-----------------------------------------------------------------------------------
Post ID:1
Sender:"mnotting" <mnot@...>
Post Date/Time:2002-01-07 09:44:36
Subject:RESTifying
Message:

I'm trying to RESTify an existing Web application, and have a
stylistic question.

Imagine that a Web application fronts for a database, where all of the
records are available as resources.

For example, you could search the database at
  http://www.example.org/search
and the results would point at records, like
  http://www.example.org/records/theThing

One can add to the database by doing a get (for the form) and then a
POST to
  http://www.example.org/add

Now, how should editing and deletion be done? One approach is to 
expose an edit resource, similar to the add one;
  http://www.example.org/edit
To edit a specific resource, one could use a query string;
  http://www.example.org/edit?resource=theThing
and use GET and POST to get the form and POST the edit.

Another approach would be to use the resource's native URI, like
  http://www.example.org/records/theThing?mode=edit
in a similar manner. This seems to be the approach taken by most
WIKIs, interestingly.

Is either approach preferable/horrible, or are they pretty much the
same? The specific application is a gateway to an LDAP database. I
haven't read Roy's full dissertation (still!), so apologies if I've
asked a FAQ.

Deletion is another interesting case; if each LDAP entry really is a
resource, DELETE would be most appropriate, no? Unfortunately, methods
other than GET and POST aren't available from HTML...

Cheers,

P.S.; Do queries identify a new resource? Their defined as a mechanism
to pass data to the server. Common use (as outlined above) seems to
indicate that people don't consider them separate, but in the URI
world, they're not lumped into URI-References with fragments...







-----------------------------------------------------------------------------------
Post ID:2
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-07 15:03:17
Subject:Re: [rest-discuss] RESTifying
Message:

> I'm trying to RESTify an existing Web application, and have a
> stylistic question.
> 
> Imagine that a Web application fronts for a database, where all of the
> records are available as resources.
> 
> For example, you could search the database at
>   http://www.example.org/search
> and the results would point at records, like
>   http://www.example.org/records/theThing

I have a thought about that that I'll bring up in another thread
shortly.

> One can add to the database by doing a get (for the form) and then a
> POST to
>   http://www.example.org/add

Why not POST to http://www.example.org/search?  The good thing about
doing that is that an intermediary would know that /search has changed
state due to the POST, whereas if it went to /add, the state change
would be transparent and the intermediary wouldn't know.  Also,
/search may not be the best name if you're posting to it.  What about
this?

http://www.example.org/database

or, if the database is a list of employees;

http://www.example.org/employees

> Now, how should editing and deletion be done? One approach is to 
> expose an edit resource, similar to the add one;
>   http://www.example.org/edit
> To edit a specific resource, one could use a query string;
>   http://www.example.org/edit?resource=theThing
> and use GET and POST to get the form and POST the edit.
> 
> Another approach would be to use the resource's native URI, like
>   http://www.example.org/records/theThing?mode=edit
> in a similar manner. This seems to be the approach taken by most
> WIKIs, interestingly.
> 
> Is either approach preferable/horrible, or are they pretty much the
> same? The specific application is a gateway to an LDAP database. I
> haven't read Roy's full dissertation (still!), so apologies if I've
> asked a FAQ.

An "edit" should be done with a PUT interface, no?  I know that this
is problematic given that browsers/HTML only support GET/POST, but if
you can afford it (development time, extra code to maintain, performance
hit with another layer), I'd solve that problem after exposing the PUT
interface, perhaps by having a separate Wiki-looking URI that accepts
POSTs and treats them as PUTs.

e.g.

http://www.example.org/employees?id=234343?pap=true

("pap" => "post-as-put")

> Deletion is another interesting case; if each LDAP entry really is a
> resource, DELETE would be most appropriate, no? Unfortunately, methods
> other than GET and POST aren't available from HTML...

Yah.  I'd do much the same as for PUT; build the DELETE interface, then
kludge a POST interface on top.

> P.S.; Do queries identify a new resource?

Yes.  Each unique URI identifies a new resource, modulo generic &
per-scheme equivalence rules.

> Their defined as a mechanism
> to pass data to the server. Common use (as outlined above) seems to
> indicate that people don't consider them separate, but in the URI
> world, they're not lumped into URI-References with fragments...

You can use them with URI refs;

      URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
      absoluteURI   = scheme ":" ( hier_part | opaque_part )
      relativeURI   = ( net_path | abs_path | rel_path ) [ "?" query ]
      hier_part     = ( net_path | abs_path ) [ "?" query ]

More on this in that other email I promised.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:3
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-07 16:27:22
Subject:Re: [rest-discuss] RESTifying
Message:

On Mon, Jan 07, 2002 at 10:03:17AM -0500, Mark Baker wrote:
> > One can add to the database by doing a get (for the form) and then a
> > POST to
> >   http://www.example.org/add
> 
> Why not POST to http://www.example.org/search?  The good thing about
> doing that is that an intermediary would know that /search has changed
> state due to the POST, whereas if it went to /add, the state change
> would be transparent and the intermediary wouldn't know.

hmm. Individual searches are separate resources; i.e., they have
different query strings, so this wouldn't necessarily work, no? (It
wouldn't make sense to POST a query, obviously).


> Also, search may not be the best name if you're posting to it. 
> /What about
> this?
> 
> http://www.example.org/database
> 
> or, if the database is a list of employees;
> 
> http://www.example.org/employees

Yes. I knew that that was a problem, just didn't have a good
mechanism; perhaps it would be good to have a DN->resource mapping,
so that

http://www.example.org/addresses

maps to 'dc=example,dc=org' (if that's the DN being used for
addresses. Then, individual entries could be maped to

  http://www.example.org/addresses/Bob%20Smith

or somesuch.

This might be a horrible abuse of LDAP, but hey, I'd
rather abuse it than the Web ;)


> An "edit" should be done with a PUT interface, no?  I know that this
> is problematic given that browsers/HTML only support GET/POST, but if
> you can afford it (development time, extra code to maintain, performance
> hit with another layer), I'd solve that problem after exposing the PUT
> interface, perhaps by having a separate Wiki-looking URI that accepts
> POSTs and treats them as PUTs.
> 
> e.g.
> 
> http://www.example.org/employees?id=234343?pap=true
> 
> ("pap" => "post-as-put")

Sure. Perhaps start with pap and then backport. I'm doing this with
python's BaseHTTPServer, so I can do anything fairly easily ;)


> You can use them with URI refs;

Yes. What I'm getting at is that the WIKI-like mechanisms such as 

  http://www.example.com/theThing
  http://www.example.com/theThing?pap=true

are a complete kludge; from a resource standpoint, these might as
well be

  http://www.example.com/theThing
  http:/www.example.com/someOtherThing

because of opacity; the only person who knows that ?pap=true does
something special is the publisher.

P.S. it would be interesting to see an analysis of the RESTyness of
WIKIs.


-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:4
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-07 18:45:52
Subject:Re: [rest-discuss] RESTifying
Message:

> > Why not POST to http://www.example.org/search?  The good thing about
> > doing that is that an intermediary would know that /search has changed
> > state due to the POST, whereas if it went to /add, the state change
> > would be transparent and the intermediary wouldn't know.
> 
> hmm. Individual searches are separate resources; i.e., they have
> different query strings, so this wouldn't necessarily work, no? (It
> wouldn't make sense to POST a query, obviously).

Why not?  Don't think of the resource as being a search, but think of
it as the result of a search.

"http://www.google.com/search?q=foo" is the set of all resources known
by Google to contain the word "foo".  That it requires a search to
resolve this URI at google.com is immaterial really.

So there's no problem with POSTing to /search.  That would be one way
for Google to allow people to register new unindexed resources, for
example.  But as mentioned below, the name is confusing.

> > Also, search may not be the best name if you're posting to it. 
> > /What about
> > this?
> > 
> > http://www.example.org/database
> > 
> > or, if the database is a list of employees;
> > 
> > http://www.example.org/employees
> 
> Yes. I knew that that was a problem, just didn't have a good
> mechanism; perhaps it would be good to have a DN->resource mapping,
> so that
> 
> http://www.example.org/addresses
> 
> maps to 'dc=example,dc=org' (if that's the DN being used for
> addresses. Then, individual entries could be maped to
> 
>   http://www.example.org/addresses/Bob%20Smith
> 
> or somesuch.
> 
> This might be a horrible abuse of LDAP, but hey, I'd
> rather abuse it than the Web ;)

Heh.  But do you understand what I was saying here, after what I just
wrote above?

> > http://www.example.org/employees?id=234343?pap=true
> > 
> > ("pap" => "post-as-put")
> 
> Sure. Perhaps start with pap and then backport. I'm doing this with
> python's BaseHTTPServer, so I can do anything fairly easily ;)

Anything except implement a catchall do_* method (I'm writing a
proxy). 8-)

> > You can use them with URI refs;
> 
> Yes. What I'm getting at is that the WIKI-like mechanisms such as 
> 
>   http://www.example.com/theThing
>   http://www.example.com/theThing?pap=true
> 
> are a complete kludge; from a resource standpoint, these might as
> well be
> 
>   http://www.example.com/theThing
>   http:/www.example.com/someOtherThing
> 
> because of opacity; the only person who knows that ?pap=true does
> something special is the publisher.

Exactly right.  An alternative is to tunnel PUT and DELETE through
POST with a hidden form field called "method".  At least the URI
wouldn't change.  I guess there's a number of ways to kludge it.
That would make for a good RESTwiki page.

> P.S. it would be interesting to see an analysis of the RESTyness of
> WIKIs.

This one has been up on the RESTwiki for a while.  It's pretty
good, I think.

http://internet.conveyor.com/RESTwiki/moin.cgi/HowWikiComparesToRest

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:5
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-07 23:06:57
Subject:Re: [rest-discuss] RESTifying
Message:

On Mon, Jan 07, 2002 at 01:45:52PM -0500, Mark Baker wrote:
> > > Why not POST to http://www.example.org/search?  The good thing about
> > > doing that is that an intermediary would know that /search has changed
> > > state due to the POST, whereas if it went to /add, the state change
> > > would be transparent and the intermediary wouldn't know.
> > 
> > hmm. Individual searches are separate resources; i.e., they have
> > different query strings, so this wouldn't necessarily work, no? (It
> > wouldn't make sense to POST a query, obviously).
> 
> Why not?  Don't think of the resource as being a search, but think of
> it as the result of a search.
> 
> "http://www.google.com/search?q=foo" is the set of all resources known
> by Google to contain the word "foo".  That it requires a search to
> resolve this URI at google.com is immaterial really.
> 
> So there's no problem with POSTing to /search.  That would be one way
> for Google to allow people to register new unindexed resources, for
> example.  But as mentioned below, the name is confusing.

Well, there's no problem POSTing an update to /search (or whatever),
but doing a query through POST doesn't seem very RESTy at all.

So, to review (and make sure I've got a cohesive interface), 

http://www.example.org/addresses 
   Exposes the DB as a whole
   GET: representation is the main interface (queries, etc.)
   POST: add a new entry, returns a 303 to the created resource
http://www.example.org/addresses?repr=add
   GET: representation is an add form
http://www.example.org/addresses?query_to_the_db
   GET: representation is a listing of the query
http://www.example.org/addresses/thePerson
   exposes a particular record
   GET: representation is a person's record
   POST: update the resource/record, returns a 303 to the resource
   PUT: create the resource/record (multiple content-types
        supported?), returns a status page (or a 303?)
   DELETE: delete the resource/record, returns a status page
http://www.example.org/addresses/thePerson?repr=edit
   GET: representation is an edit form

These duplicate functionality above:

http://www.example.org/addresses/thePerson?method=PUT
   POST: tunnels to PUT, returns a status page
http://www.example.org/addresses/thePerson?method=DELETE
   POST: tunnels to DELETE, returns a status page


I'm a *little* uncomfortable with the ?repr=add, but I can't say
exactly why.


> Exactly right.  An alternative is to tunnel PUT and DELETE through
> POST with a hidden form field called "method".  At least the URI
> wouldn't change.  I guess there's a number of ways to kludge it.
> That would make for a good RESTwiki page.

That would be cool. I like the method= kludge...


> http://internet.conveyor.com/RESTwiki/moin.cgi/HowWikiComparesToRest

Ah, I'd seen that, but never investigated. Thanks.


-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:6
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-08 01:42:42
Subject:Re: [rest-discuss] RESTifying
Message:

> > So there's no problem with POSTing to /search.  That would be one way
> > for Google to allow people to register new unindexed resources, for
> > example.  But as mentioned below, the name is confusing.
> 
> Well, there's no problem POSTing an update to /search (or whatever),
> but doing a query through POST doesn't seem very RESTy at all.

Right.  I guess I wasn't clear, my apologies.

> So, to review (and make sure I've got a cohesive interface), 
> 
> http://www.example.org/addresses 
>    Exposes the DB as a whole
>    GET: representation is the main interface (queries, etc.)
>    POST: add a new entry, returns a 303 to the created resource

Hmm, if you're creating a new resource it should be returned with a
201.  You won't get an auto redirect, but the client will know the
URI of the new resource.  The body can also include a link if a
browser is your client.

> http://www.example.org/addresses?repr=add
>    GET: representation is an add form

/addresses could serve that purposes, no need for the new URI.
Content negotiation could be used to negotiate a representation
capable of expressing a form.

> http://www.example.org/addresses?query_to_the_db
>    GET: representation is a listing of the query

Looks good.

> http://www.example.org/addresses/thePerson
>    exposes a particular record
>    GET: representation is a person's record
>    POST: update the resource/record, returns a 303 to the resource
>    PUT: create the resource/record (multiple content-types
>         supported?), returns a status page (or a 303?)
>    DELETE: delete the resource/record, returns a status page

Good.

> http://www.example.org/addresses/thePerson?repr=edit
>    GET: representation is an edit form

Again, could content negotiation not be used to retrieve an editable
format?

BTW, my other message I promised is turning into something that should
probably be sent to uri@..., so stay tuned.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:7
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-08 00:02:36
Subject:Re: [rest-discuss] RESTifying
Message:

On Mon, Jan 07, 2002 at 08:42:42PM -0500, Mark Baker wrote:
> > http://www.example.org/addresses 
> >    Exposes the DB as a whole
> >    GET: representation is the main interface (queries, etc.)
> >    POST: add a new entry, returns a 303 to the created resource
> 
> Hmm, if you're creating a new resource it should be returned with a
> 201.  You won't get an auto redirect, but the client will know the
> URI of the new resource.  The body can also include a link if a
> browser is your client.

Hmm. Seems good; will have to play.


> > http://www.example.org/addresses?repr=add
> >    GET: representation is an add form
> 
> /addresses could serve that purposes, no need for the new URI.
> Content negotiation could be used to negotiate a representation
> capable of expressing a form.
[...]
> > http://www.example.org/addresses/thePerson?repr=edit
> >    GET: representation is an edit form
> 
> Again, could content negotiation not be used to retrieve an editable
> format?

What's the media type for an HTML form which is the editable
representation of a resource again? ;)

Also, how would I tell a browser to request it?


> BTW, my other message I promised is turning into something that should
> probably be sent to uri@..., so stay tuned.

Cool!

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:8
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-08 06:51:03
Subject:The woes of conneg (was: RESTifying)
Message:

On Mon, Jan 07, 2002 at 08:42:42PM -0500, Mark Baker wrote:
> Content negotiation could be used to negotiate a representation
> capable of expressing a form.

I was hoping to allow requests to the record resource
  http://www.example.com/addresses/thePerson
to negotiate the representation returned, so that the default would
be to return an HTML page, but if linked from an <img> element, the
image/jpeg in the jpegPhoto attribute would be returned. 

Sadly, it's not to be. Conneg support in browsers is horrible.
Mozilla sends a static Accept header, no matter what the context,
which enumerates all of the types it supports. I've logged a bug[1]
for this (please vote for it if so inclined).

IE seems to generate the Accept header based on the filename
extension of the resource (EW!), and by default sends a header that
includes a lot of image/ types, a */* (which is a CUAP[2]), but no
HTML.

Of course, conneg is still useful to expose, but lack of support in
browsers means that another means of doing this -- probably with
query strings (or maybe path parameters?) -- will have to be hacked.

*sigh* 


[1] http://bugzilla.mozilla.org/show_bug.cgi?bug_id=118696
[2] http://www.w3.org/TR/cuap


Hmm... Bugzilla would be an excellent candidate for RESTification...


-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:9
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-08 07:30:25
Subject:Re: [rest-discuss] The woes of conneg (was: RESTifying)
Message:

On Mon, Jan 07, 2002 at 10:51:03PM -0800, Mark Nottingham wrote:
> [1] http://bugzilla.mozilla.org/show_bug.cgi?bug_id=118696

Oops, that should be
[1] http://bugzilla.mozilla.org/show_bug.cgi?id=118696


-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:10
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-10 17:44:31
Subject:Authentication
Message:

Why do so many websites use home-spun HTML/cookie authentication
(login/password) instead of HTTP authentication? I'm guessing it is all
about user interface issues -- being able to put the login box
where-ever you want it.

What needs to be done to web infrastructure so that this bit of context
moves from the HTML/cookie domain down into HTTP where it is supposed to
live?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:11
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-10 18:14:07
Subject:Re: [rest-discuss] Authentication
Message:

> Why do so many websites use home-spun HTML/cookie authentication
> (login/password) instead of HTTP authentication? I'm guessing it is all
> about user interface issues -- being able to put the login box
> where-ever you want it.

Exactly right.  This is a major issue, as it prevents many tasks from
being automated.

> What needs to be done to web infrastructure so that this bit of context
> moves from the HTML/cookie domain down into HTTP where it is supposed to
> live?

I don't know that there's a quick fix.  One thing I was thinking of was
an HTML/XHTML extension that would allow more flexibility in the user
interface of the authentication system.  But it would take forever to
roll that out.

Other ideas;
- conventions for cookie values.  would also be difficult to rollout
as HTTP libs that support cookies would all need fixing.
- recognizing forms with two fields where one is a password input type,
and somehow kludging that knowledge into the auth system.  easier to
rollout, but error prone and not sure how the kludge would work

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:12
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-10 20:55:01
Subject:Re: [rest-discuss] Authentication
Message:

On Thu, Jan 10, 2002 at 01:14:07PM -0500, Mark Baker wrote:
> > Why do so many websites use home-spun HTML/cookie authentication
> > (login/password) instead of HTTP authentication? I'm guessing it
> > is all about user interface issues -- being able to put the login
> > box where-ever you want it.
> 
> Exactly right.  This is a major issue, as it prevents many tasks
> from being automated.

I think the issue is more that publishers don't have much control
over the authentication state on the browser; things like remembering
the username between sessions, logging out, etc. weren't addressable
until IE and later Mozilla introduced password management interfaces.
They're still less capable than cookie handling, unfortunately.

Also, it was drilled into eveyone's heads that Basic authentication
isn't secure. Some people thought that magically using cookies would
solve this, whilst the more savvy used encrypted or hashed values in
cookies. There is Digest authentication, but it was plagued with
specification and implementation problems, IIRC.


> - conventions for cookie values.  would also be difficult to rollout
> as HTTP libs that support cookies would all need fixing.

What kind of conventions? It strikes me that defining conventions for
cookies is about as friendly as defining conventions for URIs like
well-known locations...


> - recognizing forms with two fields where one is a password input type,
> and somehow kludging that knowledge into the auth system.  easier to
> rollout, but error prone and not sure how the kludge would work

I believe this is what Mozilla and IE do now. Of course, the auth is
still sent as a cookie.


Cheers,

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:13
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-15 21:33:41
Subject:FYI: XForms and PUT
Message:

I've raised an issue [1] with the XForms WG regarding their lack of
support for PUTing xml instance data. Supporting PUT would seem to be
very helpful to RESTful applications...

[1] http://lists.w3.org/Archives/Public/www-forms/2002Jan/thread.html#47


-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:14
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-15 23:55:03
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

I don't know much about XForms but this little bit worried me:

"My personal take is that HTTP GET is broken beyond repair for I18N-safe
form-data submission. This is part of the reason why it's deprecated in
XForms. Sending around bits of XML is a much better way to go."

And yes indeed:

http://www.w3.org/TR/xforms/slice11.html#rpm-send

"The HTTP "get" protocol is deprecated for use in form submission. Form
authors should use "post" for greater compatibility."

Insofar as XForms will most often be used to submit data to be stored,
this isn't a crisis, but when XForms replace HTML forms in general, this
is going to be a big problem.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:15
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-16 01:06:04
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

> I don't know much about XForms but this little bit worried me:
> 
> "My personal take is that HTTP GET is broken beyond repair for I18N-safe
> form-data submission. This is part of the reason why it's deprecated in
> XForms. Sending around bits of XML is a much better way to go."
> 
> And yes indeed:
> 
> http://www.w3.org/TR/xforms/slice11.html#rpm-send
> 
> "The HTTP "get" protocol is deprecated for use in form submission. Form
> authors should use "post" for greater compatibility."
> 
> Insofar as XForms will most often be used to submit data to be stored,
> this isn't a crisis, but when XForms replace HTML forms in general, this
> is going to be a big problem.
> 
>  Paul Prescod

I'm not worried about this at all.  GET forms and POST forms are
completely different beasts.  The latter is for submitting resource
representations, while the former is an assertion that the specified
resource is a logical container for other resources, and is indexed by
some set of names encoded into a query term.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:16
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-16 01:41:45
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

Mark Baker wrote:
> 
>...
> 
> I'm not worried about this at all.  GET forms and POST forms are
> completely different beasts.  The latter is for submitting resource
> representations, while the former is an assertion that the specified
> resource is a logical container for other resources, and is indexed by
> some set of names encoded into a query term.

I don't follow you. A form is a user interface. Today forms are often
used as user interfaces to GET and to POST (i.e. filling in an
information request as opposed to submitting data). XForms is the
replacement for HTML forms. Over time browsers will move to this more
functional user interface and yet lose out on the ability to do
form-based GET. I see that as a problem.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:17
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-16 03:10:26
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

> I don't follow you. A form is a user interface.  Today forms are often
> used as user interfaces to GET and to POST (i.e. filling in an
> information request as opposed to submitting data). XForms is the
> replacement for HTML forms. Over time browsers will move to this more
> functional user interface and yet lose out on the ability to do
> form-based GET. I see that as a problem.


I agree that it would be a problem if this were the case.  But in my
time on the HTML WG, including while work on XForms was being done
there, it was never presented as a replacement.

It wouldn't hurt to double check though.  Why don't you raise this on
www-forms?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:18
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-16 07:06:19
Subject:RFC: Potential XML.com article
Message:

Please contribute comments on this article I am working on for xml.com.
==============
	Second Generation Web Services

In the early days of the Internet, it was common for enlightened
businesses to connect to the Internet merely by using SMTP, NTTP and FTP
clients and servers to deliver messages, text files, executables and
source code. The Internet became a more fundamental tool when businesses
started to integrate their corporate information (both public and
private) into the emerging Web framework. The Internet became popular
when it shifted from a focus on transactional protocols to a focus on
data objects and the links between them. 

The technologies that characterize the early Web framework were
HTML/GIF/JPEG, HTTP and URLs. This combination of standardized formats,
a single application protocol and a single universal namespace was
incredibly powerful. Using these technologies, corporations integrated
their diverse online publishing systems into something much more
compelling than any one of them could have built.

Once organizations converged on common formats, the HTTP protocol and a
single addressing scheme, the Web became more than a set of Web sites.
It became the world's most diverse and powerful information system.
Organizations built links between their own information and other
people's. Amazing third party applications also weaved the information
together. Examples include Google, Yahoo, Babelfish and Robin Cover's
XML citations.

First generation Web Services are like first generation Internet
connections. They are not integrated with each other and are not
designed so that third parties can easily integrate them in a uniform
way. I posit that the next generation will be more like the integrated
Web that arose for online publishing and human/computer interactions. In
fact, I believe that second generation web services will actually build
much more heavily on the architecture that made the Web work. Look for
the holy trinity: standardized formats (XML vocabularies), a
standardized application protocol and a single URI namespace.

This next generation of Web Services will likely bear the name "REST"
Web Services. REST is the underlying architectural model of the current
Web. It stands for REpresentational State Transfer. Roy Fielding of
eBuilt invented the name in his PhD dissertation.
http://www.ebuilt.com/fielding/pubs/dissertation/top.htm. Recently, Mark
Baker of PlanetFred has been a leading advocate of this architecture.

REST details why the Web has URIs, HTTP, HTML, JavaScript and many other
features. It has many aspects and I would not claim to understand it in
detail. I'm going to focus on the aspects that are most interesting to
XML users and developers.

	The Current Generation

SOAP was originally intended to be a cross-Internet form of DCOM or
CORBA. The name of an early SOAP-like technology was "WebBroker" -
Web-based object broker. It made perfect sense to model an
inter-application protocol on DCOM, CORBA, RMI etc. because they were
the current models for solving inter-application interoperability
problems.

These RPC protocols achieved only limited success before they were
ported to the Web. Some believe that the problem was merely that
Microsoft and the OMG supporters could not get along. I disagree. There
is a deeper issue. RPC models are great for closed-world problems. A
closed world problem is one where you know all of the users, you can
share a data model with them, and you can all communicate directly as to
your needs. Evolution is comparatively easy in such an environment: you
just tell everybody that the RPC API is going to change on such and such
a date and perhaps you have some changeover period to avoid downtime.
When you want to integrate a new system you do so by building a
point-to-point integration.

On the other hand, when your user base is too large to communicate
coherently you need a different strategy. You need a pre-arranged
framework that allows for evolution on both the client and server sides.
You need to depend less on a shared, global understanding of the rights
and responsibilities of a participant. You need to put in hooks where
your users can innovate without contacting you. You need to leave in
explicit mechanisms for interoperating with systems that do not have the
same API. RPC protocols are traditionally poor at this kind of
evolution. Changing interfaces tends to be extremely difficult. I
believe that this is why no enterprise has ever successfully unified all
of their systems with an RPC protocol such as DCOM, CORBA or RMI.

Now we come to the crux of the problem: SOAP RPC is DCOM for the
Internet.
There are many problems that can be solved with an RPC methodology. But
I believe that the biggest, hairiest problems will require a model that
allows for independent evolution of clients, servers and intermediaries.
It is therefore important for us to study the only distributed
applications in history to ever scale to the size of the Internet.

    The archetypical scalable application

There two most massively scalable, radically interoperable, distributed
applications in the world today and they are the Web and email. What
makes these two so scalable and interoperable feature? For starters,
they both depend on standardized, extensible message formats (HTML and
MIME). They both depend on standardized, extensible application
protocols (HTTP and SMTP). But I believe that the most important thing
is that each has a global addressing scheme.

In the real estate world there is a joke that there are three things
that make a property valuable: location, location and location. The same
is true in the world of XML web services. Properly implemented, XML web
services allow you assign addresses to data objects so that they may be
located for sharing or modification.

In particular, the web's central concept is a single unifying namespace
of URIs. URIs allow the dense web of links that make the Web worth
using. URIs identify resources. Resources are conceptual objects.
Representations of them are delivered across the web in HTTP messages.
These ideas are so simple and yet they are profoundly powerful and
demonstrably successful. URIs are extremely "loosely coupled". You can
pass a URI from one "system" to another using a piece of paper and OCR!
URIs are "late bound". They do not declare what can or should be done
with the information they reference. It is because they are so radically
"loose" and "late" that they scale to the level of the Web.

Unfortunately, most of us do not think of our web services in these
terms. Rather we think of them in terms of remote procedure calls
between endpoints that represent software components. This is CORBA/DCOM
thinking. Web thinking is organized around URIs for resources.

Claim: The next generation of web services will use individual data
objects as endpoints. Software component boundaries will be invisible
and irrelevant.

	An Illustrative Example

UDDI is an example of a Web Service that could be made much, much more
robust as a second generation Web Service. I'm not discussing the
philosophical issues of UDDI's role in the web services world but the
very concrete issue of how to get information into and out of it. These
arguments will apply to most of the Web Services in existence, including
stock quote services, airplane reservations systems and so forth.

UDDI has a concept of a businessEntity representing a corporation.
Businesses are identified by UUIDs. The Web-centric way to do this would
have been to identify them by URIs. The simplest way to do this would be
to make a businessEntity an XML document addressable at a URI
like"http://www.uddi.org/businessEntity/ibm.com" or perhaps
"http://www.uddi.org/getbusinessEntity?ibm.com". The difference between
these two is subtle and does not have many technical implications so
let's not worry about it. 

You can think of "http://www.uddi.org/businessEntity" as a directory
with files in it or a web service pulling data from a database. A
wonderful feature of the Web is that there is no way to tell which is
true just from looking at the URI. That is "loose coupling" in action!

Let's consider the implications of using HTTP-based URIs instead of
UUIDs for business entities:

*	Anybody wanting to inspect that business entity would merely point
their (XML-aware!) browser at that URI and look at the businessEntity
record. 

*	Anybody wanting to reference the businessEntity (in another web
service or a document) could just use the URL.

*	Anybody wanting to incorporate the referenced information into another
XML document could use an XLink, XPointer or XInclude.

*	Anybody wanting a permanent copy of the record could use a command
line tool like "wget" or do a "Save As" from the browser. 

*	Any XSLT stylesheet could fetch the resource dynamically to combine it
with others in a transformation.

*	Access to the businessEntity could be controlled using standard HTTP
authentication and access control mechanisms

*	Metadata could be associated with the businessEntity using RDF

*	Any client-side application (whether browser-based or not) could fetch
the data without special SOAP libraries.

*	Two business entities could represent their merger by using a standard
HTTP redirect from one businessEntity to another.

*	Editing and analysis tools like Excel, XmetaL, Word and EMACS could
import XML from the URL directly using HTTP. They could write back to it
using WebDAV.

*	UUIDs or other forms of location-independent addresses could still be
assigned as an extra level of abstraction as demonstrated at purl.org.

The current UDDI "API" has a method called get_businessDetail. Under an
address-centric model, that method would become entirely redundant and
could thus be removed from the API. UDDI has several get_ methods that
operate on data objects such as tModels and business services. These
data objects could all be represented by logical XML documents and the
methods could be removed. Note how we have substantially simplified the
user's access to UDDI information.

Business entities are not the only things in UDDI that should be
identified by URI-addressable resources rather than SOAP APIs. In fact
all of the data in a UDDI database could be represented this way.

Summary: Resources (data objects) are like children. They need to have
names if they are to participate in society.

	Extensibility

Now let's consider the extensibility  characteristics of the REST model
versus the original SOAP RPC model. Let's say that your company has a
private UDDI registry and mine does also. You and I are business
partners. We agree to share our customer databases. The customer
databases have pointers into our UDDI registries for referring to
businessEntities.

If our registries have little or no overlap then it makes sense for you
to maintain yours and for me to maintain mine. Rather than replicating
between them (which has serious security and maintainability
implications) I would like to just add you to the access control lists
for some records and allow you to refer to them from your customer
database and I'll do the opposite from mine.

If the customer databases use UUIDs then they have no way of knowing
whether a particular UUID should be looked up in the local database, the
partner's database or even the public UDDI In The Sky. URIs are not just
globally unique but also typically embed enough information to allow
them to be de-referenced without further context. Using URIs instead of
UUIDs, new repositories can be integrated whenever we want. In fact, if
we use URIs, the customer database could refer just as easily to
businessEntity records sitting on somebody's hard disk as in a formal
UDDI registry. The database maintainer could choose whether to allow
that or not.

Because the businessEntity documents are XML, it is relatively easy to
add elements, attributes or other namespaces. This makes the document
format extensible. It is also easy to extend the protocol by adding
specialized HTTP headers or even new HTTP methods.

	Performance

Performance of web services will be an important issue. Any resource
representation retrieved from a GET-based URI can be cached. It can be
cached in a cache server in front of the server, in an intermediate
provided by an ISP, at a corporate firewall or on the client computer.
Caching is built-in to HTTP. SOAP get_businessDetail messages are not
cached by any existing technology.

As an optimization, the URI "http://www.uddi.org/businessEntity/ibm.com"
might be represented as a raw text file on a hard disk of an operating
system optimized towards serving files over HTTP. There is not and will
likely never be any server that can invoke SOAP methods as quickly as a
fast HTTP server can serve files from disk.

	Other methods

UDDI has other methods for working with businessEntities. One is
delete_business. HTTP already has a DELETE method. Therefore this method
would be redundant in the REST model. Instead of doing a UDDI
SOAP-RPC-specific delete you could do an HTTP delete. This would have
the benefit of being compatible with tools that know how to do HTTP
deletes like the Windows 2000 explorer and MacOS X finder. In theory,
businesses could delete portions of their own records (perhaps obsolete
branch plant addresses) by merely hitting the "delete" key.

Obviously authentication and access control is key. Microsoft should not
be able to delete their competitors (or at least should be forced to
delete them in the old fashioned way, by competing with them). HTTP
already has the authentication, authorization and encryption features
that UDDI's SOAP RPC protocol lacks. It already works.

UDDI has a save_business method. This is for uploading new businesses.
The HTTP equivalent is PUT or POST. A pleasant side effect of using HTTP
methods instead of a SOAP method is that you can do a POST from an HTML
form. So the web service can be used either from other programs or (with
a browser) by a human editor.

UDDI has a find_business method. This is no different in principle than
the search features built into every website in the world and search
engine sites in particular. That would be a form of GET. On the URL
line, the service would take a series of search parameters and return an
XML document representing the matching businessEntities (either by
reference, as URLs, or by value, as XML elements).

	The Role of HTTP

You may notice a recurring theme. Everything that we want to do in this
Web Service is already supported in HTTP. The only things that we need
to innovate on are our URI structure and our XML schemas. Bingo! That
was the whole point of XML: to focus on data interchange instead of
software components!

Everything in UDDI can be represented in terms of HTTP operations on
resources. So HTTP isn't accidentally paired with URIs as one of the
central technologies of the Web. It is designed specifically as a major
part of the location-centric REST architecture.

Here's the radical idea: no matter what your problem, you can and should
think about it as a data resource manipulation problem rather than as an
API design problem. Think of your web server as this big information
repository: like a database. You are doing data manipulation operations
on it.

In UDDI I've chosen a web service that is ripe for an easy conversion to
REST philosophy but we can apply these principles to anything. What
about something like a purchase order submission? That seems more
transactional. Well purchase orders want to be named also! If you POST
or PUT a purchase order to a new URI then internal systems all over your
company can instantly refer to it no matter where they are. Using HTTP,
an arbitrary XSLT stylesheet or Perl script sitting on an employee's
desktop in the Beijing office can massage data from a purchase order
sitting on the accounting mainframe in Los Angeles. Accessing
HTTP-addressable resources is no more difficult than accessing files off
of the local file system, but it requires much less coordination than
standard file system sharing technologies.

What about a request for quote? RFQs want to be named! Once you give
them a name you can pass around the URL to your partners rather than the
text. Then your partners can build references to them using hyperlinks
from their documents and databases. Use access controls to keep out your
competitors. You can think about any business problem in this way.

Even web services with complicated work flows can be organized in a
URI-centric manner. Consider a system that creates airline reservations.
In a traditional HTML system there are a variety of pages representing
the different stages in the logical transaction. First you look up
appropriate flights. You get back a URI representing the set of
appropriate flights. Then you choose a light. You get back a URI
representing your choice. Then you decide to commit. You get back a web
page that returns reservation number. Ideally the URL for that page will
persist for a reasonable amount of time so that you can bookmark it. 

An XML based web service could go through the exact same steps. Rather
than returning HTML forms at each step, the service would return XML
documents conforming to a standard airline industry vocabulary. Those
same XML documents could be used on a completely different airline
reservation site to drive exactly the same process.

Summary: Any business problem can be thought of as a data resource
manipulation problem and HTTP is a data resource manipulation protocol.

	Metcalfe's Law Revisited

Metcalfe's law is that the value of a network is proportional to the
square of the number of people on the network, because each pair of
people can make a connection between them. One telephone is useless. One
billion phones cause a major telecommunications revolution - if they can
all access each other through a single global naming system. 

Metcalfe's law also applies to data objects. Elements in UDDI can only
(with a few exceptions) refer to each other. They cannot refer to
objects elsewhere on the Web (for instance in other UDDI repositories).
Similarly, objects on the Web (for instance web pages) cannot refer to
the XML elements in the UDDI repository. A URL-centric solution would
unify these data domains as the phone number system unifies telephones.

	Security

Making your data universally addressable is not equivalent to making it
universally available! It is easy to hide objects by merely never
publishing their URIs. It is also easy to apply security policies to
objects. In fact, REST simplifies security greatly. 

Under the SOAP RPC model, the objects that you work with are implicit
and their names are hidden in method parameters. Therefore you need to
invent a new security strategy for each and every web service. UDDI is
completely unlike .NET My Service which will likely be completely unlike
Liberty and so forth. Under REST, you can apply the four basic
permissions to each data object: GET permission, PUT permission, DELETE
permission and POST permission. You might also want to allow or disallow
GET/PUT/DELETE and POST on sub-resources. This model is exactly like the
one used for today's file systems! It is proven and it works. I know of
no security model that works in a similarly generic manner for remote
procedure call models.

	Maintenance

In fact, security is just one form of maintainability that is simplified
by REST.  Any network administrator will tell you that every level of
networking causes its own headaches. Some days IP works but DNS doesn't
(DNS server down or DNS settings misconfigured). Some days IP/DNS works
but HTTP doesn't (firewall or proxy misconfigured). If you run a web
service protocol on top of HTTP it will add its own layer of
configuration and software headaches on top of the existing ones. It
cannot be more reliable than its foundational HTTP layer. It can only
add one more layer of unreliability.

Once you have your service working, it is possible to "test" REST web
services just by looking at them in a browser. It is possible to make
simple HTML forms to test POSTs. QA departments can easily pretend to be
multiple users by changing their HTTP credentials. Standard web tools
can monitor availability. In essence, testing REST services is often
easy if you already know how to test web sites. On the other hand, every
SOAP RPC service will have its own security model, its own addressing
model, an implicit data model and its own set of methods. Of these four
things, only the security model is even currently a candidate for
standardization. Testing such a system is much more challenging.

	The Rest of the Story

This brief introduction can only whet your appetite to the theory and
practice of REST-based web services. In an upcoming article, I will:

*	describe in more detail how any web service can be transformed into a
URI-centric one. 

*	show how the REST philosophy and the XML philosophy are highly
compatible.

*	show an example of a successful, public, widely used web service that
uses this model today. 

*	discuss the role of SOAP in these sorts of web services.

*	discuss reliability, coordination, transactions, encryption, firewalls
etc.

If you would like to discuss these issue in the meantime, please
consider contributing to the rest-wiki
(http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage) and the REST
mailing list (http://groups.yahoo.com/group/rest-discuss/). 
=============






-----------------------------------------------------------------------------------
Post ID:19
Sender:"mdierken" <mdierken@...>
Post Date/Time:2002-01-16 08:01:03
Subject:Re: The woes of conneg (was: RESTifying)
Message:

> 
> Of course, conneg is still useful to expose, but lack of support in
> browsers means that another means of doing this -- probably with
> query strings (or maybe path parameters?) -- will have to be hacked.
> 
> *sigh* 

I've used the ?method= approach for a couple years (actually used 
do:method for collision avoidance) to tunnel methods. I've also used ?
accept= to tunnel Accept headers.

Why not use the LDAP dn in the URL?
For example, I wrote a servlet a while back to do stuff like this:

http://www.xmldatasource.com:7779/xds/ldap2xml/

http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/
uid=myxie/

http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/
uid=myxie/?do:accept=text/xml

Mike







-----------------------------------------------------------------------------------
Post ID:20
Sender:"mdierken" <mdierken@...>
Post Date/Time:2002-01-16 08:11:33
Subject:Re: The woes of conneg (was: RESTifying)
Message:

--- In rest-discuss@y..., Mark Nottingham <mnot@m...> wrote:
> 
> On Mon, Jan 07, 2002 at 08:42:42PM -0500, Mark Baker wrote:
> > Content negotiation could be used to negotiate a representation
> > capable of expressing a form.
> 
> I was hoping to allow requests to the record resource
>   http://www.example.com/addresses/thePerson
> to negotiate the representation returned, so that the default would
> be to return an HTML page, but if linked from an <img> element, the
> image/jpeg in the jpegPhoto attribute would be returned. 
> 

Even if you tunnel Accept header in the URL (which means you need to 
control the server or have a generic intermediary that un-tunnels 
them) you'll want to consider strongly using sub-resource for images 
and stuff.
If the URI space you design can address LDAP attributes, then you'd 
have the problem solved maybe?









-----------------------------------------------------------------------------------
Post ID:21
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-16 18:09:27
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:


John Barton has replied [1] to my e-mail, saying that his
interpretation of REST is that POST is more appropriate than PUT.

Still being a REST novice (and still, dammit, not having read the
entirety of Roy's dissertation), what say you, rest-discuss? Does PUT
have a place in REST?

My instinct is that there is; while POST has the benefit of
separating the data and representations, there are times when it's
beneficial to say "here's a representation; when people request this
resource in the future, give it to them." Does having such a direct
relationship violate REST?



[1] http://lists.w3.org/Archives/Public/www-forms/2002Jan/0078.html


On Tue, Jan 15, 2002 at 01:33:41PM -0800, Mark Nottingham wrote:
> 
> I've raised an issue [1] with the XForms WG regarding their lack of
> support for PUTing xml instance data. Supporting PUT would seem to be
> very helpful to RESTful applications...
> 
> [1] http://lists.w3.org/Archives/Public/www-forms/2002Jan/thread.html#47
> 
> 
> -- 
> Mark Nottingham
> http://www.mnot.net/
>  
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:22
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-16 18:49:57
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

> John Barton has replied [1] to my e-mail, saying that his
> interpretation of REST is that POST is more appropriate than PUT.
> 
> Still being a REST novice (and still, dammit, not having read the
> entirety of Roy's dissertation), what say you, rest-discuss? Does PUT
> have a place in REST?

Of course!  How else can you explicitly set state and have
intermediaries know about it (so they can cache it)?  You can't do that
with POST.

> My instinct is that there is; while POST has the benefit of
> separating the data and representations, there are times when it's
> beneficial to say "here's a representation; when people request this
> resource in the future, give it to them." Does having such a direct
> relationship violate REST?

I don't understand what you or John are referring to when you refer
to a difference between "data" and the "representation".  REST says
nothing of "data", nor should it because it's hidden (if I understand
what is meant by "data" - basically, the state in some raw form).

I also don't know what John means by "The appropriate pair for REST
is GET/POST".  Why "pair"?  Why restrict one's self to two methods
for coordination when three is needed?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:23
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-16 19:06:15
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

Mark Baker wrote:
> 
>...
> 
> I don't understand what you or John are referring to when you refer
> to a difference between "data" and the "representation".  REST says
> nothing of "data", nor should it because it's hidden (if I understand
> what is meant by "data" - basically, the state in some raw form).

Mark N. believes (and without looking it up, I would guess he's right)
that the semantics of PUT are that an immediately following GET should
return the same representation that was just PUT. Whereas POST has no
such semantic. So when they say "data" they mean a representation that
is appropriate for GETing.

> I also don't know what John means by "The appropriate pair for REST
> is GET/POST".  Why "pair"?  Why restrict one's self to two methods
> for coordination when three is needed?

You claim that three is needed (why not four) but the web more or less
gets by with two today!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:24
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-16 19:10:41
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

Mark Baker wrote:
> 
>...
> 
> Of course!  How else can you explicitly set state and have
> intermediaries know about it (so they can cache it)?  You can't do that
> with POST.

Is this intermediary argument realistic? Let's say I'm going through a
big honking cache at AOL. I do a PUT. Now all AOL users in the world
have an updated view of the world because our cache recorded the PUT.
But everyone else in the universe is out of date. Why should AOL users
get a priviledged view of the world?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:25
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-16 19:22:33
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

> Mark N. believes (and without looking it up, I would guess he's right)
> that the semantics of PUT are that an immediately following GET should
> return the same representation that was just PUT.

Actually, that's not quite right.  There's content negotiation to be
considered.

> Whereas POST has no
> such semantic. So when they say "data" they mean a representation that
> is appropriate for GETing.
> 
> > I also don't know what John means by "The appropriate pair for REST
> > is GET/POST".  Why "pair"?  Why restrict one's self to two methods
> > for coordination when three is needed?
> 
> You claim that three is needed (why not four) but the web more or less
> gets by with two today!

REST doesn't limit the number of methods.  You might need 10 to
coordinate something complicated.  The point here being that there's
a whole whack load of things that can't be *efficiently* coordinated
with GET/POST.  Just look at Wiki.  It's doing PUT with POST, and so
misses out on an important optimization (caching PUTs).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:26
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-16 19:26:31
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

> > Of course!  How else can you explicitly set state and have
> > intermediaries know about it (so they can cache it)?  You can't do that
> > with POST.
> 
> Is this intermediary argument realistic? Let's say I'm going through a
> big honking cache at AOL. I do a PUT. Now all AOL users in the world
> have an updated view of the world because our cache recorded the PUT.
> But everyone else in the universe is out of date. Why should AOL users
> get a priviledged view of the world?

It only takes one person at MSN to do a GET on that same resource, and
for MSN to cache that response, to have the same effect.

This is a really small advantage in a write-few/read-many environment.
I wouldn't worry about it.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:27
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-16 19:33:14
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

Mark Baker wrote:
> 
>...
> 
> It only takes one person at MSN to do a GET on that same resource, and
> for MSN to cache that response, to have the same effect.

Right. So and of course the same goes for the original originator
network AOL. So why worry about the caching of PUTs? The cache can just
wait for the next GET.

> This is a really small advantage in a write-few/read-many environment.
> I wouldn't worry about it.

That's my point! If PUTs have a small advantage over POST then why
should we REST-ies spend our valuable moral capital fighting with FORMs
peoples etc. over PUT. Well, I'm mostly playing the devil's advocate
because of course fighting for the Right Thing is its own reward. ;)
Seriously though, I'd rather have strong arguments in favour of PUT than
this one which seems quite weak to me.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:28
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-16 19:35:49
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

Mark Baker wrote:
> 
>...
> 
> REST doesn't limit the number of methods.  You might need 10 to
> coordinate something complicated.  The point here being that there's
> a whole whack load of things that can't be *efficiently* coordinated
> with GET/POST.  Just look at Wiki.  It's doing PUT with POST, and so
> misses out on an important optimization (caching PUTs).

I don't think I've seen a strong case that this optimization is
important. Would Wiki be noticably better if it used PUT instead of
POST?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:29
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-16 19:45:43
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

> > This is a really small advantage in a write-few/read-many environment.
> > I wouldn't worry about it.
> 
> That's my point! If PUTs have a small advantage over POST then why
> should we REST-ies spend our valuable moral capital fighting with FORMs
> peoples etc. over PUT.

There's *currently* a small advantage; caching.  There may be a larger
advantag

> Well, I'm mostly playing the devil's advocate
> because of course fighting for the Right Thing is its own reward. ;)
> Seriously though, I'd rather have strong arguments in favour of PUT than
> this one which seems quite weak to me.

I'm not rabid about the need for PUT in XForms.  It wouldn't be a
replacement for having user agents supporting it as a "File->Save" type
operation.  I'd see it mostly used for creating new resources, where
the content provider could specify the URI for the new resource.
Developers shouldn't commonly use PUT with XForms to try and replace
this missing functionality from user agents.  But hopefully any user
agent supporting XForms and PUT would go the next step and support
PUT more generally like Amaya.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:30
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-16 19:56:47
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

> I don't think I've seen a strong case that this optimization is
> important. Would Wiki be noticably better if it used PUT instead of
> POST?

Oopsie with that last message.  I'll continue my thought here.

There's *currently* a small efficiency advantage in having PUT as its
own method; caching.  But safety is also an issue.  Permitting the
PUT method to go behind a firewall is a much safer thing to do than
permitting POST, for example, because PUT behaviour is much more
narrowly defined.

I would expect that there's other good reasons too, but that's all
that I can think of right now.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:31
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-16 21:10:13
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

On Wed, Jan 16, 2002 at 02:22:33PM -0500, Mark Baker wrote:
> > Mark N. believes (and without looking it up, I would guess he's right)
> > that the semantics of PUT are that an immediately following GET should
> > return the same representation that was just PUT.
> 
> Actually, that's not quite right.  There's content negotiation to be
> considered.

From 2616 (section 9.6, PUT)

  The PUT method requests that the enclosed entity be stored under
  the supplied Request-URI. If the Request-URI refers to an already
  existing resource, the enclosed entity SHOULD be considered as a
  modified version of the one residing on the origin server. If the
  Request-URI does not point to an existing resource, and that URI is
  capable of being defined as a new resource by the requesting user
  agent, the origin server can create the resource with that URI. 
  [...]

This seems to imply that in the case of PUT, the Web *is* a
filesystem ("be stored under").


  If the request passes through a cache and the Request-URI identifies
  one or more currently cached entities, those entries SHOULD be
  treated as stale. Responses to this method are not cacheable.

So this blows away the caching arguments; in that sense, it's
equivalent to POST.


  The fundamental difference between the POST and PUT requests is
  reflected in the different meaning of the Request-URI. The URI in a
  POST request identifies the resource that will handle the enclosed
  entity. That resource might be a data-accepting process, a gateway
  to some other protocol, or a separate entity that accepts
  annotations.  In contrast, the URI in a PUT request identifies the
  entity enclosed with the request -- the user agent knows what URI
  is intended and the server MUST NOT attempt to apply the request to
  some other resource.  If the server desires that the request be
  applied to a different URI, it MUST send a 301 (Moved Permanently)
  response; the user agent MAY then make its own decision regarding
  whether or not to redirect the request.

This *seems* to limit the effects of a PUT to the identified
resource, as well as support the 'filesystem' view. This also
theoretically makes the 'accept=...' hacks even hackier, because a
PUT would indeed affect the state of other resources (i.e., the
resource identified with the accept=... hack, vs. the one identified
w/o it). Which means tha tthe accept=... hack shouldn't be available
on PUTed requests; only POSTs (which can use a method=... hack).


  HTTP/1.1 does not define how a PUT method affects the state of an
  origin server.

I'd like to know what the intent of this is; it doesn't say state of
the *resource*, but state of the *origin server*.


  Unless otherwise specified for a particular entity-header, the
  entity-headers in the PUT request SHOULD be applied to the resource
  created or modified by the PUT.

And this seems to cover conneg. I read this as saying "if it has a
'Content-Foo: bar' request header, negotiate subsequent GETs as if
it's Foo is bar." This view seems to be supported by:

  The recipient of the entity MUST NOT ignore any Content-*
  (e.g. Content-Range) headers that it does not understand or implement
  and MUST return a 501 (Not Implemented) response in such cases.


-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:32
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-16 21:10:37
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

On Wed, Jan 16, 2002 at 11:33:14AM -0800, Paul Prescod wrote:
> Seriously though, I'd rather have strong arguments in favour of PUT than
> this one which seems quite weak to me.

I agree.


-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:33
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-16 21:24:49
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

On Wed, Jan 16, 2002 at 01:10:13PM -0800, Mark Nottingham wrote:
>   The fundamental difference between the POST and PUT requests is
>   reflected in the different meaning of the Request-URI. The URI in a
>   POST request identifies the resource that will handle the enclosed
>   entity. That resource might be a data-accepting process, a gateway
>   to some other protocol, or a separate entity that accepts
>   annotations.  In contrast, the URI in a PUT request identifies the
>   entity enclosed with the request -- the user agent knows what URI
>   is intended and the server MUST NOT attempt to apply the request to
>   some other resource.  If the server desires that the request be
>   applied to a different URI, it MUST send a 301 (Moved Permanently)
>   response; the user agent MAY then make its own decision regarding
>   whether or not to redirect the request.

And this, BTW, is why (I think) PUT's semantics can't be replaced
with POST-with-connneg.

It's conceivable that a resource will accept POSTs of media type
foo/bar, but also return representations of media type foo/bar upon
GET. Therefore, it's necessary to have an operation that allows one
to change the representations returned as opposed to submitting a
representation for processing.

This is admittedly far-fetched (I have difficulty coming up with an
example), but IMHO that's mostly because of the limitations of
browsers, not the concept of a resource.

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:34
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-16 22:37:04
Subject:Re: [rest-discuss] FYI: XForms and PUT
Message:

> > Actually, that's not quite right.  There's content negotiation to be
> > considered.
> 
> >From 2616 (section 9.6, PUT)
> 
>   The PUT method requests that the enclosed entity be stored under
>   the supplied Request-URI. If the Request-URI refers to an already
>   existing resource, the enclosed entity SHOULD be considered as a
>   modified version of the one residing on the origin server. If the
>   Request-URI does not point to an existing resource, and that URI is
>   capable of being defined as a new resource by the requesting user
>   agent, the origin server can create the resource with that URI. 
>   [...]
> 
> This seems to imply that in the case of PUT, the Web *is* a
> filesystem ("be stored under").

It's unclear.  I'd agree with what's written iff the resource in
question was known to be a variant of some other resource.  But I've
almost thought that invoking PUT on a known variant resource is bad
practice - why not just PUT to the non-variant (primary) resource?
Hmm, maybe because variants are most likely to be cacheable?

Anyway you look at a set of variant resources though, if you effect
a state change on one, the others should all change.  From a cache
validity POV, the important thing is that the cache knows what
the variants are (which Content-Location would have told it, if it
was paying attention).

>   If the request passes through a cache and the Request-URI identifies
>   one or more currently cached entities, those entries SHOULD be
>   treated as stale. Responses to this method are not cacheable.
> 
> So this blows away the caching arguments; in that sense, it's
> equivalent to POST.

I don't think so.  It says that the request invalidates whatever's
already in the cache, which is a given.  It also says that the response
to the PUT is not cacheable, which is fine because side effects are
involved.  It doesn't say that the request entity can't be used as
a cached request response, though I know that this isn't default
behaviour and that you'd have to futz with Cache-Control (though
I haven't looked into how you'd do this).

>   The fundamental difference between the POST and PUT requests is
>   reflected in the different meaning of the Request-URI. The URI in a
>   POST request identifies the resource that will handle the enclosed
>   entity. That resource might be a data-accepting process, a gateway
>   to some other protocol, or a separate entity that accepts
>   annotations.  In contrast, the URI in a PUT request identifies the
>   entity enclosed with the request -- the user agent knows what URI
>   is intended and the server MUST NOT attempt to apply the request to
>   some other resource.  If the server desires that the request be
>   applied to a different URI, it MUST send a 301 (Moved Permanently)
>   response; the user agent MAY then make its own decision regarding
>   whether or not to redirect the request.
> 
> This *seems* to limit the effects of a PUT to the identified
> resource, as well as support the 'filesystem' view. This also
> theoretically makes the 'accept=...' hacks even hackier, because a
> PUT would indeed affect the state of other resources (i.e., the
> resource identified with the accept=... hack, vs. the one identified
> w/o it). Which means tha tthe accept=... hack shouldn't be available
> on PUTed requests; only POSTs (which can use a method=... hack).

I agree.  I don't like that wording.  Though what it says is mostly
true, it's a bit misleading because it chooses to avoid defining the
meaning of PUT independant of the Request-URI, which can be done.
If you consider the Request-URI always identifies the resource upon
which the method applies, then the meaning of PUT and POST can easily
be defined in those terms. i.e. PUT = replace or create the identified
resource, POST = submit/add to the identified resource.

>   HTTP/1.1 does not define how a PUT method affects the state of an
>   origin server.
> 
> I'd like to know what the intent of this is; it doesn't say state of
> the *resource*, but state of the *origin server*.

Yah, me too.

>   Unless otherwise specified for a particular entity-header, the
>   entity-headers in the PUT request SHOULD be applied to the resource
>   created or modified by the PUT.
> 
> And this seems to cover conneg. I read this as saying "if it has a
> 'Content-Foo: bar' request header, negotiate subsequent GETs as if
> it's Foo is bar." This view seems to be supported by:
> 
>   The recipient of the entity MUST NOT ignore any Content-*
>   (e.g. Content-Range) headers that it does not understand or implement
>   and MUST return a 501 (Not Implemented) response in such cases.

Right.  No problem there.  That's where my Subject-is-Representation
header would come in handy too.  No need to assume an entity header
starts with "Content-";

http://internet.conveyor.com/RESTwiki/moin.cgi/HttpAndTheSemanticWeb 

MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:35
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-17 01:34:51
Subject:asynch
Message:

I have been fooling around with asynch services lately, and of course an
important issue is HTTP.  What I'm going to write here is a fairly rambling note
to explore related issues.  I am hoping that others will help tease apart the
issues, which I have found interesting but easy to get lost in.

Asynch mode matters a lot.  We can't live without it.

Asynch HTTP is a funny idea.  There seem to be incompatibilities large and
small.

Without asynch HTTP, there is no asynch REST.  That is not acceptable.

Asynchronous infrastructure is nearly always too optimistic about the time
frame -- a coherent thread of messages is assumed to be complete within the
lifetime of a sending application.  In reality the lifetimes of messages and
processes are different things.  Furthermore, asynch infrastructure is limited
in scope and generality.  Aside from email, asynch infrastructure is an anarchic
bag of incompatible technologies like JMS/RMI, proprietary real time financial
data protocols, the Gnutella protocol, SOAP 1.2, Jxta, etc ad infinitum.

HTTP and email share a basket of technologies, mainly MIME but also the end to
end principle and many similar semantics.  It is straightforward to model SMTP
in terms of HTTP, and not extremely hard to model HTTP in terms of SMTP.  Given
that the output of a series of SMTP commands is a MIME message, you can think of
it as a marginally different animal.  The biggest difference is that SMTP lacks
syntactic support for the HTTP target URI header line, as well as having no
semantic equivalent.

POP3 does a clean job of diffentiating a message store from its contents.
...less so IMAP, which integrates the semantics of text messaging and
store-and-forward.

If the basic message of REST is that, per Jeff Bone, "the *existing*
Web and its abstractions and mechanisms --- if used properly ---
obviate the need for a large number of the things people seem dead-set
on creating new mechanisms to do", the exact same argument applies to
efforts to create a newly asynchronous HTTP, which existing email
infrastructure obviates much of the need for.  Asynchronous REST
implies email for the same reasons that synchronous REST implies the
web.

HTTP proxy semantics and SMTP forwarder semantics clash.  SMTP intermediaries
and endpoints are basically symetrical, while HTTP intermediaries have a
dedicated role and command set.

...my inclination is to work on mashing together HTTP and SMTP.  Thoughts why
this might be a blind alley?  Is there any interest in shared hacking on such a
project?














-----------------------------------------------------------------------------------
Post ID:36
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-17 01:48:38
Subject:Re: [rest-discuss] asynch
Message:

> HTTP proxy semantics and SMTP forwarder semantics clash.  SMTP intermediaries
> and endpoints are basically symetrical, while HTTP intermediaries have a
> dedicated role and command set.
> 
> ...my inclination is to work on mashing together HTTP and SMTP.  Thoughts why
> this might be a blind alley?  Is there any interest in shared hacking on such a
> project?

Do you believe that email is asynchronous because it arrives without a
request going out for it?  If so, how is that any different from an HTTP
message arriving without prompting (i.e. if you're the web server).

For the record, I'm all for introducing asynchronous notifications into
HTTP.  I'll just refrain from suggesting how it should be done until I
understand what you're asking, lest I confuse things by introducing a
solution too early.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:37
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-17 01:57:22
Subject:RE: [rest-discuss] asynch
Message:

> Do you believe that email is asynchronous because it arrives without a
> request going out for it?

No.  I believe that it is asynchronous -- much moreso than HTTP -- because it
has broad support for the whole gamut of issues that come up with regard to
asynchronicity.  For example, it fixes the issue of message lifetimes being out
of synch with process lifetimes; it supports dynamically determined routing
paths; forwarders know to retry over some fairly long interval; via POP it has
strong support for transient nodes; it has a reply-to header for activating
callbacks; implementations already handle much longer message lifetimes by
writing them to disk; it has POP3 to support the semantics of message stores; it
has a broad deployed base of forwarders and temporary storage depots.

> For the record, I'm all for introducing asynchronous notifications into
> HTTP.  I'll just refrain from suggesting how it should be done until I
> understand what you're asking, lest I confuse things by introducing a
> solution too early.

Please do introduce and suggest.










-----------------------------------------------------------------------------------
Post ID:38
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-17 02:55:59
Subject:Re: [rest-discuss] asynch
Message:

> No.  I believe that it is asynchronous -- much moreso than HTTP -- because it
> has broad support for the whole gamut of issues that come up with regard to
> asynchronicity.  For example, it fixes the issue of message lifetimes being out
> of synch with process lifetimes; it supports dynamically determined routing
> paths; forwarders know to retry over some fairly long interval; via POP it has
> strong support for transient nodes; it has a reply-to header for activating
> callbacks; implementations already handle much longer message lifetimes by
> writing them to disk; it has POP3 to support the semantics of message stores; it
> has a broad deployed base of forwarders and temporary storage depots.

To me, none of those are specifically asynchronous issues.  They're
mostly stateless issues.  And HTTP satisfies each of them (ok, we need a
reply-to header - see below).  This is important because it explains why
what I have below is so simple.

> > For the record, I'm all for introducing asynchronous notifications into
> > HTTP.  I'll just refrain from suggesting how it should be done until I
> > understand what you're asking, lest I confuse things by introducing a
> > solution too early.
> 
> Please do introduce and suggest.

Let me start by saying that REST, like all architectures, works by
placing restrictions on component interaction.  The fundamental REST
restriction is that interactions are limited to semantics that apply
to things with identity, aka resources.

So the question is (assuming we've already decided we need asynch 8-),
when do things with identity need to send event notifications?

The answer that KnowNow came up with is "When they change state".  I
haven't kept up with what they've been implementing, but I recall
talking with Rohit about a "WATCH" method (Roy suggested the name).

It works this way (I'm not saying KnowNow does this, only this is
how it could work - there may be better ways too, but the request
line won't change);

WATCH http://www.yahoo.com HTTP/1.1
Reply-To: http://mysite.org/yahoo-watch

This is a request to the resource to notify the Reply-To URI (via POST)
when www.yahoo.com changes state.  *What* the notification looks like
is up for grabs, there are lots of possibilities and the request can
be configured to ask for something specific (e.g. a delta encoding,
just the URI, a full representation, etc..).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:39
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-17 07:42:32
Subject:Re: [rest-discuss] Re: The woes of conneg (was: RESTifying)
Message:

So, I'm inclined to make the jpg a subresource (along with other
attributes), but this leaves me with a bit of a headache; how do I
identify an HTML-editable version of the resource? If I make it
another subresource, e.g.,
  .../thePerson/editform
there's the (theoretical) possibility of a namespace clash. So, I can
either define sub-sub-resources
  .../thePerson/attr/jpegPhoto
  .../thePerson/other/editform
which is icky, or I can use a query arg or attribute;
  .../thePerson?repr=editform  --or--
  .../thePerson;editform

In combination with the method and conneg hacks, then, I could have
  .../thePerson?repr=editform&method=PUT&accept=text/xml
(not really applicable to this representation, but you get the idea)

I think I like using a parameter best; is there any semantic
difference worth noting (from a REST standpoint) between query args
and parameters?

Regarding putting the DN in the URI; I was concerned about
typability, etc., until it occured to me earlier today that I could
have a "typeable" interface optimised for people hand-typing URIs,
jsut as there's a search interface optimised for HTML form
submission; e.g.,
  http://addresses.example.org/name/Mark+Nottingham
or somesuch.



On Wed, Jan 16, 2002 at 08:01:03AM -0000, mdierken wrote:
> 
> > 
> > Of course, conneg is still useful to expose, but lack of support in
> > browsers means that another means of doing this -- probably with
> > query strings (or maybe path parameters?) -- will have to be hacked.
> > 
> > *sigh* 
> 
> I've used the ?method= approach for a couple years (actually used 
> do:method for collision avoidance) to tunnel methods. I've also used ?
> accept= to tunnel Accept headers.
> 
> Why not use the LDAP dn in the URL?
> For example, I wrote a servlet a while back to do stuff like this:
> 
> http://www.xmldatasource.com:7779/xds/ldap2xml/
> 
> http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/
> uid=myxie/
> 
> http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/
> uid=myxie/?do:accept=text/xml
> 
> Mike
> 
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:40
Sender:"mdierken" <mdierken@...>
Post Date/Time:2002-01-17 08:01:08
Subject:Re: asynch
Message:

> So the question is (assuming we've already decided we need asynch 8-
),
> when do things with identity need to send event notifications?
> 
> The answer that KnowNow came up with is "When they change state".  I
> haven't kept up with what they've been implementing, but I recall
> talking with Rohit about a "WATCH" method (Roy suggested the name).
> 
> It works this way (I'm not saying KnowNow does this, only this is
> how it could work - there may be better ways too, but the request
> line won't change);
> 
> WATCH http://www.yahoo.com HTTP/1.1
> Reply-To: http://mysite.org/yahoo-watch
> 
> This is a request to the resource to notify the Reply-To URI (via 
POST)
> when www.yahoo.com changes state.  *What* the notification looks 
like
> is up for grabs, there are lots of possibilities and the request can
> be configured to ask for something specific (e.g. a delta encoding,
> just the URI, a full representation, etc..).
> 

Yes - this is the basic idea. They use 'route' rather than 'watch'.
There are other magic bits in there also (like a javascript client 
that receives via persisitent response, kn_expires, 
kn_response_format for content negotiation (they should've 
used 'accept', the weasels)).

One trick that I'm not sure how to accomplish is the identification 
of what the event is 'about' when it is a multi-hop. Is there 
a 'topic' header or something? KN uses kn_routed_from to identify 
that latest URI the message has passed through. (and I don't want to 
hear about using an xml namespace for this... more weasels)

KnowNow docs at:
http://developer.knownow.com/devguide/docs/routers/knrouterapi.html

Setting up a subscription:
http://www.yahoo.com?do_method=route&kn_to=http://mysite.org/yahoo-
watch

They also use kn_id to identify an event - useful for supressing 
duplicates and correlating replies.









-----------------------------------------------------------------------------------
Post ID:41
Sender:"mdierken" <mdierken@...>
Post Date/Time:2002-01-17 08:09:19
Subject:Re: The woes of conneg (was: RESTifying)
Message:

--- In rest-discuss@y..., Mark Nottingham <mnot@m...> wrote:
> 
> In combination with the method and conneg hacks, then, I could have
>   .../thePerson?repr=editform&method=PUT&accept=text/xml
> (not really applicable to this representation, but you get the idea)

Not sure if I understand method=PUT and accept together.
PUT would have a content-type though.

Identifying the editable representation is a bother.
Once I tried uri?method=edit but didn't like that, so ditched it 
before anybody noticed.
Tried uri?layout=editor - moving in the right direction. Kept that 
for a while.

Don't know what to try next. Maybe uri?view=editor - 'view' is a 
wonderfully ambigous noun/verb.

Mike









-----------------------------------------------------------------------------------
Post ID:42
Sender:"mdierken" <mdierken@...>
Post Date/Time:2002-01-17 08:12:14
Subject:Re: The woes of conneg (was: RESTifying)
Message:

--- In rest-discuss@y..., "mdierken" <mdierken@y...> wrote:
> --- In rest-discuss@y..., Mark Nottingham <mnot@m...> wrote:

> Identifying the editable representation is a bother.
> Once I tried uri?method=edit but didn't like that, so ditched it 
> before anybody noticed.
> Tried uri?layout=editor - moving in the right direction. Kept that 
> for a while.
> 
> Don't know what to try next. Maybe uri?view=editor - 'view' is a 
> wonderfully ambigous noun/verb.
> 

Another reason to use 'view' is when accessing a heirchical 
collection of information or a database-like thing it can be fun to 
talk about 'slices' or 'views' thorough a multi-dimensional space.

Although it might not make as much sense when I wake up tomorrow...







-----------------------------------------------------------------------------------
Post ID:43
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-17 15:19:01
Subject:RE: [rest-discuss] asynch
Message:

Mark,

Something like WATCH is definately part of the solution!  But it is only part of
the solution -- there is much new code to be written to make it work.  For
example,

> WATCH http://www.yahoo.com HTTP/1.1
> Reply-To: http://mysite.org/yahoo-watch

You are assuming that this call can be emitted synchronously.  Before the new
WATCH method can solve anything, it has to be received.  What if the caller, the
caller's proxy, or the recipient is temporarily offline?  In the context of
request/response, you only emit calls that make sense if they complete in the
present.  In the context of publish/subscribe you may emit calls that don't have
any results until a fuzzy point in the future, so it may not matter if the call
is emitted immediately.

In the above example, the client should be able to cache the call until it goes
online.  Such a local cache would be just like a local outbox.  That is:
===========
User software has an application-defined need to send a subscription message.
This might be an application subscribing to a stock ticker.  The user software
finds that the user is offline, hence the message can't be sent.  It caches the
message and initiates a polling loop against the remote resource provider.
===========

Notice the similarity with a mail user agent attempting to publish a text
message via email.  The sending application should not do the polling, because
there may be many such sending applications.  Instead the sending application
should submit the send to a system-wide outbound queue and leave the polling to
a single daemon.

===========
An application publishes a subscription message to a stock ticker.  Because the
endpoint is offline, the message is submitted to an outbound queue.  A daemon
minding the queue and polling to discover online mode eventually finds that the
endpoint is online.  However the ticker publisher is not online at that moment.
The daemon submits the subscription event to a third party dropbox maintaned by
the ticker publisher.
===========

Again, these semantics are covered by mail infrastructure already but not by web
infrastructure.

Let's not get bogged down in this slightly wierd point that email is more RESTy
than the web.  The first point is that _sender_ asynchronicity means assuming
that every single hop may be an emission that requires store-and-forward.
KnowNow's architecture requires a special new server, the event router.  What is
an event router but a store-and-forward node?  (uh, well, it's also a topic
coordinator.  That's too big a can of worms for this message.)

- Lucas











-----------------------------------------------------------------------------------
Post ID:44
Sender:"asynch_messaging" <asynch_messaging@...>
Post Date/Time:2002-01-17 17:58:27
Subject:Re: asynch
Message:

> A daemon minding the queue and polling to discover online mode 
> eventually finds that the endpoint is online.  
> However the ticker publisher is not online at that moment.
> The daemon submits the subscription event to a third party dropbox 
maintaned by
> the ticker publisher.
> ===========
> 
Why not publish to that third party dropbox to begin with?

A.M.








-----------------------------------------------------------------------------------
Post ID:45
Sender:"asynch_messaging" <asynch_messaging@...>
Post Date/Time:2002-01-17 18:04:52
Subject:Re: asynch
Message:

> However the ticker publisher is not online at that moment.
> The daemon submits the subscription event to a third party dropbox 
maintaned by
> the ticker publisher.

Is it a subscription 'event' or a subscription 'request'?
To me, an event is a notification that state changed - things will 
still work from the senders point of view if the receiver ignores the 
message. A request is a plea from the sender to make something happen 
and if it isn't possible, let the sender know.

It interesting to note that a 'notify' method isn't needed. You can 
pretty much echo stuff that happens after the subscription to the 
subscribers. But what do you echo? The follow-on requests or the 
responses (considering purely HTTP)? Or both? Or do you only echo a 
request when a success response occurrs?

Fun stuff.











-----------------------------------------------------------------------------------
Post ID:46
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-17 19:20:06
Subject:Re: [rest-discuss] asynch
Message:

Mark Baker wrote:
> 
>...
> 
> WATCH http://www.yahoo.com HTTP/1.1
> Reply-To: http://mysite.org/yahoo-watch
> 

Is there any move to specify this somewhere on the Web? It's a little
unfair for us to tell people that HTTP does everything you need and then
say that we mean: "after adding an HTTP extension."

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:47
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-17 21:19:48
Subject:Re: [rest-discuss] asynch
Message:

> Is there any move to specify this somewhere on the Web? It's a little
> unfair for us to tell people that HTTP does everything you need and then
> say that we mean: "after adding an HTTP extension."

Well, technically, you could do it without a new method.  It just
wouldn't look as pretty;

GET http://www.yahoo.com

response;

HTTP/1.1 200 OK
Properties: http://www.yahoo.com/properties

next invocation;

--
POST http://www.yahoo.com/properties;watch
Content-Type: text/uri

http://myhost.org/yahoo-watch
--

response;

HTTP/1.1 201 Created
Location: http://www.yahoo.com/watch/2342343

this invocation unsubscribes you;

DELETE http://www.yahoo.com/watch/2342343

and then you're unsubscribed.

You'd still need to agree on what a "watch" property is though,
so I guess that still counts as an extension.  Never mind. 8-)

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:48
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-17 21:34:32
Subject:Re: [rest-discuss] asynch
Message:

> Mark,
> 
> Something like WATCH is definately part of the solution!  But it is only part of
> the solution -- there is much new code to be written to make it work.  For
> example,
> 
> > WATCH http://www.yahoo.com HTTP/1.1
> > Reply-To: http://mysite.org/yahoo-watch
> 
> You are assuming that this call can be emitted synchronously.  Before the new
> WATCH method can solve anything, it has to be received.

True, but I don't say *who* has to receive it!

>  What if the caller, the
> caller's proxy, or the recipient is temporarily offline?

Then let the recipient have a proxy that queues up these requests.

>  In the context of
> request/response, you only emit calls that make sense if they complete in the
> present.  In the context of publish/subscribe you may emit calls that don't have
> any results until a fuzzy point in the future, so it may not matter if the call
> is emitted immediately.

Ok.

> In the above example, the client should be able to cache the call until it goes
> online.  Such a local cache would be just like a local outbox.  That is:
> ===========
> User software has an application-defined need to send a subscription message.
> This might be an application subscribing to a stock ticker.  The user software
> finds that the user is offline, hence the message can't be sent.  It caches the
> message and initiates a polling loop against the remote resource provider.
> ===========

Right.  See above.

> Notice the similarity with a mail user agent attempting to publish a text
> message via email.  The sending application should not do the polling, because
> there may be many such sending applications.  Instead the sending application
> should submit the send to a system-wide outbound queue and leave the polling to
> a single daemon.
> 
> ===========
> An application publishes a subscription message to a stock ticker.  Because the
> endpoint is offline, the message is submitted to an outbound queue.  A daemon
> minding the queue and polling to discover online mode eventually finds that the
> endpoint is online.  However the ticker publisher is not online at that moment.
> The daemon submits the subscription event to a third party dropbox maintaned by
> the ticker publisher.
> ===========
> 
> Again, these semantics are covered by mail infrastructure already but not by web
> infrastructure.

You sure about that?

> Let's not get bogged down in this slightly wierd point that email is more RESTy
> than the web.  The first point is that _sender_ asynchronicity means assuming
> that every single hop may be an emission that requires store-and-forward.
> KnowNow's architecture requires a special new server, the event router.  What is
> an event router but a store-and-forward node?  (uh, well, it's also a topic
> coordinator.  That's too big a can of worms for this message.)

Heh.  It's just a web app, nothing more.

Pipeline + statelessness = great (email)
Pipeline + statelessness + generic semantics = awesome (Web)

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:49
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-17 22:25:08
Subject:Async confusion
Message:

I think we're getting a little bit confused re: what async means in this context.
There are at least two orthogonal dimensions of interest:  asynchronous communication
of request and a possible future response stream, and asynchrony -wrt- connectivity at
a given point in time, i.e., the idea that the sender and receiver must be able to
communicate at a given instance, hence must both be online.

The first is simply "callbacks" --- even pub / sub, watching, etc. is a higher-level
metaphor over simple callbacks.  Callbacks have no topological implications / require
no new connector types and --- as Mark points out --- don't even require protocol
extensions.

The second is store-and-forward,  where the sender and receiver need not necessarily
have instantaneous connectivity.  Store-and-forward requires a number of things:  more
complex intermediary services, a notion (at least minimal) of routing, etc.

Just a point of clarification --- these are independent things.  Another interesting
semi-related thing to consider is the impact of communication *assymetry* --- the fact
that sending and receiving roles are not the same as connection initiator and
connection receiver, i.e. "client" and "server."

$0.02

jb


Mark Baker wrote:

> > Mark,
> >
> > Something like WATCH is definately part of the solution!  But it is only part of
> > the solution -- there is much new code to be written to make it work.  For
> > example,
> >
> > > WATCH http://www.yahoo.com HTTP/1.1
> > > Reply-To: http://mysite.org/yahoo-watch
> >
> > You are assuming that this call can be emitted synchronously.  Before the new
> > WATCH method can solve anything, it has to be received.
>
> True, but I don't say *who* has to receive it!
>
> >  What if the caller, the
> > caller's proxy, or the recipient is temporarily offline?
>
> Then let the recipient have a proxy that queues up these requests.
>
> >  In the context of
> > request/response, you only emit calls that make sense if they complete in the
> > present.  In the context of publish/subscribe you may emit calls that don't have
> > any results until a fuzzy point in the future, so it may not matter if the call
> > is emitted immediately.
>
> Ok.
>
> > In the above example, the client should be able to cache the call until it goes
> > online.  Such a local cache would be just like a local outbox.  That is:
> > ===========
> > User software has an application-defined need to send a subscription message.
> > This might be an application subscribing to a stock ticker.  The user software
> > finds that the user is offline, hence the message can't be sent.  It caches the
> > message and initiates a polling loop against the remote resource provider.
> > ===========
>
> Right.  See above.
>
> > Notice the similarity with a mail user agent attempting to publish a text
> > message via email.  The sending application should not do the polling, because
> > there may be many such sending applications.  Instead the sending application
> > should submit the send to a system-wide outbound queue and leave the polling to
> > a single daemon.
> >
> > ===========
> > An application publishes a subscription message to a stock ticker.  Because the
> > endpoint is offline, the message is submitted to an outbound queue.  A daemon
> > minding the queue and polling to discover online mode eventually finds that the
> > endpoint is online.  However the ticker publisher is not online at that moment.
> > The daemon submits the subscription event to a third party dropbox maintaned by
> > the ticker publisher.
> > ===========
> >
> > Again, these semantics are covered by mail infrastructure already but not by web
> > infrastructure.
>
> You sure about that?
>
> > Let's not get bogged down in this slightly wierd point that email is more RESTy
> > than the web.  The first point is that _sender_ asynchronicity means assuming
> > that every single hop may be an emission that requires store-and-forward.
> > KnowNow's architecture requires a special new server, the event router.  What is
> > an event router but a store-and-forward node?  (uh, well, it's also a topic
> > coordinator.  That's too big a can of worms for this message.)
>
> Heh.  It's just a web app, nothing more.
>
> Pipeline + statelessness = great (email)
> Pipeline + statelessness + generic semantics = awesome (Web)
>
> MB
> --
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@...
> http://www.markbaker.ca   http://www.planetfred.com
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:50
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-17 23:52:57
Subject:Asynch and rest-wiki (was Re: [rest-discuss] asynch)
Message:

Mark Baker wrote:
> 
>...
> 
> You'd still need to agree on what a "watch" property is though,
> so I guess that still counts as an extension.  Never mind. 8-)

Anyhow, you get my point. Eventually the REST world needs to standardize
this or agree that HTTP just doesn't handle the problem of asynch. It's
one of the weakest points of REST rhetoric. But there are others. 

On that note, I've modified the REST wiki FAQ with a bunch of common
FAQs. Here are the questions I changed or added.

http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq

====

 ** What do you mean when you say RPC? 

We mean that each developer defines their own methods and makes them
available for remote invocation over the Internet. With this definition,
REST can be said to use RPC, because it defines the methods for the
developers so that they don't have to worry about them. 

Most applications that self-identify as using "RPC" do not adhere to the
REST philosophy. In particular, they use a single URL to represent the
end-point instead of using a multitude of URLs representing every
interesting data object. Then they hide their data objects behind method
calls and parameters, making them unavailable to applications built
around the Web architecture. REST-based services give addresses to every
useful data object and use the resources themselves as the targets for
method calls (typically using HTTP methods). 

 ** Are REST and RPCs incompatible? 

Except for the proviso in the previous FAQ item, and that REST provides
for defining new methods (as long as they operate on resources), then
the answer is yes. REST is incompatible with "end-point" RPC. Either you
address data objects or you address "software components". REST does the
former. End-point RPC does the later. You can try to contort RPC
protocols into working on data object URIs but then you end up
re-inventing a non-standard variant of HTTP. 


 ** Is the concept of Web Services incompatible with REST? 

One answer is that there is no firm definition of WebServices. But REST
seems to be compatible with most of the definitions floating around. It
is not compatible with definitions that take SOAP-RPC as a starting
point. (but then why would you define the problem space around an
implementation technology?) 

Most applications that call themselves "web services" use an end-point
RPC philosopy. 

 ** What if I need to do a GET but my query is not something that can be
fit into a URL? 

MarkBaker has addressed this and defended it in discussion. Someday
somebody should write a more unified discussion of this design and its
defence. But in the meantime, ask yourself how often this problem arises
in real-world situations. GET is restricted to a single-URL line and
that sort of enforces a good design principle that everything
interesting on the web should be URL-addressable. If you want to make a
system where interesting stuff is not URL-addressable then you need to
justify that decision. Typically "contorting" your application around
GET's limitations makes the application better by forcing it into the
web architecture. 

 **  How does HTTP handle reliable delivery? 

Good question...there's an answer but nobody has typed it in yet.
PaulPrescod claims that the gist of it is that reliable delivery is more
of a characteristic of software than of a protocol. After all, there is
no way that some fancy transaction monitoring program like MQSeries can
prevent someone from pulling a network cable out in the middle of a
message. The best it can do is try to re-send the message. This implies
that the protocol can help by having some kind of message-id. HTTP does
need an extension for this. Any volunteers to write this up? 

 ** How does HTTP handle asynchronous delivery?

There is no standardized solution yet. You need an HTTP extension. The
outlines of one were discussed on rest-discuss. Also, you should
probably learn about Adam and Rohit's work on notify.

 **  How does HTTP handle transactions: multiple step commands that are
rolled back together if any one fails? 

Good question...while you wait for an answer let's ask how SOAP, XML-RPC
etc. handle transactions? The answer is mostly: "it is the client's
responsibility". I think that's the REST answer also. The database
concept of transactions does not scale well to the Web because clients
will start transactions and then just forget about them. This doesn't
just tie up server resources: it also has severe locking consequences.
Essentially some other user could be locked out waiting for the
transaction to complete. On the other hand, if the clients take full
responsibility for reversing their own transactions then the server will
not try to do any locking etc. 

 ** Can REST really beat RPC when the whole software industry is pushing
RPC-like solutions? 

If REST works and RPC doesn't then yes, REST can win. Some of us believe
that. Notice how the course of SOAP started as pure RPC and has been
moving further and further away from it? Perhaps that is early evidence
of an industry shift. Also, how many RPC-based web services are really
deployed and in-use on the Web? SOAP and XML-RPC have been around for
years and yet there is no killer app! REST can point to the Web itself
as proof that it works. If you want to see REST used with XML-RPC then
I'd suggest you look at Meerkat, which is a massively scalable
application, incorporating content from hundreds of sites. It does so by
using plain old HTTP. Is there any equivalent SOAP or XML-RPC API that
is widely implemented in an interoperable fashion? It seems the answer
is: "not yet."

 **  What does a REST message look like? 

REST is just an architctural style. HTTP is the protocol that is most in
tune with the style, and the one used by the largest REST application,
the World Wide Web. URIs are the addressing mechanism for that
application. REST can support any media type, but XML is expected to be
the most popular transport for structured information. REST is already
used today with HTML, XHTML, RSS and various proprietary XML
vocabularies. Unlike SOAP and XML-RPC, REST does not really require a
new message format. Just use HTTP and the most appropriate XML
vocabulary! 

 ** I need my app to work with non-HTTP protocols. Does REST still
apply? 

First, are you sure you need your app to work with non-HTTP protocols,
or is that just what you were told? Perhaps if you read the rest of this
page you'll learn to use HTTP in ways that obviate the need for other
protocols. Consider carefully how hard it is to deploy new protocols
across firewalls. If HTTP can be used for instant messaging (Magi),
content management (WebDAV) and P2P (see above) then what did you have
in mind that is outside of its scope? 

Second, if you really do need non-HTTP (e.g. to talk to a village in
Zambia with only UUCP access) then have you considered tunnelling HTTP
over that protocol? HTTP is pretty simple...basically just a couple of
headers and you are done!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:51
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-01-18 03:31:47
Subject:Re: MIME-RPC (was Re: REST)
Message:

On Thu, 17 Jan 2002, Paul Prescod wrote:
> [would you mind moving this to rest-discuss? There was near a FORK
> rebellion last time]

Ok.  On both MIME-RPC and rest-discuss.

> "S. Alexander Jacobson" wrote:
> >
> > On Wed, 16 Jan 2002, Paul Prescod wrote:
> >
> > > "S. Alexander Jacobson" wrote:
> > > >
> > > > Ok.  So, if I want to send a message to an HTTP
> > > > server and have it call back my HTTP server later,
> > > > how do I specify that?
> >
> > I don't think you answered this one at all.
>
> Sorry. http://groups.yahoo.com/group/rest-discuss/message/38

Great.  So the answer is the same as MIME-RPC.
Add another mime header.  As I said before, I
think we are largely in agreement on most things.
I think MIME-RPC formalizes much of the wire
level stuff REST proponents advocate.

The main difference between Reply-To as
described in this message and Reply-To-URL as
described in the MIME-RPC spec is that the later
is suitable for use both in email and in HTTP
while the former only works in HTTP.

The main point of REST seems to be that things
should exist in terms of URIs, but it seems to
insist on only allowing HTTP uris.   Why not allow
HTTPS URIs or mailto uris?

> > I completely agree.  In MIME, that record format
> > is called a "content-type".  MIME even defines a
> > procedure for getting organizations to agree on
> > the name for that type. It is RFC 2048.  With
> > MIME-RPC, you would send e.g.
> >
> > ---
> > content-type: application/x-employee
> >
> > OPAQUE DATA THAT IS INTERPRETED BY A MIME-RPC
> > IMPLEMENTATION IN ACCORDANCE WITH THE SPEC FOR
> > THIS FORMAT -- THE FORMAT MIGHT BE BINARY!!!
> > ---
>
> Okay, but that's just *MIME*. MIME-RPC is adding no value here!

If REST is just using the existing web, then I
would ask the same question of REST.

MIME-RPC simply formalizes common practice
in using MIME for messaging to applications rather
than people.  The value it provides is simply a
formalization of existing practice.

I think REST provides a philosophy. MIME-RPC
provides a wire format.

> >...
> > MIME-RPC encourages #2.  The point is that for
> > massive interoperability, applications need to be
> > able to send each other messages that may include
> > objects of various types packaged together.  MIME
> > is a well defined and well used mechanism for
> > doing exactly that.
>
> Nobody disputes the value of MIME. For a while, even Microsoft was in
> favor...before they invented "DIME". I'm asking about the value of
> MIME-RPC. Adding RPC to MIME is not exciting to a REST-er since REST is
> an alternative model to RPC!

Please define your use of RPC.  My use of RPC is
simply that the recipient of the message is an
application rather than a person.

I think we are in agreement about most things.  I
am just trying to provide a short reference
document for application developers.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax









-----------------------------------------------------------------------------------
Post ID:52
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-18 03:47:21
Subject:Re: MIME-RPC (was Re: REST)
Message:

"S. Alexander Jacobson" wrote:
> 
> 
> Ok.  On both MIME-RPC and rest-discuss.

Okay.

>...
> The main point of REST seems to be that things
> should exist in terms of URIs, but it seems to
> insist on only allowing HTTP uris.   Why not allow
> HTTPS URIs or mailto uris?

HTTPS is REST-compatible.

The problem with mailto is I can't dereference it. I can only send
information to it and the information goes into a black hole. That's
against the REST philosophy. If email were designed according to REST
then every email message would have a globally unique identifier and you
would reply to a message by POSTing to the identifier (which you can't
do with an SMTP unique identifer).

>...
> 
> I think REST provides a philosophy. MIME-RPC
> provides a wire format.

Right, REST is a philosophy. The wire format is already HTTP + MIME +
XML. What does MIME-RPC add?

>...
> Please define your use of RPC.  My use of RPC is
> simply that the recipient of the message is an
> application rather than a person.

This may help:

http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:53
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-18 04:07:59
Subject:Re: [rest-discuss] Re: MIME-RPC (was Re: REST)
Message:

> The problem with mailto is I can't dereference it. I can only send
> information to it and the information goes into a black hole. That's
> against the REST philosophy. If email were designed according to REST
> then every email message would have a globally unique identifier and you
> would reply to a message by POSTing to the identifier (which you can't
> do with an SMTP unique identifer).

Actually, that's not quite true.  Consider telnetting to a mailto/SMTP
HTTP proxy and entering;

  GET mailto:distobj@...

The response could be an HTML email style form (ala Hotmail) with the To
field filled in, a textarea where I type my message, and a submit button
that sends the email.

In fact, I assert that everything that has a URI, has at least one
useful response to a GET.

MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:54
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-18 04:29:55
Subject:MIME-RPC versus the REST+XML architectural style
Message:

======= MIME-RPC example:

POST /some/resource HTTP/1.1
Content-type: application/x-www-form-urlencoded

0=example.getStateName&1=10023

======= REST example:

GET /states/10023 HTTP/1.1

(the response is the same)
======= MIME-RPC example:

POST /some/resource HTTP/1.1
Content-type: application/x-www-form-urlencoded

0=example.getTeam&state=New%20York&sport=Baseball

HTTP/1.1 200 OK
Content-type: multipart/mixed, boundary=B

--B

Yankees
--B

Mets
--B

======= REST (with XML) equivalent:

GET /teams?state=New%20York&sport=Baseball HTTP/1.1

HTTP/1.1 200 OK
<teams xmlns="...someurl.com">
 <team>Yankees</team>
 <team>Mets</team>
</teams>
=======
MIME-RPC:

POST /some/resource HTTP/1.1
Content-type: application/x-www-form-urlencoded

0=example.addUser&fname=Igna%ACio&lname=Sanchez
=======
REST version:

POST /users HTTP/1.1
Content-type: text/plain

Igna Sanchez
=====

Main differences:

 * rather than "wasting" the HTTP URL slot with /some/resource, the
resource is the thing you are acting upon

 * when you're doing something idempotent, use GET, not POST

 * use XML for structuring text rather than MIME. 
   * more compact 
   * easier to read 
   * can use schema for validation

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:55
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-18 04:52:27
Subject:Re: [rest-discuss] Re: MIME-RPC (was Re: REST)
Message:

>
> The problem with mailto is I can't dereference it. I can only send
> information to it and the information goes into a black hole. That's
> against the REST philosophy. If email were designed according to REST
> then every email message would have a globally unique identifier and you
> would reply to a message by POSTing to the identifier (which you can't
> do with an SMTP unique identifer).

Can't I use POP3 to fetch mail given only
mailto:asynch_messaging@... ?







-----------------------------------------------------------------------------------
Post ID:56
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-18 15:55:37
Subject:RE: [rest-discuss] asynch
Message:

> >  What if the caller, the
> > caller's proxy, or the recipient is temporarily offline?
>
> Then let the recipient have a proxy that queues up these requests.

Hmm, you mean that every callback URL would be a queuing front end somewhere.
That queing front end could be a CGI script which writes to a disk file...   Of
course, it's convenient to have that CGI shared by multiple transient endpoints
so that every watch app doesn't require yet another install and datastore....
The datastore in the shared CGI is partitioned by endpoint...  The endpoint
signs in and picks up its messages...  Yup, POP3.

Are there substantial benefits from reconstructing all of SMTP and POP with
HTTP, or can they be considered orthogonal and complementary?

> > Again, these semantics are covered by mail infrastructure already
> but not by web
> > infrastructure.
>
> You sure about that?

Yes.  They can be emulated with HTTP, but haven't yet been.











-----------------------------------------------------------------------------------
Post ID:57
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-01-18 19:19:16
Subject:Re: [MIME-RPC] Re: MIME-RPC (was Re: REST)
Message:

On Thu, 17 Jan 2002, Paul Prescod wrote:
> The problem with mailto is I can't dereference it. I can only send
> information to it and the information goes into a black hole. That's
> against the REST philosophy. If email were designed according to REST
> then every email message would have a globally unique identifier and you
> would reply to a message by POSTing to the identifier (which you can't
> do with an SMTP unique identifer).

You could always create an HTTP service that
provides some data about any mailto uri, but I'm
not sure why you would want to.

In any case, RFC822 says that every mail message
should have a globally unique identifier
(message-id) and that replies should have
"in-reply-to: message-id" in their headers.

What is missing here?

> > I think REST provides a philosophy. MIME-RPC
> > provides a wire format.
>
> Right, REST is a philosophy. The wire format is already HTTP + MIME +
> XML. What does MIME-RPC add?

As I said before, in MIME-RPC, any MIME transport
is the transport (HTTP, HTTPS, SMTP, IMAP, etc).
The wire format is a MIME envelope wrapped
around whatever makes the most sense for your
application (e.g. GIF, JPEG, or Flash rather than
SVG).

The last one is important.  XML does not easily
allow delivery of multiple XML documents or other
opaque data types like graphics or MSOffice files.
MIME is designed to do just that.

It appears to work very well for both email and
the web.

My question is What is REST?  What does it add?
There seems to be no definition only ostensive
descriptions.  Note: sending an XML document over
HTTP is compliant with MIME-RPC.  I just think
that you frequently want to do more.

I am actually beginning to think that MIME-RPC and
REST are orthogonal.  You can use MIME-RPC in
REST-style or not.  It is just that
because MIME-RPC  allows people to do things in
non-REST style, some RESTers might object.

> > Please define your use of RPC.  My use of RPC is
> > simply that the recipient of the message is an
> > application rather than a person.

> http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq

Ok.  I read this and think we are in agreement.
MIME-RPC does not require use of method names.  It
really just presumes that people are sending data
structures to one another.  In the spec, method
names and arguments are nothing more than
elements of a struct.  If application developers
want to interpret that struct as a command, they
are free to do so.  If they want to interpret it
as a message advising them of something, that is
ok too.

I think that MIME-RPC supports both REST and
non-REST styles.  I like REST style, I just don't
think I always want to use it and I think that
frequently people want a more easy to use
abstraction of their code.  MIME-RPC supports them
either way.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax











-----------------------------------------------------------------------------------
Post ID:58
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-18 19:24:56
Subject:Re: [rest-discuss] asynch
Message:

Let me see if I have internalized the REST philosophy....

Lucas Gonze wrote:
> 
>...
> 
> Are there substantial benefits from reconstructing all of SMTP and POP with
> HTTP, or can they be considered orthogonal and complementary?

There are benefits to reconstructing stuff.

Reason #1. It is bad to have useless silos of functionality. Why should
SMTP have some features and REST other features unless there is some
reason that the two features do not coexist naturally. For instance,
there is HTTPS but as far as I know, there is no POPS. So I had to set
up SSL-based POP "manually". And I can't depend on it being available in
an application. If POP was HTTP then "POPS" would be avaialable
everywhere.

Reason #2. The web is organized around URI addresses. HTTP is the only
protocol that is similarly organized. You could make a URI-centric SMTP
or POP but it would be just as hard as adding async infrastructure to
HTTP software but you'd be left with problem #1.

Reason #3. We're computer scientists. Overgeneralizing is what we do.

Of course SMTP and POP are not going away. But if we're building new
asych apps then yes, I'm going to follow the party line and say that
asynch HTTP are the way to go. And the sooner we clarify that the
better. Could someone inform me what happened here:

http://groups.yahoo.com/group/notification/

 and here:

http://www.cs.caltech.edu/~adam/isen/bof-charter-bash/

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:59
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-18 19:30:02
Subject:Re: [rest-discuss] Re: [MIME-RPC] Re: MIME-RPC (was Re: REST)
Message:

> My question is What is REST?  What does it add?

It adds the methods so you don't have to.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:60
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-01-18 20:14:53
Subject:Re: [MIME-RPC] MIME-RPC versus the REST+XML architectural style
Message:

Paul,

Your structuring your MIME-RPC examples to be
harder to read and biasing the discussion.

The MIME-RPC state name request looks like this:

   POST /states HTTP/1.1

   10023

It is not obvious that this is substantially
simpler than the REST

   GET /states/10023 HTTP/1.1

I am also thinking about ammending the MIME-RPC
spec to note that, by convention HTTP
applications allow urlencoded bodies to be passed
in a querystring when the method is GET, so
MIME-RPC implementations should as well.

Then a MIME-RPC request could look like this:

   GET /states?10023 HTTP/1.1

Do you think these differences are substantive?

(The reason I prefer to use name/value in my
applications is that it allows web browsers to
interact with your application directly.  You pay
with some ugliness to support web browsers.  Such
is life.)

You also said:
> (the response is the same)

Note true.  The simple MIME-RPC response:

   HTTP/1.1 200 OK

   New York

In contrast, the REST would be:

    HTTP/1.1 200 OK
    Content-type: text/xml; charset=utf-8

    <state xmlns="http://foo.com/bar/namespace">New York</state>

The MIME-RPC response is much simpler.  The client
is not required to parse XML and resolve a
namespace just to get at the answer.

The same arguments apply to your other examples
so I won't expand on them here.  Nothing in
MIME-RPC stops you from delivering an a text/xml
as a response rather than a multipart/mixed.  I
think it depends on the application which makes
the most sense.

>  * rather than "wasting" the HTTP URL slot with /some/resource, the
> resource is the thing you are acting upon

This is a poor argument.  see above.

>  * when you're doing something idempotent, use GET, not POST

I now realize that REST seems to want a new
protocol that isn't either HTTP/1.0 or HTTP/1.1.

Claim: idempotent requests should use GET

Reality: Many idempotent requests, e.g. SQL
database queries, can't be sent with GET, because
they are too large or entail too much structure.

Claim: REST supports asynchronous messaging

Reality: REST appears to require use of HTTP and
HTTP does not support asynchronous requests.

Claim: Applications should define new HTTP methods

Reality: This is very difficult to deploy for many
users and there is no standards process for
defining these methods (limiting interop).

Of course real life HTTP deployments may change
and maybe the HTTP spec will evolve, but, right
now, the REST you describe appears to be
incompatible with deployed infrastructure.

>  * use XML for structuring text rather than MIME.
>    * more compact
>    * easier to read

Very debatable.  In the states example, the
MIME-RPC response was easier to read and shorter.
In the baseball example, the multipart/mixed
actually had fewer characters than the text/xml
exampe.  Readability is in the eye of the
beholder.

>    * can use schema for validation

When that is relevant to your application,
MIME-RPC does not prevent you from using XML.
However, in the states and baseball examples, I
don't think the validation is so useful.
(Note: I a putting aside for the moment, my
general doubts about schema validation technology)

MIME-RPC gives you the flexibility to do what you
need to do.  When you need to talk to web
browsers, it supports you.  When you want RPC, it
supports you.  When you want to do asynchronous
messaging, it supports you.  When you want to do
REST, it suppports you as well.

I guess I just think that there are times when
REST is incompatible with your needs, but MIME-RPC
helps you.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax









-----------------------------------------------------------------------------------
Post ID:61
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-18 20:34:30
Subject:Re: [rest-discuss] asynch
Message:

> There are benefits to reconstructing stuff.

[snipped reasons]

Yes, excellent reasons.  I'd add one more important one;

Reason #4; optimizations are for the general case

> better. Could someone inform me what happened here:
> 
> http://groups.yahoo.com/group/notification/
> 
>  and here:
> 
> http://www.cs.caltech.edu/~adam/isen/bof-charter-bash/

I was following it, and attended the first BOF in Chicago.  There was a
large turnout, but no followup, and nobody driving it hard.   It might
have had something to do with how vague the first BOF was with respect
to the scope of the work.  About a year after that, Adam & Rohit formed
KnowNow and actually implemented it.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:62
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-18 21:58:13
Subject:Re: [rest-discuss] Re: [MIME-RPC] MIME-RPC versus the REST+XML architectural style
Message:


"S. Alexander Jacobson" wrote:

> Note true.  The simple MIME-RPC response:
>
>    HTTP/1.1 200 OK
>
>    New York
>
> In contrast, the REST would be:
>
>     HTTP/1.1 200 OK
>     Content-type: text/xml; charset=utf-8
>
>     <state xmlns="http://foo.com/bar/namespace">New York</state>

Wrong.  Show me where in any of the HTTP spec it says that response bodies
are any particular content-type or content-encoding?!  REST applications may
use XML, but there's certainly no requirement there.  Even the use of the
content-type header is a SHOULD, not a MUST.  (In cases where it's not
provided, clients MAY use heuristics to attempt to guess, and if the
content-type remains unknown it SHOULD be treated as type
"application/octet-stream."  Cf. rfc2616, Section 7.2.1.)

Bottom line, the body belongs to the particular application, not HTTP
itself.  And this is as it should be.

> The client
> is not required to parse XML and resolve a
> namespace just to get at the answer.

That's true for REST as well.

> The same arguments apply to your other examples
> so I won't expand on them here.  Nothing in
> MIME-RPC stops you from delivering an a text/xml
> as a response rather than a multipart/mixed.  I
> think it depends on the application which makes
> the most sense.

Likewise for REST.

> I now realize that REST seems to want a new
> protocol that isn't either HTTP/1.0 or HTTP/1.1.

No, it just asserts that the semantics of HTTP are already rather
well-defined, and just wishes that people would understand (a) that fact, and
(b) the generality afforded by the already-specified semantics.

> Claim: idempotent requests should use GET
>
> Reality: Many idempotent requests, e.g. SQL
> database queries, can't be sent with GET, because
> they are too large or entail too much structure.

This is troublesome, and it's been argued (by me, among others, before I
really "got" REST) that GET should be extended to include this
functionality.  But that's really not the right answer --- doing so would
require changes to the HTTP infrastructure, requiring that HTTP itself take
on the task of understanding at some semantic level the object
representations that it transfers.

A reasonable position for REST to take is this:  idempotent requests which
are "too large" to be effectively URL encoded in a reasonable way probably
imply that the resources of the application aren't modeled and exposed
correctly.  I.e., the only reason you need that much data in an idempotent
operation would be if you were tunneling some other "protocol" (using the
term loosely) with some other view of the world (i.e., relational model, SQL
being tunneled) through HTTP.  The REST position is therefore that you need
to remodel your application to fit the HTTP model and thereby get all the
goodness of HTTP, rather than using it as a "dumb" conduit to tunnel other
protocols and map to other object models.  *Fully expose your application as
resources that conform to the generic semantics of HTTP.*

> Claim: REST supports asynchronous messaging
>
> Reality: REST appears to require use of HTTP and
> HTTP does not support asynchronous requests.

This is (a) incorrect, as we've already stated, and (b) rather ludicrous
anyway.  Asynchrony as an application communication pattern doesn't require
an asynchronous communication protocol --- if it did, it wouldn't be possible
to build asynchronous applications with i.e. ONC RPC, CORBA, etc.  But we do
just that.  Syncronous request-response protocols are sufficient for building
asynchronous messaging on top of, and vice-versa --- both models are fully
general.

In HTTP, you would simply do asynchronous communication as callbacks:  a
request supplies, potentially in an URL-encoded fashion, the URI to which
responses should be sent at a later date.  Responses are then passed back via
later HTTP methods invoked on the callback resource.

We *do* need some conventional ways for doing this, but it should be noted
that there are *many* kinds of asynchrony that are interesting to different
applications.  For some apps, simple one-shot callbacks are sufficient.  For
others such as pub-sub, "persistent" callbacks are needed.  All of these and
more styles of communication are trivially built atop the existing HTTP
infrastructure with *no changes at all.*  A little bit of care must however
be exercised in order to ensure that you don't break the overall semanics of
HTTP, i.e. caching, etc.  And even though all of this is trivially possible
*today,* some cases may be common enough that extensions to the set of HTTP
methods might be reasonable optimizations.

> Claim: Applications should define new HTTP methods
>
> Reality: This is very difficult to deploy for many
> users and there is no standards process for
> defining these methods (limiting interop).

Reality:  REST doesn't claim that applications should add to the HTTP method
set.  (BTW, that was my loudest and most passionate objection to REST before
I "got it.")  The REST claim is that almost anything you can think of doing
can be trivially recast within the context of HTTP's general, powerful
methods.  (Atomic read+delete is an example of one possible missing method,
but there aren't many of them.)

Think about it this way:  the limited HTTP method set is analogous to the
limited file IO interface in UNIX.  And just as those interfaces have proven
*incredibly* flexible and powerful --- almost anything can be recast as file
IO and stream operations, cf. Plan 9 --- so is the limited HTTP method set
more flexible and powerful than it may appear at first glance.

>
> Very debatable.  In the states example, the
> MIME-RPC response was easier to read and shorter.
> In the baseball example, the multipart/mixed
> actually had fewer characters than the text/xml
> exampe.  Readability is in the eye of the
> beholder.

Again, REST is in no way married to XML.  Neither is it antagonistic to XML.

> I guess I just think that there are times when
> REST is incompatible with your needs,

Such as...?

jb








-----------------------------------------------------------------------------------
Post ID:63
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-18 22:09:47
Subject:[rest-discuss] asynch
Message:

Counter-reasons follow, but almost purely for the sake of debate:

#1: It is bad to reinvent the wheel.

#2: Reinventing the wheel is likely to fail, as there is little market niche
available.

#3: Why bother figuring out how to merge wheels and boxes when you can put them
together and have a car?  Is it possible to bolt HTTP and SMTP together in a way
that minimizes integration work?

#4: If optimizations are for the general case, email wins.  It's much more
general.

#5: If a URI-centric SMTP makes no sense, that is evidence that SMTP and HTTP
are orthogonal.


Why "almost purely for the sake of debate"?  Because it's too soon to be
commenting on solutions.  There is not yet:
* a convincing case that asynch is needed
* usecases
* a requirements list
* serious implementation proposals











-----------------------------------------------------------------------------------
Post ID:64
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-18 23:25:23
Subject:Re: [rest-discuss] asynch
Message:

http://www.cs.caltech.edu/~adam/isen/bof-charter-bash/

Adam & Rohit started KnowNow - http://www.knownow.com

Asynch messaging over HTTP. There is a Python library so you might be interested...





-----------------------------------------------------------------------------------
Post ID:65
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-18 23:41:07
Subject:Re: [rest-discuss] asynch
Message:

> > Then let the recipient have a proxy that queues up these requests.
> 
> Hmm, you mean that every callback URL would be a queuing front end somewhere.

I was thinking of queueing up outgoing subscriptions, but this could
also be used.

> That queing front end could be a CGI script which writes to a disk file...   Of
> course, it's convenient to have that CGI shared by multiple transient endpoints
> so that every watch app doesn't require yet another install and datastore....
> The datastore in the shared CGI is partitioned by endpoint...  The endpoint
> signs in and picks up its messages...  Yup, POP3.

Sure, but showing that HTTP semantics trump those of POP3.

> Are there substantial benefits from reconstructing all of SMTP and POP with
> HTTP, or can they be considered orthogonal and complementary?

See Paul's response.

> > > Again, these semantics are covered by mail infrastructure already
> > but not by web
> > > infrastructure.
> >
> > You sure about that?
> 
> Yes.  They can be emulated with HTTP, but haven't yet been.

I don't recall which ones we were talking about, but HTTP has a lot of
goodies that you might have missed if you weren't looking for them.

-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:66
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-19 02:37:09
Subject:Re: [MIME-RPC] MIME-RPC versus the REST+XML architectural style
Message:

"S. Alexander Jacobson" wrote:
> 
> Paul,
> 
> Your structuring your MIME-RPC examples to be
> harder to read and biasing the discussion.

I believe that I cut and pasted all of those MIME-RPC examples from your
examples pages!

> The MIME-RPC state name request looks like this:
> 
>    POST /states HTTP/1.1
> 
>    10023

Not according to this URL:

http://www.mime-rpc.com/examples.html

> It is not obvious that this is substantially
> simpler than the REST
> 
>    GET /states/10023 HTTP/1.1

It may not be much more complicated. But it is less correct. If you are
GET-ting information you should use GET. That's useful for caching and
firewalls.

> I am also thinking about ammending the MIME-RPC
> spec to note that, by convention HTTP
> applications allow urlencoded bodies to be passed
> in a querystring when the method is GET, so
> MIME-RPC implementations should as well.
> 
> Then a MIME-RPC request could look like this:
> 
>    GET /states?10023 HTTP/1.1
> 
> Do you think these differences are substantive?

No. Now you're catching on to REST. But if that request doesn't use the
MIME-RPC header and doesn't use any MIME-RPC conventions then how is it
MIME-RPC? It looks like HTTP to me!

> (The reason I prefer to use name/value in my
> applications is that it allows web browsers to
> interact with your application directly.  You pay
> with some ugliness to support web browsers.  Such
> is life.)

Understood. I've been arguing that XForms should allow the construction
of any form of URL, even /states/10023.

> You also said:
> > (the response is the same)
> 
> Note true.  The simple MIME-RPC response:
> 
>    HTTP/1.1 200 OK
> 
>    New York
> 
> In contrast, the REST would be:
> 
>     HTTP/1.1 200 OK
>     Content-type: text/xml; charset=utf-8
> 
>     <state xmlns="http://foo.com/bar/namespace">New York</state>

No. REST does not require XML. REST was invented before XML. I
personally encourage the use of XML for *structured* data.

>...
> >  * rather than "wasting" the HTTP URL slot with /some/resource, the
> > resource is the thing you are acting upon
> 
> This is a poor argument.  see above.

You don't seem to understand that this is the *core idea of REST*. It is
also the core idea of the Web. You say that you are just formalizing
existing web conventions but your examples don't use GET to mean GET.

>...
> Claim: idempotent requests should use GET
> 
> Reality: Many idempotent requests, e.g. SQL
> database queries, can't be sent with GET, because
> they are too large or entail too much structure.

Show me a SQL database query that is incompatible with Python's
urllib.urlencode. Jeff Bone's answer is more nuanced. Why are you trying
to do SQL over the Web. The Web has a different data model than a
relational database. Use the web's data model.

> Claim: REST supports asynchronous messaging
> 
> Reality: REST appears to require use of HTTP and
> HTTP does not support asynchronous requests.

I'll leave that to Jeff Bone.

> Claim: Applications should define new HTTP methods
> 
> Reality: This is very difficult to deploy for many
> users and there is no standards process for
> defining these methods (limiting interop).

This issue is more subtle. You can use REST with only the methods GET
and POST. That's what most web sites do already. You can also define new
methods if you really feel it important to do so (rare, but not unheard
of). You can also do hacky workarounds. If MIME-RPC documented its
syntax as a workaround for applications that don't properly support HTTP
method extension then I would be more happy with it. One could build a
generic translator that hid the hackiness from the underlying
application.

>...
> Very debatable.  In the states example, the
> MIME-RPC response was easier to read and shorter.

Not true, as I discussed above.

> In the baseball example, the multipart/mixed
> actually had fewer characters than the text/xml
> exampe.  Readability is in the eye of the
> beholder.

If you say so...the XML sure looked easier to read to me.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:67
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-19 02:46:41
Subject:Re: [rest-discuss] Re: MIME-RPC (was Re: REST)
Message:

Asynch Messaging wrote:
> 
> ...
> 
> Can't I use POP3 to fetch mail given only
> mailto:asynch_messaging@... ?

What in the URL tells you that POP3 is available? Also, is fetching mail
the same as addressing a resource? It sounds like "RPC thinking". You
have a single end-point and you send it messages. Web-thinking is that
every resource (i.e. email message!) represents an endpoint and you send
*them* HTTP messages. That's why I still don't think that "mailto:" is
particularly REST-y. Arguably a better name is "mailbox:" and then
you're addressing the mailbox but it is an incredibly course-grained
object. You would hardly ever do a GET, DELETE or PUT. That means it is
like a SOAP endpoint that you can only do POST on. So once again it is
very RPC-like.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:68
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-19 02:47:56
Subject:Re: [rest-discuss] Re: [MIME-RPC] Re: MIME-RPC (was Re: REST)
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> In any case, RFC822 says that every mail message
> should have a globally unique identifier
> (message-id) and that replies should have
> "in-reply-to: message-id" in their headers.

How do I dereference those identifiers? If I can't put an identifier in
a browser URL bar and expect to get some set of bytes back then I don't
personally think it is really REST-y. But then REST is just a philosophy
so there will be differences of opinion on that. I would say that
message-id's should be HTTP URLs that dereference to the message
contents and that ACLs should be used to say who can and cannot see it.
Archives of messages (e.g. egroups) could add a header

orig-message-url: http:// ....

I'm just making this up as I go along. I'm not claiming to be a REST
guru.

>...
> As I said before, in MIME-RPC, any MIME transport
> is the transport (HTTP, HTTPS, SMTP, IMAP, etc).
> The wire format is a MIME envelope wrapped
> around whatever makes the most sense for your
> application (e.g. GIF, JPEG, or Flash rather than
> SVG).
> 
> The last one is important.  XML does not easily
> allow delivery of multiple XML documents or other
> opaque data types like graphics or MSOffice files.
> MIME is designed to do just that.

It is easy to set up an HREF from an XML document to a MIME. I don't
know whether SOAP does it intelligently or not. In Python it would take
me a couple of lines to get from an HREF to a MIME part so I don't know
what MIME-RPC adds.

>...
> My question is What is REST?  What does it add?
> There seems to be no definition only ostensive
> descriptions.  

REST is the architecture of the web. What does it add? The Web. If you
use the Web in the way it was designed then you get applications that
are easier to maintain, scales better and generally works better. In
your MIME-RPC examples you use POST to do a getStateName. I know you're
just copying the XML-RPC examples but the point is that if you rethought
it in terms of the web's native architecture (and use GET) you'd get
better caching, smaller messages, simpler messages and you'd find that
all of the specs you need are *already in place* so there is no need for
another spec.

GET /states/41/name HTTP/1.1

It just works. There is no need for another spec.

> I am actually beginning to think that MIME-RPC and
> REST are orthogonal.  You can use MIME-RPC in
> REST-style or not.  

Yes, but when you use it in the REST-style I think it is just called
"MIME". The RPC part falls away. The type marshaling is not necessary if
you use externally defined custom XML vocabularies. The function naming
part is not necessary because REST doesn't have function calls.

There's nothing wrong with RPC if it meets your needs. And MIME-RPC
seems a good way to do RPC if you are trying to avoid defining an XML
vocabulary. But I haven't yet seen how a REST web application would take
advantage of any of the MIME-RPC conventions.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:69
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-19 06:24:52
Subject:Re: [rest-discuss] Re: MIME-RPC (was Re: REST)
Message:



> Asynch Messaging wrote:
> >
> > ...
> >
> > Can't I use POP3 to fetch mail given only
> > mailto:asynch_messaging@... ?
>
> What in the URL tells you that POP3 is available? Also, is fetching mail
> the same as addressing a resource? It sounds like "RPC thinking".
Ouch.

> You
> have a single end-point and you send it messages. Web-thinking is that
> every resource (i.e. email message!) represents an endpoint and you send
> *them* HTTP messages. That's why I still don't think that "mailto:" is
> particularly REST-y. Arguably a better name is "mailbox:" and then
> you're addressing the mailbox but it is an incredibly course-grained
> object.
That's what I was getting at. Since e-mail doesn't have a single protocol
for all operations (SMTP to post, IMAP or POP to get), I thought maybe a
user-agent could infer 'mailto' meant 'try imap or pop if doing a get'.
The mailto uri spec might not provide identifiers for tasty sub-resources -
like folders and messages within those folders - but we could pretend it
did.

Following the 'mailbox:' example, I'd love to see
GET mailbox://hotmail.com/asynch_messaging/INBOX/
GET
mailbox://hotmail.com/asynch_messaging/INBOX/3C48DE11.222C668A@...
DELETE
mailbox://hotmail.com/asynch_messaging/INBOX/3C48DE11.222C668A@...
POST GET mailbox://hotmail.com/asynch_messaging/INBOX/
(this is where a MOVE might be handy)

Hmm... I'm not asking for a new wire protocol, but a client library that had
similar abilities as an HTTP client library, but used smtp/pop to do the
resource manipulation.

You know, maybe i'll write a servlet that proxies http requests over a set
of resources that mailbox servers this way...

> You would hardly ever do a GET, DELETE or PUT.
Why not?

> That means it is
> like a SOAP endpoint that you can only do POST on. So once again it is
> very RPC-like.
>
>  Paul Prescod
>






-----------------------------------------------------------------------------------
Post ID:70
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-19 18:27:31
Subject:Re: [rest-discuss] Re: MIME-RPC (was Re: REST)
Message:

>
> Following the 'mailbox:' example, I'd love to see
> GET mailbox://hotmail.com/asynch_messaging/INBOX/
> GET
> mailbox://hotmail.com/asynch_messaging/INBOX/3C48DE11.222C668A@...
> DELETE
> mailbox://hotmail.com/asynch_messaging/INBOX/3C48DE11.222C668A@...
> POST GET mailbox://hotmail.com/asynch_messaging/INBOX/
> (this is where a MOVE might be handy)

Typo -
> Before
> POST mailbox://hotmail.com/asynch_messaging/INBOX/
> After
> POST mailbox://hotmail.com/asynch_messaging/INBOX/

It'd be interesting to also use HTTP to GET and POST content of
Content-Type: message/http-request
You could do asynchronous, client-initiated HTTP.






-----------------------------------------------------------------------------------
Post ID:71
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-19 19:00:02
Subject:Re: [rest-discuss] Re: MIME-RPC (was Re: REST)
Message:

> > You
> > have a single end-point and you send it messages. Web-thinking is that
> > every resource (i.e. email message!) represents an endpoint and you send
> > *them* HTTP messages. That's why I still don't think that "mailto:" is
> > particularly REST-y. Arguably a better name is "mailbox:" and then
> > you're addressing the mailbox but it is an incredibly course-grained
> > object.
> That's what I was getting at. Since e-mail doesn't have a single protocol
> for all operations (SMTP to post, IMAP or POP to get), I thought maybe a
> user-agent could infer 'mailto' meant 'try imap or pop if doing a get'.
> The mailto uri spec might not provide identifiers for tasty sub-resources -
> like folders and messages within those folders - but we could pretend it
> did.
> 
> Following the 'mailbox:' example, I'd love to see
> GET mailbox://hotmail.com/asynch_messaging/INBOX/
> GET
> mailbox://hotmail.com/asynch_messaging/INBOX/3C48DE11.222C668A@...
> DELETE
> mailbox://hotmail.com/asynch_messaging/INBOX/3C48DE11.222C668A@...
> POST GET mailbox://hotmail.com/asynch_messaging/INBOX/
> (this is where a MOVE might be handy)
> 
> Hmm... I'm not asking for a new wire protocol, but a client library that had
> similar abilities as an HTTP client library, but used smtp/pop to do the
> resource manipulation.
> 
> You know, maybe i'll write a servlet that proxies http requests over a set
> of resources that mailbox servers this way...

You're exactly right here.  The mailto: URI *does* uniquely identify a
mailbox, but that's not sufficient for resolution.

"http://www.markbaker.ca/" is a URI that uniquely identifies me, but had
the HTTP URI scheme not described how to use that string so that
resolution could be automated, it wouldn't make it any less valuable as
an identifer of me.

The mailto URI scheme could have said something like a POP3 server
should be running on the host corresponding to the domain portion
of an email address (in practice, it would have to be lot more
convoluted than that due to MX/A record differences, and other issues).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:72
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-20 19:24:16
Subject:drafting an asynch http
Message:

Ok, I have my smtp transport for asynch messaging running, next thing to do is
the http layer.  The purpose of this is to be a testbed for ideas about how
asynch http would work.  Also, this message is quite disorderly, since I'm
focused on running code today rather than clear exposition.  There is nothing
special about SMTP -- UDP should be supported by the design just as well -- it
just happens to be a convenient transport.  I am thinking in Java today, so
that's what the examples are.

How to set up the layering between transport and HTTP?  My instinct is to create
a sort of simulated request/response, but with the asynch guts still exposed for
those who want to see them.  It is assumed that any asynch scheme must be
backwards compatible with synch mode; I do this by considering synch to be a
special case where there is always exactly one response.

A client program in need of HTTP obtains a connection object that wrappers the
asynch details.
The client program retrieves and manipulates the connection object as always,
except that it must actively indicate that an asynch connection is OK.
The connection object is a derived subclass of HttpURLConnection.  It is willing
to do anything synchronous HTTP does, but it never lies about the asynch nature
of things.  An example of not lying is that working via a hacked proxy as
Freenet does is not acceptable unless the client indicates that this is OK.

When A calls conn.getContent() a message is emitted and a callback is stored.  A
_new_ response code is emitted to indicate _asynch_ communications: eg 900
"Emission pended" or 901 "Emission sent and accepted".  The outer caller, the
one that wants synchronicity does _not_ get a lie; no "200 OK" that doesn't come
from the real destination.  However, there may be proxy status codes that are
suitable, in particular 407 and 408, I don't know.  The outer caller may be
dropped into a pending state (e.g. via wait()) in anticipation of a true HTTP
response.  When a response message is received it is mapped via a thread-id or
request-id to a callback.

A big question is what URI scheme to use?  This is _not_ HTTP, because there is
no domain name and because -- and worse! -- the dest address should be
expressable as a URI.  EG: "http:/(URI)/etc" is not legal.   How to pack a URI
in there?  The protocol identifier HTTP is inappropriate, because it doesn't
flag that the target host is a URI.  An HTTP URL would be unparseable if the
target host were a URI.  EG,
asynch-http://http://bloe.com/targetContent/

Is "/targetContent"          ^
part of the http URI or part of the asynch-http URI?

Practical comments would be appreciated, as I hope to have running code shortly.







-----------------------------------------------------------------------------------
Post ID:73
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-20 19:45:33
Subject:RE: [rest-discuss] drafting an asynch http
Message:

Thinking about this further, there should be less of the async interface done at
the binary/api level and more at the HTTP layer.  I should implement something
like the WATCH design that Mark suggested.  ...then the only immediate questions
are
* how to model a compound URL that allows a full URI as the target destination?
* what is the status code for an emission that has been scheduled but not
necessarily performed?
* need some analog for SMTP status codes, and probably those codes themselves if
the transport happens to be SMTP.







-----------------------------------------------------------------------------------
Post ID:74
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-20 21:17:57
Subject:Re: [rest-discuss] drafting an asynch http
Message:

Lucas Gonze wrote:
> 
>...

I've read your emails a couple of times and I don't understand the
questions:

> * how to model a compound URL that allows a full URI as the target destination?

What are you trying to express with this URL? What resource is it the
URL of? These are not koans. I don't understand what you're trying to
do.

> * what is the status code for an emission that has been scheduled but not
> necessarily performed?

This bit I understand. What's wrong with "Emission pended".

> * need some analog for SMTP status codes, and probably those codes themselves if
> the transport happens to be SMTP.

Why do you need a transport? Obviously I don't understand enough of what
you mean by asynch. I'll send another message about that. Sorry to drag
you back from coding to explaining the problem you're trying to solve.
;)

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:75
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-20 21:45:07
Subject:RE: [rest-discuss] drafting an asynch http
Message:

> > * how to model a compound URL that allows a full URI as the target
> destination?
> What are you trying to express with this URL?

The target resource is available by some version of HTTP, but does not have
domain name or IP address.  IE, in a URL like:
http://server_address/resource

The server address may itself be a URI.  In the strawman model, it's something
like smtp:joe@....  What I am trying to accomplish is to allow servers to
be addressed via any means that permits bytes to flow, under the assumption that
HTTP can be more-or-less reconstructed as long as bytes can pass.

Hm, I wonder if such a compound URL can be expressed using a sequence of calls:
1) POST http://localhost/stream (POST args are URI=smtp:joe@...)
(drops the URI into saved state on localhost and returns a stream ID)
2) GET http://localhost/stream?ID=234234&resource=/index.html

> > * what is the status code for an emission that has been scheduled but not
> > necessarily performed?
>
> This bit I understand. What's wrong with "Emission pended".

Yes, but there's no such thing in HTTP.

> > * need some analog for SMTP status codes, and probably those codes
> themselves if
> > the transport happens to be SMTP.
>
> Why do you need a transport?
> Obviously I don't understand enough of what
> you mean by asynch.

My working approach for the weekend is just to try to run HTTP over well known
asynch infrastructure and see what, if any, problems are not solvable with
existing HTTP infrastructure.  I could have chosen UDP just as easily as SMTP.
...this project is a reality check on the fairly abstract conversations we've
been having.










-----------------------------------------------------------------------------------
Post ID:76
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-20 21:51:42
Subject:Re: [rest-discuss] drafting an asynch http
Message:

Lucas Gonze wrote:
> 
> Thinking about this further, there should be less of the async interface done at
> the binary/api level and more at the HTTP layer.  I should implement something
> like the WATCH design that Mark suggested.  ...then the only immediate questions
> are

I think that what you call asynch HTTP is better called HTTP
notifications. If one thinks about the minimal amount need to add
"asynch" to HTTP it is a way for a client to tell the server where to
send the response when it becomes available. You need a reply-to: header
with an IP address and a port. The server returns "900: Sure, I'll get
back to you when I can". When the server completes a (potentially long)
computation, it makes a TCP connection to the port and returns a result.
This would be good where the basic pattern is request-response but the
computation may take very long (especially in a workflow-type situation)
and the client doesn't want to keep a socket open for days or weeks on
end.

On the other hand, notifications is about reporting when a resource
changes. The primary virtue of notifications is that they break the
request-response pattern of HTTP. So it is *more than asynch behaviour*
that is interesting in notifications. It is multi-response. In my "pure"
asynch HTTP you could only emulate multi-response by making multiple
requests.

I think you are interested in notifications, not just asych HTTP.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:77
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-21 06:14:10
Subject:Re: [rest-discuss] drafting an asynch http
Message:

> I think that what you call asynch HTTP is better called HTTP
notifications.
Yes.

> If one thinks about the minimal amount need to add
> "asynch" to HTTP it is a way for a client to tell the server where to
> send the response when it becomes available. You need a reply-to: header
> with an IP address and a port. The server returns "900: Sure, I'll get
> back to you when I can".
No. Use Status 202 "Accepted".

You are right that the initial request should use a Reply-To: header.
The final 'response' that closes the request/response message exchange comes
as a new request into the Reply-To address.

That is probably a PUT to the uri in Reply-To as determined by the initiator
of the exchange. That uri would identify a place to update the status of the
initial outgoing message. The
content would be type message/http-response - not sure if something like
this is registered.

> This would be good where the basic pattern is request-response but the
> computation may take very long (especially in a workflow-type situation)
Oooh. Workflow. Another holy grail.

> and the client doesn't want to keep a socket open for days or weeks on
> end.
>
> On the other hand, notifications is about reporting when a resource
> changes. The primary virtue of notifications is that they break the
> request-response pattern of HTTP.
Not necessarily.
A notification about a 'pending request' is about a resource if you model it
as such.

> So it is *more than asynch behaviour*
> that is interesting in notifications. It is multi-response. In my "pure"
> asynch HTTP you could only emulate multi-response by making multiple
> requests.
>
> I think you are interested in notifications, not just asych HTTP.
>
All current HTTP needs for asynchronous request/response is :
 use request header of Reply-To,
 response status of 204 Accepted
 future request to Reply-To uri with content-type: message/http-response.

It would be useful to define an HTTP message that indicates a notification
about the status of a 'pending request' (my term - everybodies got one...).
This 'request' would need to indicate what pending message (identified as a
resource) it is 'about'. This could be used to let the requestor know that
errors have occurred, but the processing hasn't given up. That's the
difference between a notification and a response.
This notification might have to indicate that it is only 'advisory' and not
a 'close the transaction' type of response to an initial request. The HTTP
method might be the best place - otherwise a custom content type.

==

Here's a try at what the message exchange would look like with this
approach:

== Submitting a purchase order ==
POST http://www.widgets.com/industrial/widgets/purchase-orders/ HTTP/1.1
Reply-To: http://www.smallbiz.com/accounting/po/12345/ack/
Content-Type: application/xml
Content-Model: PurchaseOrder
Authenticiation: Basic YNGQ7G=

<po>
<item>ChromedWidget</item>
<quantity>27</quantity>
<unit-of-measure>pounds</unit-of-measure>
</po>

== Acknowledgement of submission ==
HTTP/1.1 202 Accepted
Location: http://www.widgets.com/customer59/po/abcdef/


== Message that updates status of purchase order ===
NOTIFY http://www.smallbiz.com/accounting/po/12345/ack/ HTTP/1.1
Content-Type: message/http-event
Authenticiation: Basic Y7GHHA==

HTTP/1.1 500 Internal Server Error
Content-Type: text/plain

We are experiencing technical difficulties. Please stand by.

== Message that confirms purchase order ===
PUT http://www.smallbiz.com/accounting/po/12345/ack/ HTTP/1.1
Content-Type: message/http-response
Authenticiation: Basic Y7GHHA==

HTTP/1.1 200 Success
Content-Type: application/xml
Content-Model: PurchaseOrderAck

<po-ack>
<invoice>http://www.widgets.com/customer59/invoice/xyz123/</invoice>
<comment>Thank you for doing business with WidgetsRUs!!!</comment>
</po-ack>









-----------------------------------------------------------------------------------
Post ID:78
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-21 17:07:33
Subject:Re: [rest-discuss] drafting an asynch http
Message:


Asynch Messaging wrote:

> == Message that updates status of purchase order ===
> NOTIFY http://www.smallbiz.com/accounting/po/12345/ack/ HTTP/1.1
> Content-Type: message/http-event
> Authenticiation: Basic Y7GHHA==
>
> HTTP/1.1 500 Internal Server Error
> Content-Type: text/plain
>
> We are experiencing technical difficulties. Please stand by.

I agree wholeheartedly that this general scheme is the right way to do async.
I'm still lost as to why Lucas wants to drag SMTP into the mix.  I have one
question / suggested modification to the above:  why do we even need a NOTIFY
here, when the semantics of POST suffice?

jb








-----------------------------------------------------------------------------------
Post ID:79
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-21 17:15:27
Subject:Re: [rest-discuss] drafting an asynch http
Message:

> I agree wholeheartedly that this general scheme is the right way to do async.
> I'm still lost as to why Lucas wants to drag SMTP into the mix.  I have one
> question / suggested modification to the above:  why do we even need a NOTIFY
> here, when the semantics of POST suffice?

Right.  Given that the caller provides the URI on the Reply-To, that
can be made to mean that the caller expect the notification on a POST.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:80
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-21 17:43:20
Subject:Re: [rest-discuss] drafting an asynch http
Message:

Asynch Messaging wrote:
> 
>...
> No. Use Status 202 "Accepted".

You are probably right.

> You are right that the initial request should use a Reply-To: header.
> The final 'response' that closes the request/response message exchange comes
> as a new request into the Reply-To address.

One design is that the thing is totally bidirectional. The "client"
becomes the "server" in an HTTP sense. Definitions:

HTTP client: software that generates HTTP requests and consumes to HTTP
responses.

HTTP server: software that expects HTTP requests, interprets them as
actions to be taken on resources and generates HTTP responses.

Another design is to keep the protocol directed. The server contacts the
client with a message that does NOT look like an HTTP request but rather
like an HTTP response.

The virtue of the former design is that it is easier to layer on the
existing HTTP protocol because every message going across the wire is
HTTP-as-we-know-it.

The virtue of the latter design is that it is simpler. You don't have a
request that is really a response. You have just a response. The only
thing novel about it is that it is a new socket created by the server.

> That is probably a PUT to the uri in Reply-To as determined by the initiator
> of the exchange. 

If I were a firewall administrator, I'd rather deal with a system that
allows an delayed response on a new socket than one that allows PUTs to
desktop machines in the organization.

There are costs in turning the client into a "full server". We should
consider those carefully. It is more difficult to detect a response that
is embedded in a request than to understand a simple request.

> ... That uri would identify a place to update the status of the
> initial outgoing message. The
> content would be type message/http-response - not sure if something like
> this is registered.

So we're talking about an HTTP message embedded in an HTTP message,
right?

> > This would be good where the basic pattern is request-response but the
> > computation may take very long (especially in a workflow-type situation)
> Oooh. Workflow. Another holy grail.

All I mean is that humans may be involved in processing an HTTP request.
i.e. if Babelfish used real human translators. You submit your data
today and get back a decent translation tomorrow.

> > and the client doesn't want to keep a socket open for days or weeks on
> > end.
> >
> > On the other hand, notifications is about reporting when a resource
> > changes. The primary virtue of notifications is that they break the
> > request-response pattern of HTTP.
> Not necessarily.
> A notification about a 'pending request' is about a resource if you model it
> as such.

If you make the HTTP client into an HTTP server then yes, it is easy to
make multiple "responses". 

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:81
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-21 19:13:54
Subject:RE: [rest-discuss] drafting an asynch http
Message:

> Another design is to keep the protocol directed. The server contacts the
> client with a message that does NOT look like an HTTP request but rather
> like an HTTP response.
>
> The virtue of the former design is that it is easier to layer on the
> existing HTTP protocol because every message going across the wire is
> HTTP-as-we-know-it.
>
> The virtue of the latter design is that it is simpler. You don't have a
> request that is really a response. You have just a response. The only
> thing novel about it is that it is a new socket created by the server.

I started coding up the latter this weekend and found that the former was both
simpler and more powerful.  Also, the former is time tested -- all those third
party shopping carts use it to return from the transaction processor's site to
the vendor's site.


> > That is probably a PUT to the uri in Reply-To as determined by the initiator
> > of the exchange.
...
> There are costs in turning the client into a "full server". We should
> consider those carefully. It is more difficult to detect a response that
> is embedded in a request than to understand a simple request.

The design issue is whether or not to make it possible to expose client state.
If the callback is a response then requestor state is a black box.  If the
callback is a POST request, then the state of the original requester/client
becomes exposed.

My preference is that callbacks should be any legal request, because this allows
easier switching between client/server roles.  Using DAV as an example, it would
be much easier to create a decentralized CVS cluster if PUT requests could be
flooded through the cluster unaltered.

> > ... That uri would identify a place to update the status of the
> > initial outgoing message. The
> > content would be type message/http-response - not sure if something like
> > this is registered.
>
> So we're talking about an HTTP message embedded in an HTTP message,
> right?

I am not convinced that a new Reply-to header is any better an idea than a new
WATCH method.  The entire problem of pragating new standards goes away if all
these features are modeled as a web app, and so far I haven't seen any features
that can't be modeled that way.  In that context an HTTP message embedded in an
HTTP message is just another POST argument.

Actually, I'd say that the REST design style strongly implies that doing it as a
web app is the right approach.  Given the choice between a new WATCH verb and
Reply-to header versus a /watches URI and Reply-to argument, REST implies the
second.










-----------------------------------------------------------------------------------
Post ID:82
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-21 20:18:59
Subject:Re: [rest-discuss] drafting an asynch http
Message:

>
> Asynch Messaging wrote:
>
> > == Message that updates status of purchase order ===
> > NOTIFY http://www.smallbiz.com/accounting/po/12345/ack/ HTTP/1.1
> > Content-Type: message/http-event
> > Authenticiation: Basic Y7GHHA==
> >
> > HTTP/1.1 500 Internal Server Error
> > Content-Type: text/plain
> >
> > We are experiencing technical difficulties. Please stand by.
>
> I agree wholeheartedly that this general scheme is the right way to do
async.
> I'm still lost as to why Lucas wants to drag SMTP into the mix.  I have
one
> question / suggested modification to the above:  why do we even need a
NOTIFY
> here, when the semantics of POST suffice?
>
> jb

If POST is used, then there might be an unknown number of POSTs - you may
get several 'errors' and one 'success'.
It would be nice to be able to identify which are ignorable/advisory. I was
looking for a way to indicate the status and indicate that processing will
continue. The 202 Accepted status doesn't leave much room for indicating
whether the processing is in a transient error situation (database is down
for nightly backup, etc).

I almost want to say NOTIFY is idempotent and POST isn't  - but I don't know
what that all means anyway.
The message-in-a-message can be avoided if the response status can be
tunneled in a request header like Status:









-----------------------------------------------------------------------------------
Post ID:83
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-21 20:24:57
Subject:Re: [rest-discuss] drafting an asynch http
Message:

An additional thing to think about - regarding message-in-a-message.
If a response can come in a request, then a request can come in a response.
Which can be very useful for servers behind a firewall.

The client (the 'protected' server) initiates a GET on a collection of
pending messages, which may stream down multiple messages in response. If
these messages have content-type: message/http-request then the it can be
parsed as such and handed to some sort of HTTP dispatching software - like
Apache. The response from something like Apache would go up as a new HTTP
request with content-type: message/http-response.

The collection of pending messages can be a third party provider of
'mailbox' functionality. With tricky software you could be backwards
compatible by having the intermediary hold open the connections for older
clients until a message/http-response arrives (or times out), do the
correlation and literally pipe the response back to the older client.








-----------------------------------------------------------------------------------
Post ID:84
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-21 20:30:36
Subject:Re: [rest-discuss] drafting an asynch http
Message:


Asynch Messaging wrote:

> If POST is used, then there might be an unknown number of POSTs - you may
> get several 'errors' and one 'success'.
> It would be nice to be able to identify which are ignorable/advisory. I was
> looking for a way to indicate the status and indicate that processing will
> continue. The 202 Accepted status doesn't leave much room for indicating
> whether the processing is in a transient error situation (database is down
> for nightly backup, etc).
>
> I almost want to say NOTIFY is idempotent and POST isn't  - but I don't know
> what that all means anyway.
> The message-in-a-message can be avoided if the response status can be
> tunneled in a request header like Status:

What you're describing is almost exactly the proper interpretation of the
semantic differences between POST and PUT.  Think of it this way:  the callback
resource models the current state of the request as it evolves over time.
POSTing to that resource in effect modifies the state of that resource as the
transaction (using term loosely, don't get hung up here) progresses, while the
final PUT effectively sets the final state of that resource.  The application
could then, presumably, delete the resource in question.

A rather sloppy but perhaps illustrative way to think of it:

POST is like        echo "something" >> foo
PUT is like          echo "something final" > foo

$0.02,

jb









-----------------------------------------------------------------------------------
Post ID:85
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-21 21:05:24
Subject:Re: [rest-discuss] drafting an asynch http
Message:

> 
> An additional thing to think about - regarding message-in-a-message.
> If a response can come in a request, then a request can come in a response.
> Which can be very useful for servers behind a firewall.

I don't like that approach at all.  Encapsulation is always a dicey
proposition, because it can all too easily become tunneling.  A lot of
work would have to be done to ensure it didn't, and I don't see the
value add in doing that.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:86
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-21 21:07:30
Subject:Re: [rest-discuss] drafting an asynch http
Message:

Jeff Bone wrote:
> 
>...
> 
> I agree wholeheartedly that this general scheme is the right way to do async.
> I'm still lost as to why Lucas wants to drag SMTP into the mix.  

Let me try to channel Lucas.

SMTP software handles queuing, retries, status notifications, ...

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:87
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-21 23:18:47
Subject:Re: [rest-discuss] drafting an asynch http
Message:


Paul Prescod wrote:

> Jeff Bone wrote:
> >
> >...
> >
> > I agree wholeheartedly that this general scheme is the right way to do async.
> > I'm still lost as to why Lucas wants to drag SMTP into the mix.
>
> Let me try to channel Lucas.
>
> SMTP software handles queuing, retries, status notifications, ...

Understood, but...  it's not clear that reusing SMTP is the right way to add this
kind of thing to HTTP.  Either HTTP's synchronous calls are fundamental and
asynchronous communication is built atop this with full visibility to the
underlying synchronous mechansim, or the asynchronous mechanism is fundamental and
we map HTTP onto it while preserving visibility for the asynchronous mechanism.
IMO they can't effectively be on par, one has to be more essential;  and the task
of layering asynchrony on top of HTTP seems easier and more productive to me than
trying to force-fit synchronous HTTP semantics on top of SMTP.  Lucas seems to have
arrived at mostly the same conclusion...?

jb








-----------------------------------------------------------------------------------
Post ID:88
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-21 23:41:33
Subject:Re: [rest-discuss] drafting an asynch http
Message:

> A rather sloppy but perhaps illustrative way to think of it:

> POST is like        echo "something" >> foo
> PUT is like          echo "something final" > foo

I do want to indicate the difference between 'something' and 'something
final'.
Perhap both should use PUT with some sort of visible 'status' somewhere - in
header or body.
The problem I see is preventing intermediate notifications arriving out of
sequence to not change the status.

One thought would be to make both the 'intermediate status' and the
'response' both URI addressable.
The initial request would specify two locations rather than one and the
responder would use PUT for both.
The idempotency of PUT allows for repeated messages in case something got
dropped - increasing reliability.

==

== Submitting a purchase order ==
POST http://www.widgets.com/industrial/widgets/purchase-orders/ HTTP/1.1
Reply-To: http://www.smallbiz.com/accounting/po/12345/ack/
Status-To: http://www.smallbiz.com/accounting/po/12345/status/
Content-Type: application/xml
Content-Model: PurchaseOrder
Authenticiation: Basic YNGQ7G=

<po>
<item>ChromedWidget</item>
<quantity>27</quantity>
<unit-of-measure>pounds</unit-of-measure>
</po>

== Acknowledgement of submission ==
HTTP/1.1 202 Accepted
Location: http://www.widgets.com/customer59/po/abcdef/


== Message that updates status of purchase order ===
PUT http://www.smallbiz.com/accounting/po/12345/status/ HTTP/1.1
Content-Type: message/http-event
Authenticiation: Basic Y7GHHA==

HTTP/1.1 500 Internal Server Error
Content-Type: text/plain

We are experiencing technical difficulties. Please stand by.

== Message that confirms purchase order ===
PUT http://www.smallbiz.com/accounting/po/12345/ack/ HTTP/1.1
Content-Type: message/http-response
Authenticiation: Basic Y7GHHA==

HTTP/1.1 200 Success
Content-Type: application/xml
Content-Model: PurchaseOrderAck

<po-ack>
<invoice>http://www.widgets.com/customer59/invoice/xyz123/</invoice>
<comment>Thank you for doing business with WidgetsRUs!!!</comment>
</po-ack>









-----------------------------------------------------------------------------------
Post ID:89
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-21 23:45:18
Subject:Re: [rest-discuss] drafting an asynch http
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>


> >
> > An additional thing to think about - regarding message-in-a-message.
> > If a response can come in a request, then a request can come in a
response.
> > Which can be very useful for servers behind a firewall.
>
> I don't like that approach at all.  Encapsulation is always a dicey
> proposition, because it can all too easily become tunneling.  A lot of
> work would have to be done to ensure it didn't, and I don't see the
> value add in doing that.
>

Party pooper.
It was meant as a 'tunnel' approach - but I don't what can of worms that
opens up.
I was trying to find some way for client initiated exchanges to have
requests flow from server to client. This helps enable peer to peer between
two firewalled nodes - with the assistance of a middleman.

For software behind a firewall, how would you suggest we maintain
RESTfullness if we attempt client initiated messaging?
Especially if you want to maintain existing programming models.








-----------------------------------------------------------------------------------
Post ID:90
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-21 23:56:04
Subject:Re: [rest-discuss] drafting an asynch http
Message:

> == Submitting a purchase order ==
> POST http://www.widgets.com/industrial/widgets/purchase-orders/ HTTP/1.1
> Reply-To: http://www.smallbiz.com/accounting/po/12345/ack/
> Status-To: http://www.smallbiz.com/accounting/po/12345/status/

Make that Notify-To: - it sounds better and doesn't assume the meaning of
values PUT to it.







-----------------------------------------------------------------------------------
Post ID:91
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-22 00:02:15
Subject:Re: [rest-discuss] drafting an asynch http
Message:

> > I don't like that approach at all.  Encapsulation is always a dicey
> > proposition, because it can all too easily become tunneling.  A lot of
> > work would have to be done to ensure it didn't, and I don't see the
> > value add in doing that.
> >
> 
> Party pooper.
> It was meant as a 'tunnel' approach - but I don't what can of worms that
> opens up.

See http://www.i-cap.org 8-)  Basically, it breaks HTTP's end-to-end
model.  To not break it would require treating the encapsulated
message as transparent rather than opaque, and doing stuff like
stripping the Connection header on the first hop (etc.., etc..,
etc..)

> I was trying to find some way for client initiated exchanges to have
> requests flow from server to client. This helps enable peer to peer between
> two firewalled nodes - with the assistance of a middleman.

Well, with WATCH, you're doing that, but I guess you mean that you want
them coming back on the same connection.

> For software behind a firewall, how would you suggest we maintain
> RESTfullness if we attempt client initiated messaging?
> Especially if you want to maintain existing programming models.

Use GET and a persistent connection rather than WATCH.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:92
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-22 00:08:45
Subject:Re: [rest-discuss] drafting an asynch http
Message:

Asynch Messaging wrote:

> > A rather sloppy but perhaps illustrative way to think of it:
>
> > POST is like        echo "something" >> foo
> > PUT is like          echo "something final" > foo
>
> I do want to indicate the difference between 'something' and 'something
> final'.

Argh, no.  The difference isn't in "something" or "something final" --- it's in
>> vs. >, aka POST vs. PUT.  Let me restate the sloppy example in a clearer
fashion:

POST is like        echo "something" >> foo
PUT is like          echo "something" > foo

Repeated POSTS of the same content are not necessarily idempotent;  repeated
PUTs are.  The semantic differences are in the methods, with no additional need
for status codes embedded in the message, different resources, etc.  The
semantics of POST are that the state of the resource (i.e., progress of the
transaction) is updated, while PUT implies that the state of the resource is
replaced.  It's appropriate to view *replacement* of the resource state as the
finalization of the transaction.

> One thought would be to make both the 'intermediate status' and the
> 'response' both URI addressable.

Why not simply have content POSTED to the "progress-of-the-transaction" resource
indicate intermediate changes of state, while the first content successfully PUT
to the resource indicates the completion of the interaction?  I may be missing
something really obvious, but I still don't think you need anything new, here.
I think POST and PUT to the same resource are sufficient.

jb








-----------------------------------------------------------------------------------
Post ID:93
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-22 00:10:58
Subject:Re: [rest-discuss] drafting an asynch http
Message:


Asynch Messaging wrote:

> For software behind a firewall, how would you suggest we maintain
> RESTfullness if we attempt client initiated messaging?

Note that asymmetry of connectivity is an orthogonal issue to any of various
kinds of synchrony --- though they share partial solutions.

> Especially if you want to maintain existing programming models.

The one REST is most interested in maintaining is called "the Web."  ;-)

jb








-----------------------------------------------------------------------------------
Post ID:94
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 00:21:14
Subject:RE: [rest-discuss] drafting an asynch http
Message:

> > Let me try to channel Lucas.
> >
> > SMTP software handles queuing, retries, status notifications, ...

Paul is 100% more articulate about this than I am, but otherwise that's a good
channeling.

jb said:
> Understood, but...  it's not clear that reusing SMTP is the right way
> to add this
> kind of thing to HTTP.  Either HTTP's synchronous calls are fundamental and
> asynchronous communication is built atop this with full visibility to the
> underlying synchronous mechansim, or the asynchronous mechanism is
> fundamental and
> we map HTTP onto it while preserving visibility for the asynchronous
> mechanism.
> IMO they can't effectively be on par, one has to be more essential;
> and the task
> of layering asynchrony on top of HTTP seems easier and more
> productive to me than
> trying to force-fit synchronous HTTP semantics on top of SMTP.  Lucas
> seems to have
> arrived at mostly the same conclusion...?


My feeling is that HTTP's synchronous calls are fundamental and asynch should be
built atop this with full visibility.

I wouldn't attempt to merge HTTP semantics into SMTP -- already tried it, didn't
work.  What I don't know is how good an idea it is to build general purpose
"asynch/notifications/store-and-forward HTTP" as a web app, but that's the
current plan.  If there are people interested in collaborating on design or
implementation, I would welcome you.  See
http://gonze.com/asynch-http/aREST_frame.htm
for the current state of the design.  I definately have not yet gotten the HTTP
calls correct, and blame Visio export for the heinous HTML.

















-----------------------------------------------------------------------------------
Post ID:95
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 00:23:04
Subject:Re: [rest-discuss] drafting an asynch http
Message:

Jeff Bone wrote:
> 
>...
> 
> Understood, but...  it's not clear that reusing SMTP is the right way to add this
> kind of thing to HTTP.  

Remember, I'm just channelling and not claiming to have thought this all
through:

Maybe SMTP software is useful as a *software transport* for queued,
routed, HTTP messages with retry-behaviour. The end-points may not know
that SMTP is being used as an intermediary.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:96
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 00:36:30
Subject:tunnelling
Message:

per MB:
> Basically, [tunnelling] breaks HTTP's end-to-end
> model.  To not break it would require treating the encapsulated
> message as transparent rather than opaque, and doing stuff like
> stripping the Connection header on the first hop (etc.., etc..,
> etc..)

Is this the reason that SMTP tunneling would break the end to end model: there's
no practical way to fully emulate HTTP 1.1 using SMTP, therefore an SMTP
transport would have to monkey with the protocol.

Yes?

I agree that any solution which has to do stuff like strip the Connection header
is not doable.  Also, any solution which isn't completely straight up with the
client about what's going on is unacceptable -- that's why a Freenet-style
hacked proxy can't work.  One possible solution is that tunnelled HTTP must be
HTTP 1.0 or even 0.9.













-----------------------------------------------------------------------------------
Post ID:97
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 00:36:32
Subject:Last call
Message:

I'm going to give anybody who wants to comment on the REST article one
more evening. I'll submit tomorrow. I appreciate the encouragement from
those who read it but didn't find time for detailed comments. I know
about the vast gulf between intentions and possibility.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:98
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 01:03:55
Subject:Re: [rest-discuss] drafting an asynch http
Message:

Lucas Gonze wrote:
> 
>....comments welcome...
> 

I'm guessing that the reason that in the first example there is a
"callback time" is just to show that the result is not instantaneous.

What does "note: URL encoded body" mean? Do you mean that you're running
the URL encoding algorithm over the XML? Or that the XML is an
approximation of something that really uses ampersands and semicolons?

The stocks example is not clear on how the service decides when to send
notifications. I think something more compelling would be to send a
notification when the stock passes a floor or ceiling.

Is there a way to put some prose on each example describing the
application?

At the bottom of the first page of "Store and Forward" you've got the
Responder responding to the Requester. I don't think they've got a
connection to each other, so I think that's a typo. It should be
responding to the Email Service thingee. That's about where I get lost
in that whole example. Why do we need store and forward for this
application? Here's where I would use store and forward. My laptop is
going to be off the network so I ask a web service to contact me via a
store and forward web service instead of directly. 

But you have the requester (e.g. my laptop) contacting the responder
through a store and forward service. 

As a graphical thing, is it possible to have the thing closest to the
requester (end-user) always on the left hand side and the thing closest
to the real service always on the right?

And maybe it would be cool if you could add a "time passes" bubble to
differentiate the asynch parts from the sync parts.

A fundamental part of this is the mail->HTTP gateway. The important
thing is that the mail software does the queuing, retry etc. But if the
HTTP target of the message is offline is there a way for the "Email
service" to let the MTA know that it has failed to deliver? I guess I
don't know whether the "email service" is a separate process working
through mail protocols or a milter or a thing pointed to from the
.forward or ... Whatever it is, it needs to be able to translate HTTP
failures into mail delivery failures.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:99
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 01:28:08
Subject:RE: [rest-discuss] drafting an asynch http
Message:


> -----Original Message-----
> From: Paul Prescod [mailto:paul@...]
> Sent: Monday, January 21, 2002 8:04 PM
> To: Lucas Gonze; Rest-Discuss
> Subject: Re: [rest-discuss] drafting an asynch http
>
>
> Lucas Gonze wrote:
> >
> >....comments welcome...
> >
>
> I'm guessing that the reason that in the first example there is a
> "callback time" is just to show that the result is not instantaneous.

Yup.  Added note to that effect.


> What does "note: URL encoded body" mean? Do you mean that you're running
> the URL encoding algorithm over the XML? Or that the XML is an
> approximation of something that really uses ampersands and semicolons?

Not important -- removed that note.

> The stocks example is not clear on how the service decides when to send
> notifications. I think something more compelling would be to send a
> notification when the stock passes a floor or ceiling.

Added "floor" param.


> Is there a way to put some prose on each example describing the
> application?

Done.

>
> At the bottom of the first page of "Store and Forward" you've got the
> Responder responding to the Requester. I don't think they've got a
> connection to each other, so I think that's a typo. It should be
> responding to the Email Service thingee.

Correct.  Fixed.

> That's about where I get lost
> in that whole example. Why do we need store and forward for this
> application? Here's where I would use store and forward. My laptop is
> going to be off the network so I ask a web service to contact me via a
> store and forward web service instead of directly.

Need to pick a better app.  Will do.


> But you have the requester (e.g. my laptop) contacting the responder
> through a store and forward service.
>
> As a graphical thing, is it possible to have the thing closest to the
> requester (end-user) always on the left hand side and the thing closest
> to the real service always on the right?

Todo.

>
> And maybe it would be cool if you could add a "time passes" bubble to
> differentiate the asynch parts from the sync parts.

:)

>
> A fundamental part of this is the mail->HTTP gateway. The important
> thing is that the mail software does the queuing, retry etc. But if the
> HTTP target of the message is offline is there a way for the "Email
> service" to let the MTA know that it has failed to deliver? I guess I
> don't know whether the "email service" is a separate process working
> through mail protocols or a milter or a thing pointed to from the
> .forward or ... Whatever it is, it needs to be able to translate HTTP
> failures into mail delivery failures.

These are good points.  I stopped short of that level of detail in order to hit
the main points first.

The thing that I am most concerned about is getting the REST modeling right.








-----------------------------------------------------------------------------------
Post ID:100
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-22 02:11:21
Subject:Re: [rest-discuss] drafting an asynch http
Message:

>
> > I was trying to find some way for client initiated exchanges to have
> > requests flow from server to client. This helps enable peer to peer
between
> > two firewalled nodes - with the assistance of a middleman.
>
> Well, with WATCH, you're doing that, but I guess you mean that you want
> them coming back on the same connection.
Yes - a persistent response (ala KnowNow) would do that.

>
> > For software behind a firewall, how would you suggest we maintain
> > RESTfullness if we attempt client initiated messaging?
> > Especially if you want to maintain existing programming models.
>
> Use GET and a persistent connection rather than WATCH.
>
Yes - but what would the response stream look like, if I wanted to pretend
there were requests coming down the pipe?
Especially if I wanted to service many resources via this single connection.
I'm suggesting that putting one or more message/http-request entities in the
response is the way to do that. I'm not so concerned with being extremely
RESTful, at least at this level.






-----------------------------------------------------------------------------------
Post ID:101
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-22 02:13:52
Subject:Re: [rest-discuss] drafting an asynch http
Message:

>
> > I was trying to find some way for client initiated exchanges to have
> > requests flow from server to client. This helps enable peer to peer
between
> > two firewalled nodes - with the assistance of a middleman.
>
> Well, with WATCH, you're doing that, but I guess you mean that you want
> them coming back on the same connection.

Yes - with WATCH, the requests come in as requests on a new connection, so
the stream formats are exactly the same as existing message exchanges on the
Web. But if you cannot listen for requests - firewalled - then what?








-----------------------------------------------------------------------------------
Post ID:102
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-22 02:17:45
Subject:Re: [rest-discuss] drafting an asynch http
Message:

>
> Argh, no.  The difference isn't in "something" or "something final" ---
it's in
> >> vs. >, aka POST vs. PUT.  Let me restate the sloppy example in a
clearer
> fashion:
>
> POST is like        echo "something" >> foo
> PUT is like          echo "something" > foo
>
Oh.


> Repeated POSTS of the same content are not necessarily idempotent;
repeated
> PUTs are.  The semantic differences are in the methods, with no additional
need
> for status codes embedded in the message, different resources, etc.  The
> semantics of POST are that the state of the resource (i.e., progress of
the
> transaction) is updated, while PUT implies that the state of the resource
is
> replaced.  It's appropriate to view *replacement* of the resource state as
the
> finalization of the transaction.
>
Well, as long as we have a common understanding that there are multiple
messages and one of them is the 'finalization' of the transaction.


> > One thought would be to make both the 'intermediate status' and the
> > 'response' both URI addressable.
>
> Why not simply have content POSTED to the "progress-of-the-transaction"
resource
> indicate intermediate changes of state, while the first content
successfully PUT
> to the resource indicates the completion of the interaction?  I may be
missing
> something really obvious, but I still don't think you need anything new,
here.
> I think POST and PUT to the same resource are sufficient.


I suppose POST for the intermediate events and PUT for the final reply is
fine.









-----------------------------------------------------------------------------------
Post ID:103
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-22 02:20:50
Subject:Re: [rest-discuss] drafting an asynch http
Message:

>
> > Especially if you want to maintain existing programming models.
>
> The one REST is most interested in maintaining is called "the Web."  ;-)
>
I was thinking of API model rather than architectural model.
As in provide the ASP Request and Response objects or the Servlet Request
and Response objects to client-side programmers when they are behind a
firewall and the other side is also behind a firewall.
It'd be cool to write script to handle these & also let that script interact
with the desktop UI (something I call Appster).
(And if anybody is willing to fund that kind of peer to peer application
engine, let me know.)








-----------------------------------------------------------------------------------
Post ID:104
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-22 02:55:38
Subject:Re: [rest-discuss] drafting an asynch http
Message:


Asynch Messaging wrote:

> >
> > > Especially if you want to maintain existing programming models.
> >
> > The one REST is most interested in maintaining is called "the Web."  ;-)
> >
> I was thinking of API model rather than architectural model.

Now we're getting somewhere!  :-)

One of the basic ideas AFAICT behind REST is that the architectural model
*implies* a certain style of application modeling, one with generic interfaces.
Trying to map a typical API model directly onto generic interfaces is a losing
proposition on lots of dimensions.

jb








-----------------------------------------------------------------------------------
Post ID:105
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-22 03:15:00
Subject:Re: [rest-discuss] drafting an asynch http
Message:

> > Use GET and a persistent connection rather than WATCH.
> >
> Yes - but what would the response stream look like, if I wanted to pretend
> there were requests coming down the pipe?

They wouldn't be requests, but it would be reasonable to assume that
the response body to the GET would be the same as the request body
on an incoming POST from a WATCH invocation ... with the minor
difference that the GET would have to be streamed, perhaps with
each chunk being an individual notification.

> Especially if I wanted to service many resources via this single connection.

Persistent connections can be used for multiple resources.

> I'm suggesting that putting one or more message/http-request entities in the
> response is the way to do that. I'm not so concerned with being extremely
> RESTful, at least at this level.

Well, if you have to, but I haven't seen the need yet.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:106
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-22 04:28:01
Subject:Re: [rest-discuss] drafting an asynch http
Message:

> > >
> > > > Especially if you want to maintain existing programming models.
> > >
> > > The one REST is most interested in maintaining is called "the Web."
;-)
> > >
> > I was thinking of API model rather than architectural model.
>
> Now we're getting somewhere!  :-)
>
> One of the basic ideas AFAICT behind REST is that the architectural model
> *implies* a certain style of application modeling, one with generic
interfaces.
> Trying to map a typical API model directly onto generic interfaces is a
losing
> proposition on lots of dimensions.
>
Yes, I know that.
I am trying to enable programmers to use this system, and one way is to
provide this via existing APIs.
Those APIs are not 'problem domain models' (information models) - which
should be cast into generic RESTish interfaces - but just the existing
technology coding APIs.
I would literally like to take the client-initiated messaging via HTTP stuff
& pipe it through Apache - you get things like DAV, JSP, etc. - or even IIS
for ASP capabilities (if you don't have a mod_asp or whatever).








-----------------------------------------------------------------------------------
Post ID:107
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-22 04:34:10
Subject:Re: [rest-discuss] drafting an asynch http
Message:


> > > Use GET and a persistent connection rather than WATCH.
> > >
> > Yes - but what would the response stream look like, if I wanted to
pretend
> > there were requests coming down the pipe?
>
> They wouldn't be requests, but it would be reasonable to assume that
> the response body to the GET would be the same as the request body
> on an incoming POST from a WATCH invocation ... with the minor
> difference that the GET would have to be streamed, perhaps with
> each chunk being an individual notification.
And I think that the response body being the same as the request body should
be indicated by a Content-Type header - hence the message/http-request
stuff.. A response looks like a request, but without the first line - the
method and resource.

And with good enough access to the lower levels of HTTP, using chunked
encoding with each discrete message within the response might work.

I haven't followed this out to look at encoding issues or at multi-hop
(proxies) issues. But it sounds fun anyway.






-----------------------------------------------------------------------------------
Post ID:108
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-22 04:42:56
Subject:Re: [rest-discuss] drafting an asynch http
Message:

> > They wouldn't be requests, but it would be reasonable to assume that
> > the response body to the GET would be the same as the request body
> > on an incoming POST from a WATCH invocation ... with the minor
> > difference that the GET would have to be streamed, perhaps with
> > each chunk being an individual notification.
> And I think that the response body being the same as the request body should
> be indicated by a Content-Type header - hence the message/http-request
> stuff.. A response looks like a request, but without the first line - the
> method and resource.

No no, because what I'm talking about doesn't have the request line, just
the headers (unencapsulated) and body.  So content-type would be like
application/xml, or whatever.  Not message/http.

> And with good enough access to the lower levels of HTTP, using chunked
> encoding with each discrete message within the response might work.
> 
> I haven't followed this out to look at encoding issues or at multi-hop
> (proxies) issues. But it sounds fun anyway.

We have at PF.  Lots of fun.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:109
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 05:01:50
Subject:Indicating Notifications in HTTP
Message:

I'd like opinions on how the client indicates to the server that it is
asking for notifications. I think I've seen the following options
discussed here:

 1. through a new method

WATCH /blah/blah

 2. through the existence of a new header in a POST

Reply-to: http://....

 3. through a form parameter in a POST

&reply-to=http://....

 4. through a POST of a content type

Content-type: application/www-notification-request

 5. The application could merely "know" that when a POST is made to a
particular URI that the request is for a notification.

I guess I prefer 2, the reply-to header. Lucas, why do your examples use
3? I would rather leave the POST body completely in the domain of the
application because what if the application wants to pass XML or
graphics as the body? 

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:110
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-22 05:15:17
Subject:Re: [rest-discuss] drafting an asynch http
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>


> > > They wouldn't be requests, but it would be reasonable to assume that
> > > the response body to the GET would be the same as the request body
> > > on an incoming POST from a WATCH invocation ... with the minor
> > > difference that the GET would have to be streamed, perhaps with
> > > each chunk being an individual notification.
> > And I think that the response body being the same as the request body
should
> > be indicated by a Content-Type header - hence the message/http-request
> > stuff.. A response looks like a request, but without the first line -
the
> > method and resource.
>
> No no, because what I'm talking about doesn't have the request line, just
> the headers (unencapsulated) and body.  So content-type would be like
> application/xml, or whatever.  Not message/http.
>
I'm not sure that would do what I want - but I can definitely see that it
would be useful.
For what I am trying to do - and there may be better ways of doing it - it
seems that I need a request line (the URI and method).
If a server managing a collection of resources cannot receive inbound
requests, yet can fetch arbitrary data, how would receiving headers and body
help service request upon that collection of resources? Maybe its a
different problem. What does your (response) body actually look like? Are
you doing client initiated retrieval of requests?
Color me confused.










-----------------------------------------------------------------------------------
Post ID:111
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-22 05:34:01
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> I'd like opinions on how the client indicates to the server that it is
> asking for notifications. I think I've seen the following options
> discussed here:
> 
>  1. through a new method
> 
> WATCH /blah/blah
> 
>  2. through the existence of a new header in a POST
> 
> Reply-to: http://....
> 
>  3. through a form parameter in a POST
> 
> &reply-to=http://....
> 
>  4. through a POST of a content type
> 
> Content-type: application/www-notification-request
> 
>  5. The application could merely "know" that when a POST is made to a
> particular URI that the request is for a notification.
> 
> I guess I prefer 2, the reply-to header. Lucas, why do your examples use
> 3? I would rather leave the POST body completely in the domain of the
> application because what if the application wants to pass XML or
> graphics as the body? 

Right.  #3 is a crude form of RPC, equivalent to #4 (and #5 if you think
about it).

But #2, with that header, isn't sufficient either.  I assume that you
were trying to use my WATCH-as-PUT example where only an extension
header was required?  If so, the header there works quite differently
than just "Reply-To".

I also prefer the new method.  A practical reason is that the meaning is
more obvious, especially to most firewalls that permit blocking based
on methods.  None I know of can follow a hypertext transaction to
understand what you're really doing with GET, follow-header, PUT/POST,
etc..  Though there's no reason that they can't, they don't.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:112
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-22 05:36:35
Subject:Re: [rest-discuss] drafting an asynch http
Message:

> I'm not sure that would do what I want - but I can definitely see that it
> would be useful.
> For what I am trying to do - and there may be better ways of doing it - it
> seems that I need a request line (the URI and method).
> If a server managing a collection of resources cannot receive inbound
> requests, yet can fetch arbitrary data, how would receiving headers and body
> help service request upon that collection of resources? Maybe its a
> different problem. What does your (response) body actually look like? Are
> you doing client initiated retrieval of requests?
> Color me confused.

Ah, I see now.  You'd have to tunnel in this case.  This is at a lower
layer.  So feel free to do that, so long as at your highest layer,
HTTP's end to end semantics are preserved.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:113
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-22 05:45:39
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

I like using a header, except when headers are not available, as in a
browser. In that case I'd 'tunnel' them into query terms
?reply-to=http://...

But you are not asking for the client to receive notifications, you are
asking the server to post to a location.

If you want the client itself to receive notifications, you should use GET
and an indication of the time range - i.e. the 'future' (but indicating some
number/age of messages in the past is also useful). The server could return
a list of message references - which would interestingly look a lot like a
file listing - or it could return the messages themselves. You'd probably
want to use an Accept header to indicate which representation you want.



----- Original Message -----
From: "Paul Prescod" <paul@...>


> I'd like opinions on how the client indicates to the server that it is
> asking for notifications. I think I've seen the following options
> discussed here:
>
>  1. through a new method
>
> WATCH /blah/blah
>
>  2. through the existence of a new header in a POST
>
> Reply-to: http://....
>
>  3. through a form parameter in a POST
>
> &reply-to=http://....
>
>  4. through a POST of a content type
>
> Content-type: application/www-notification-request
>
>  5. The application could merely "know" that when a POST is made to a
> particular URI that the request is for a notification.
>
> I guess I prefer 2, the reply-to header. Lucas, why do your examples use
> 3? I would rather leave the POST body completely in the domain of the
> application because what if the application wants to pass XML or
> graphics as the body?
>
>  Paul Prescod
>






-----------------------------------------------------------------------------------
Post ID:114
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-22 05:55:21
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:


Mark Baker wrote:

> I also prefer the new method.  A practical reason is that the meaning is
> more obvious, especially to most firewalls that permit blocking based
> on methods.

Ah, but here's where you and I diverge, Mark.  While you see enabling
firewalls as a positive, I see it as an unnecessary and undesirable hinderance
to adoption of new technology.  I.e., are notification applications so
semantically different that we need to differentiate them for the purposes of
firewall filtering *beyond* existing method filtering and the already
significant issue of connection asymmetry?

jb








-----------------------------------------------------------------------------------
Post ID:115
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-22 06:11:18
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> Mark Baker wrote:
> 
> > I also prefer the new method.  A practical reason is that the meaning is
> > more obvious, especially to most firewalls that permit blocking based
> > on methods.
> 
> Ah, but here's where you and I diverge, Mark.  While you see enabling
> firewalls as a positive, I see it as an unnecessary and undesirable hinderance
> to adoption of new technology.  I.e., are notification applications so
> semantically different that we need to differentiate them for the purposes of
> firewall filtering *beyond* existing method filtering and the already
> significant issue of connection asymmetry?

It's not just firewalls.  To any intermediary, the effort in determining
what's going on is going to be greater for the extension header than for
the extension method, at least during the initial transaction where the
intermediary learns what the Watcher URI is.  In an environment with
very long lived subscriptions where that initial cost gets amortized,
it's less of an issue.  But in the absence of that info, and knowing
that the method I need to use for subscription is POST (not PUT as with
WebDAV LOCK), and so the chances of reusing deployed optimizations is
nil, I'd go for the new method.

But it's not a huge deal, I could live with either approach.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:116
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-22 06:28:54
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:


Jeff Bone wrote:

> Mark Baker wrote:
>
> > I also prefer the new method.  A practical reason is that the meaning is
> > more obvious, especially to most firewalls that permit blocking based
> > on methods.

Here're what I hope are a few *really, really* good arguments against introducing
a WATCH method for subscription.

(1)  It doesn't make sense for all resources to support subscriptions;  the naive
behavior --- send me the entire new state anytime the resource changes --- doesn't
make sense for all resources, particularly ones that change with high frequency.
More sophisticated cases --- such as "send me only the changed state" --- probably
cannot be defined generically for all (or even many) application domains and
modeled resources.

(2)  Supporting subscriptions for a substantial portion of resources hosted by a
particular domain has costs which may not be justified for a given service /
application.

(3)  Recognizing (1) and preventing (2) would require a kind of fine-grained,
per-resource configuration to allow or disallow WATCH behavior.  Sure, global DENY
could be overridden by local ALLOW, but do you *really* want to burden the server
administrator with defining what is probably more accurately an application
configuration issue?  Is the cost of moving that configuration duty out into local
config space e.g. Apache htaccess files really worthwhile?

(4)  Adding new methods to HTTP requires changes to many different server
implementations, firewall implementations, etc.  This has a very high cost in
terms of delaying the propagation and limiting the reach of the new functionality
in question.

(5)  It's not clear at all that a new method is required in order to preserve the
end-to-end semantics of HTTP.  For example, you could simply model the list of
subscriptions to a given resource as a sub-URL of the resource, i.e.

   POST /some/resource/subscriptions?reply-to=http://foo.com/notices/1
   POST /other/resource/subscriptions?reply-to=http://foo.com/notices/2

In this case, the subscription list for /interesting/resource is itself a resource
on which GET, POST, and PUT all make sense without modification.  The relationship
between this subscription list and the resource it refers to is conventional
rather than programatic, but it makes sense in a RESTful modeling sense.  (At
least, so it seems to me.)  This is *no longer* an RPC because you aren't
overloading POST semantics on the original resource of interest, but rather
further reifying the notion of subscription in the domain of things to which URI
refer.

Subscription / notification is really a rather application-specific thing.  It's
not clear to me that a generic subscription / notification mechanism justifies
polluting the method space rather than just coming up with some generic
conventions, nor is it clear that adding such a method will spur universal
development and interoperability of async HTTP applications.  IMO, it's a losing
proposition all the way around, compared to other alternatives.

jb








-----------------------------------------------------------------------------------
Post ID:117
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-22 06:30:25
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:


Mark Baker wrote:

> It's not just firewalls.  To any intermediary, the effort in determining
> what's going on is going to be greater for the extension header than for
> the extension method, at least during the initial transaction where the
> intermediary learns what the Watcher URI is.

No doubt.

> In an environment with
> very long lived subscriptions where that initial cost gets amortized,
> it's less of an issue.  But in the absence of that info, and knowing
> that the method I need to use for subscription is POST (not PUT as with
> WebDAV LOCK), and so the chances of reusing deployed optimizations is
> nil, I'd go for the new method.
>
> But it's not a huge deal, I could live with either approach.

Coolness.  IMO, no matter what else happens, you'll see non-HTTP methods first and
most broadly, simply due to adoption friction.

jb








-----------------------------------------------------------------------------------
Post ID:118
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 06:59:40
Subject:"Reliability"
Message:

Beyond asynch, the other buzzword that HTTP seems to miss is
"reliability". One part of reliability is disk-backed queuing in case of
crashes. I think that's a software issue, not a protocol issue.

Another part of reliable messaging as it is normally implemented is
queuing. I think that this is probably an orthogonal issue to actual
reliability.

The main part is once and only once delivery. This only matters for
non-idempotent methods (primarily POST). As far as I know, the only
protocol issue (as opposed to software issue) is some form of ID that
ensures that the same thing (e.g. purchase order) is not POSTed twice.
Should there be a convention for doing it so that it need not be always
done at the application level? There must be a reason that HTTP doesn't
have this already.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:119
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 09:15:47
Subject:Re: [rest-discuss] "Reliability"
Message:

Here is one application-agnostic way that you might implement "only
once" delivery in HTTP:

--->
RPOST /purchase_orders HTTP/1.1

<---
201 Created
Location: /reliable_delivery_target_1432
Expires: Thu, 01 Dec 2094 16:00:00 GMT

"A one-time delivery location has been set up. Please PUT the
information there. Only the first PUT will be respected. Subsequent PUTs
will be rejected."

--->
PUT /reliable_delivery_target_1432

<--
200 OK

"Thank you for this purchase order...it will be processed as if you had
POSTed it normally."

This would be semantically equivalent to a single POST and response.

A reliable delivery target would timeout after some time. It could be
DELETEd if it wasn't going to be used for some reason. The first PUT
would launch whatever processing the POST would have (in fact with
mod_reliable, it would look to your application as if it WERE a POST).

I thought that this method-based approach was more REST-y than an
"only-once" ID because it reifies the ID so that the server does not
need "implicit state" tracking which IDs have come through before. It
takes an extra hop to let the server choose the ID but then both the
client and the server have the same view of the time-window for the PUT.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:120
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 13:45:46
Subject:RE: [rest-discuss] Indicating Notifications in HTTP
Message:

Paul said:
> >  3. through a form parameter in a POST
> >
> > &reply-to=http://....
...
> > I guess I prefer 2, the reply-to header. Lucas, why do your examples use
> > 3? I would rather leave the POST body completely in the domain of the
> > application because what if the application wants to pass XML or
> > graphics as the body?
>

And Mark said:
> Right.  #3 is a crude form of RPC, equivalent to #4 (and #5 if you think
> about it).

Them's fightin words in these parts, Baker. ;)

I used #3 with full knowledge of the other alternatives because this approach
models asych comms as a _web app_.  If it's a web app then the arguments belong
in the domain of the app, which is the POST body.


> But #2, with that header, isn't sufficient either.  I assume that you
> were trying to use my WATCH-as-PUT example where only an extension
> header was required?

Yes.

> If so, the header there works quite differently
> than just "Reply-To".

Explain?


> I also prefer the new method.  A practical reason is that the meaning is
> more obvious, especially to most firewalls that permit blocking based
> on methods.  None I know of can follow a hypertext transaction to
> understand what you're really doing with GET, follow-header, PUT/POST,
> etc..  Though there's no reason that they can't, they don't.

This is the best reason not to do it as a web app -- that it requires a fairly
complex combination of elements.  The counter argument is that REST says that we
get less overall complexity by inventing new nouns and reusing existing verbs
than by inventing new verbs.

Per firewalls, I leave it to them to keep up.  I am on the side of firewall
transgressors in this.

- Lucas







-----------------------------------------------------------------------------------
Post ID:121
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 13:55:22
Subject:RE: [rest-discuss] "Reliability"
Message:

I have been considering this requirement as a feature of store-and-forward.  In
a S-F model, once the message is emitted there is software to make every effort
to get it delivered, including queueing, retries, expiration, failure
notification, etc.  Note that SMTP infrastructure already covers all of this,
and that the SMTP/HTTP binding I proposed should support it as well.

> Beyond asynch, the other buzzword that HTTP seems to miss is
> "reliability". One part of reliability is disk-backed queuing in case of
> crashes. I think that's a software issue, not a protocol issue.
>
> Another part of reliable messaging as it is normally implemented is
> queuing. I think that this is probably an orthogonal issue to actual
> reliability.
>
> The main part is once and only once delivery. This only matters for
> non-idempotent methods (primarily POST). As far as I know, the only
> protocol issue (as opposed to software issue) is some form of ID that
> ensures that the same thing (e.g. purchase order) is not POSTed twice.
> Should there be a convention for doing it so that it need not be always
> done at the application level? There must be a reason that HTTP doesn't
> have this already.
>
>  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:122
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-22 14:52:44
Subject:Re: [rest-discuss] "Reliability"
Message:

> The main part is once and only once delivery. This only matters for
> non-idempotent methods (primarily POST). As far as I know, the only
> protocol issue (as opposed to software issue) is some form of ID that
> ensures that the same thing (e.g. purchase order) is not POSTed twice.
> Should there be a convention for doing it so that it need not be always
> done at the application level? There must be a reason that HTTP doesn't
> have this already.

Yup, there is.

If you use that header, you want to be able to know that that the other
end of the pipe understands it.  Because most will just ignore it and
not tell you they are doing so (per RFC 2616).  Enter the need for a
mandatory extension mechanism, such as in RFC 2774 (M-*) or in SOAP
(though with SOAP headers).

See the example at the end of this;

http://lists.w3.org/Archives/Public/ietf-discuss/2001Dec/0008.html

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:123
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-22 15:09:14
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> And Mark said:
> > Right.  #3 is a crude form of RPC, equivalent to #4 (and #5 if you think
> > about it).
> 
> Them's fightin words in these parts, Baker. ;)
>
> I used #3 with full knowledge of the other alternatives because this approach
> models asych comms as a _web app_.  If it's a web app then the arguments belong
> in the domain of the app, which is the POST body.

Ah, ok, I follow now.  You want to do this from a browser, so you're
stuck with application/x-www-form-urlencoded.  Got it.

Ideally, you'd just post the URI (as text/uri), or some XML description
of the characteristics of the watch you're doing, to the container that
houses the list of current watchers.  But because you're doing it from
a browser, you're stuck needing a name for the URI.  But I suggest that
"Reply-To" is unnecessary, in case, as I did, somebody thought that the
name was required in order to trigger a watch.  It isn't, all that's
required is the URI, so you could just have had;

  "uri=http://..."

> > If so, the header there works quite differently
> > than just "Reply-To".
> 
> Explain?

Just like I said here;

http://groups.yahoo.com/group/rest-discuss/message/47

The active header is "Properties" (from DAV), plus the extension is
really the "watch" modifier of it that says we're looking at the
watch property.

> > I also prefer the new method.  A practical reason is that the meaning is
> > more obvious, especially to most firewalls that permit blocking based
> > on methods.  None I know of can follow a hypertext transaction to
> > understand what you're really doing with GET, follow-header, PUT/POST,
> > etc..  Though there's no reason that they can't, they don't.
> 
> This is the best reason not to do it as a web app -- that it requires a fairly
> complex combination of elements.  The counter argument is that REST says that we
> get less overall complexity by inventing new nouns and reusing existing verbs
> than by inventing new verbs.

No, REST doesn't say that.  It's only recommendation wrt creating new
methods is that you understand that you're forgoing the use of existing
and possible future optimizations created around existing methods.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:124
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 15:08:37
Subject:updates posted
Message:

I have posted an update to the strawman, with suggestions incorporated, better
explanatory text, etc.

http://gonze.com/asynch-http/aREST_frame.htm








-----------------------------------------------------------------------------------
Post ID:125
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 16:22:50
Subject:Re: [rest-discuss] "Reliability"
Message:

Mark Baker wrote:
> 
>...
> 
> If you use that header, you want to be able to know that that the other
> end of the pipe understands it.  

Right, I figured this out later and invented "RPOST".

> ... Because most will just ignore it and
> not tell you they are doing so (per RFC 2616).  Enter the need for a
> mandatory extension mechanism, such as in RFC 2774 (M-*) or in SOAP
> (though with SOAP headers).

"An origin server SHOULD return the status code 405 (Method Not Allowed)
if the method is known by the origin server but not allowed for the
requested resource, and 501 (Not Implemented) if the method is
unrecognized or not implemented by the origin server."

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:126
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 16:45:41
Subject:Re: [rest-discuss] updates posted
Message:

Lucas Gonze wrote:
> 
> I have posted an update to the strawman, with suggestions incorporated, better
> explanatory text, etc.
> 
> http://gonze.com/asynch-http/aREST_frame.htm

Looking good!

Question: isn't the implementation of the StoreAndForwardWebService
irrelevant to the outside? It's a black box. You use SMTP not really as
a "protocol" but as an API for a particular piece of software you have
that happens to do the queuing and retry that you want. I say "API"
instead of "protocol" because the SMTP bit is only used within the web
service and is never exposed to either the requester nor the responder.

Maybe the implementation bit should be on a separate slide to make this
clear. (do we intend to publicize this URI?)

When you say this is a "web app" you mean what the industry calls web
service. It is a web-based service that exposes some functionality:
storing and forwarding. 

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:127
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 17:00:16
Subject:Re: [rest-discuss] "Reliability"
Message:

Lucas Gonze wrote:
> 
> I have been considering this requirement as a feature of store-and-forward.  ]

What if I need reliability AND syncronicity? I think reliability should
be orthogonal to store and forward.

> ... In
> a S-F model, once the message is emitted there is software to make every effort
> to get it delivered, including queueing, retries, expiration, failure
> notification, etc.  Note that SMTP infrastructure already covers all of this,
> and that the SMTP/HTTP binding I proposed should support it as well.

That isn't what I mean by reliability though. If I email you a purchase
order for a million dollars of work, are we guaranteed that it will
arrive once and only once? I don't think so. If the last packet of your
SMTP response does not arrive then I don't know whether you got it or
not. The only safe thing is to send it again. But then I might have
purchased two million dollars worth of work.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:128
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 17:03:51
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

Mark Baker wrote:
> 
> ...
> 
> The active header is "Properties" (from DAV), plus the extension is
> really the "watch" modifier of it that says we're looking at the
> watch property.

Isn't http://www.yahoo.com/properties;watch a violation of the opaque
URI policy? You're generating a URI on the client side by pasting
together strings using some convention!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:129
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 17:08:05
Subject:RE: [rest-discuss] updates posted
Message:

> Looking good!

:)

>
> Question: isn't the implementation of the StoreAndForwardWebService
> irrelevant to the outside? It's a black box. You use SMTP not really as
> a "protocol" but as an API for a particular piece of software you have
> that happens to do the queuing and retry that you want. I say "API"
> instead of "protocol" because the SMTP bit is only used within the web
> service and is never exposed to either the requester nor the responder.
>
> Maybe the implementation bit should be on a separate slide to make this
> clear. (do we intend to publicize this URI?)

Good points.  I think that what's useful about the StoreAndForwardWebService
implementation is just proof of concept.  The slides should be clear about this.

I already have to publicize the URL to the o'reilly etech conf committee, since
I am proposing a talk on the subject, so maybe we should also add it to the REST
Wiki and do any other marketing that seems appropriate.

> When you say this is a "web app" you mean what the industry calls web
> service. It is a web-based service that exposes some functionality:
> storing and forwarding.

Amen.  I have incorporated that into the slides.










-----------------------------------------------------------------------------------
Post ID:130
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-22 17:30:19
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> Isn't http://www.yahoo.com/properties;watch a violation of the opaque
> URI policy? You're generating a URI on the client side by pasting
> together strings using some convention!

Maybe, but not necessarily.  I'm still figuring out the opacity
characteristics of ";" (though I think I've got "/" and ";" figured
out). 8-)

MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:131
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-22 17:35:09
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> (though I think I've got "/" and ";" figured
> out). 8-)

Er, make that "?".

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:132
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 17:36:37
Subject:Re: [rest-discuss] updates posted
Message:

You should make notification subscriptions into addressable resources so
that they may be DELETEd by the client.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:133
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 17:48:10
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

Jeff, I buy your arguments from tactical practicality but not long-term
purity. I absolutely think it would be cool if my browser had a button
that said: "WATCH this URL." It would authenticate me (just as for PUT)
and then watch it.

Therefore I'd propose that we view it as a convention layered on top of
existing methods in the short term with a transition to a WATCH method
in the long (perhaps very long) term.

Jeff Bone wrote:
> 
>...
> 
> (1)  It doesn't make sense for all resources to support subscriptions;  the naive
> behavior --- send me the entire new state anytime the resource changes --- doesn't
> make sense for all resources, particularly ones that change with high frequency.
> More sophisticated cases --- such as "send me only the changed state" --- probably
> cannot be defined generically for all (or even many) application domains and
> modeled resources.

Hmmm. It seems like sometimes you want a notification that a change has
happened, sometimes you want a notification that embeds the changed
object and sometimes you want a diff. I think that the first case
applies pretty efficiently and generally to all objects everywhere.

Maybe we should only ever send URLs, not representations, in
notifications. The client can easily do a GET if it wants the data, and
some kind of "GET the difference" if it knows how to do that. 

> (2)  Supporting subscriptions for a substantial portion of resources hosted by a
> particular domain has costs which may not be justified for a given service /
> application.

The same goes for supporting PUT! That's why most web sites don't
support PUT!

> (3)  Recognizing (1) and preventing (2) would require a kind of fine-grained,
> per-resource configuration to allow or disallow WATCH behavior. 

Doesn't seem much different than PUT to me.

> (4)  Adding new methods to HTTP requires changes to many different server
> implementations, firewall implementations, etc.  This has a very high cost in
> terms of delaying the propagation and limiting the reach of the new functionality
> in question.

Granted.

> (5)  It's not clear at all that a new method is required in order to preserve the
> end-to-end semantics of HTTP.  For example, you could simply model the list of
> subscriptions to a given resource as a sub-URL of the resource, i.e.

I like the idea of reifying subscriptions but see it as complementary to
a new HTTP method. The method would return the subscription URI in its
Location: header.

>    POST /some/resource/subscriptions?reply-to=http://foo.com/notices/1
>    POST /other/resource/subscriptions?reply-to=http://foo.com/notices/2

It's arguable whether the client should have to create a separate
end-point if they want separate subscriptions. Might not it make sense
to have dozens of service with an endpoint of mailto:email@...?






-----------------------------------------------------------------------------------
Post ID:134
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 18:16:04
Subject:RE: [rest-discuss] "Reliability"
Message:

DSN/MDN, Delivery Status Notification/Message Delivery Notification, is a good
model for acks, though it should be wrapped via the specification of the web
app.  I would expose a success/failure notification in the web interface and
leave the internals (SMTP or otherwise) to the implementation.  Our design would
need an ack specification, and DSN/MDN is a good place to start, but the
interface should probably not be canonical DSN/MDN.  ...need to read that
specification, which I haven't done, and see how generic it is.

> That isn't what I mean by reliability though. If I email you a purchase
> order for a million dollars of work, are we guaranteed that it will
> arrive once and only once? I don't think so. If the last packet of your
> SMTP response does not arrive then I don't know whether you got it or
> not. The only safe thing is to send it again. But then I might have
> purchased two million dollars worth of work.
>
>  Paul Prescod
>







-----------------------------------------------------------------------------------
Post ID:135
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 18:24:33
Subject:RE: [rest-discuss] updates posted
Message:

> From: Paul Prescod [mailto:paul@...]
>
> You should make notification subscriptions into addressable resources so
> that they may be DELETEd by the client.

In "notifications" slide, removed body argument notificationTarget and changed
target URI from
POST /notifications/ HTTP/1.1
to
POST /notifications/stocks/symbols/APLX HTTP/1.1

Note that a DELETE would depend on session state.  Don't know if this clashes
with DELETE semantics.








-----------------------------------------------------------------------------------
Post ID:136
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-22 18:37:08
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:


Paul Prescod wrote:

> Therefore I'd propose that we view it as a convention layered on top of
> existing methods in the short term with a transition to a WATCH method
> in the long (perhaps very long) term.

I'm not *entirely* antagonistic to this kind of a both / and approach, assuming that we
can guarantee that the semantics of the two mechanisms are consistent and that any
service that supports WATCH is also required to support the other mechanism as well.  (I
think this is important from an adoption perspective.)  Having said that, let me
(gently) play devil's advocate on a couple of these...

> Hmmm. It seems like sometimes you want a notification that a change has
> happened, sometimes you want a notification that embeds the changed
> object and sometimes you want a diff. I think that the first case
> applies pretty efficiently and generally to all objects everywhere.
>
> Maybe we should only ever send URLs, not representations, in
> notifications. The client can easily do a GET if it wants the data, and
> some kind of "GET the difference" if it knows how to do that.

I think that the kind of notification desired is a very application (i.e., resource)
specific thing.  There are really three distinct parts to a subscription:  an expression
of interest in notifications of state change on some resource by some other component,
an event notification of state change per-se, and potentially the representation of the
changed state.  In the latter case, what you're really doing is specifying what
representation of the resource you want sent to you when state changes;  it's entirely
consistent (AFAICT) with HTTP / URI to specify this in a query string, e.g.

  POST /some/rsrc/subs?reply-to=http://foo.com/notices/1;repr=delta

But there's a deeper issue:  what does a state change on a given resource mean,
exactly?  It's not clear that this is generically meaningful for all resources.  If a
web page, for example, contains a counter that changes every time a GET happens on it,
should that then trigger a bunch of notifications?  IMO, the issue of what's "in" a
notification, how to represent it, and when to trigger it are all dependent on the
application / resource in question.  Each app --- indeed each resource --- should be
free to define these things however they like.

> > (2)  Supporting subscriptions for a substantial portion of resources hosted by a
> > particular domain has costs which may not be justified for a given service /
> > application.
>
> The same goes for supporting PUT! That's why most web sites don't
> support PUT!

Yup.  Think about that.

> > (3)  Recognizing (1) and preventing (2) would require a kind of fine-grained,
> > per-resource configuration to allow or disallow WATCH behavior.
>
> Doesn't seem much different than PUT to me.

Absolutely correct.  IMO, it's not that PUT wouldn't be appropriate in many cases;  it's
that it's operationally too hard to use for many app developers in many contexts.
Several issues combine to make PUT less exploited than it could otherwise be.  The
application developer / operator is often not the Web server administrator, and when the
app developer / operator has to get the Web server administrator to perform
application-specific configurations it (a) often doesn't happen, (b) often takes a long
time, and (c) is rather fragile over time.  These kinds of friction and others lead
application developers to abandon certain available features and, indeed, push them
towards tunnelling things *through* HTTP in inappropriate ways, failing to leverage the
resource model and namespace, etc.  (This is a generic problem with the way IT is
internally organized in many places;  ther's also a tug-of-war between apps / ops and
admin.  It results in balkanization and duplication, such as in the entirely distinct
user management mechanisms for e.g. databases and networks as a whole.)

Anyway, recognizing that this problem exists, it seems silly to build something and hope
it's generally used when there's this kind of built-in adoption friction.

> I like the idea of reifying subscriptions but see it as complementary to
> a new HTTP method.

If this is strongly true, then I'm (somewhat uneasily) okay with a new method; if the
spec for a new method *requires* that subscriptions be reified in a general way --- thus
ensuring parity of method and non-method based, um, methods --- then we're good.  I
doubt very seriously that this is acceptable to the general HTTP audience, though ---
the protocol space shouldn't mold the resource model.

> It's arguable whether the client should have to create a separate
> end-point if they want separate subscriptions. Might not it make sense
> to have dozens of service with an endpoint of mailto:email@...?

We agree on the value of reifying subscriptions on the server end of things;  similar
benefits and arguments obtain for reifying subscriptions on the client end of things.
If you *don't* reify subscriptions on the client end of things, then generally speaking
the client needs to do much more work to determine what particular subscription a
particular event notification refers to.  This probably means embedding data about the
sender in either the headers or the body of the notification, and that's somewhere I
think we all agree we don't want to go.

Resources, not endpoints. :-)

jb










-----------------------------------------------------------------------------------
Post ID:137
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 18:44:56
Subject:Re: [rest-discuss] updates posted
Message:

Lucas Gonze wrote:
> 
> > From: Paul Prescod [mailto:paul@...]
> >
> > You should make notification subscriptions into addressable resources so
> > that they may be DELETEd by the client.
> 
> In "notifications" slide, removed body argument notificationTarget and changed
> target URI from
> POST /notifications/ HTTP/1.1
> to
> POST /notifications/stocks/symbols/APLX HTTP/1.1

Well I was thinking about asking for that too, but it wasn't what I
meant.

I meant that in the RESPONSE, there should be a Location header:

Location: http://www.thismachine.com/stocks/symbols/APLX/notifications/1

You could DELETE that later if you wanted to cancel notification. You
could PUT to it if you wanted to change the notification trigger rules
and expiry time. You could GET it to remind yourself of the notification
trigger rules and expiry time. You could fiddle ACLs on it to allow
other people to fiddle with your notifications. In other words, it
should be a first-class resource.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:138
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-22 18:56:20
Subject:Re: [rest-discuss] updates posted
Message:


Lucas Gonze wrote:

> Note that a DELETE would depend on session state.  Don't know if this clashes
> with DELETE semantics.

This is clever, but it does clash.  From rfc2616 sec 9.7:  "The DELETE method
requests that the origin server delete the resource identified by the
Request-URI."  If the URI in question represents the object being subscribed to
rather than the subscription itself, then the meaning of the DELETE is now
ambiguous and probably not easily disabiguated.

My suggestion:  if the resource of interest is

   /resource

then its server-side subscriptions are represented under a collection

  /resource/subs

and each shows up as

  /resource/subs/<someid>

* Getting a subscription is a process of doing a POST to /resource/subs.
* Getting the list of subs ifor resource s a GET on /resource/subs.
* The state of a sub can be changed by an appropriate POST to
/resource/subs/<someid>.
* A sub can be cancelled via a DELETE on /resource/subs/<someid>

Authentication of any / all of these operations is an orthogonal issue, handled in
any of the usual ways.

jb








-----------------------------------------------------------------------------------
Post ID:139
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 19:23:23
Subject:RE: [rest-discuss] updates posted
Message:

> > Note that a DELETE would depend on session state.  Don't know if
> this clashes
> > with DELETE semantics.
>
> This is clever, but it does clash.

!$!#@$.

> My suggestion:  if the resource of interest is
>
>    /resource
>
> then its server-side subscriptions are represented under a collection
>
>   /resource/subs

Agreed with a caveat:

If the target is
/subs/resource[/someid]

instead of
/resource/subs[/someid]

then the implementation can grab all subevents of /subs.  This enables
implementations to plug into existing apps more cleanly, because they can just
be mounted under a unique root.  The root(s) could be anywhere on a server, but
would own the entire namespace under that root.

> * Getting a subscription is a process of doing a POST to /resource/subs.
> * Getting the list of subs ifor resource s a GET on /resource/subs.
> * The state of a sub can be changed by an appropriate POST to
> /resource/subs/<someid>.
> * A sub can be cancelled via a DELETE on /resource/subs/<someid>
>
> Authentication of any / all of these operations is an orthogonal
> issue, handled in
> any of the usual ways.

Appended Location: header with /[some-id] to all 202 responses.

Appended the /[some-id] tag to all relevant requests.

Added the following interaction between requester and responder to notifications
slide:
DELETE http://responder-host/notifications/stocks/symbols/APLX/ID/[some-id]
HTTP/1.1

Todo eventually:
* illustrate getting list of subs, changing state of a sub.
* more text to say why things are the way they are.

- Lucas







-----------------------------------------------------------------------------------
Post ID:140
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 19:31:26
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> > Therefore I'd propose that we view it as a convention layered on top of
> > existing methods in the short term with a transition to a WATCH method
> > in the long (perhaps very long) term.
> 
> I'm not *entirely* antagonistic to this kind of a both / and approach, assuming that we
> can guarantee that the semantics of the two mechanisms are consistent and that any
> service that supports WATCH is also required to support the other mechanism as well.  (I
> think this is important from an adoption perspective.)  

Fair enough.

> ...
> 
> I think that the kind of notification desired is a very application (i.e., resource)
> specific thing.  There are really three distinct parts to a subscription:  an expression
> of interest in notifications of state change on some resource by some other component,
> an event notification of state change per-se, and potentially the representation of the
> changed state.  In the latter case, what you're really doing is specifying what
> representation of the resource you want sent to you when state changes;  it's entirely
> consistent (AFAICT) with HTTP / URI to specify this in a query string, e.g.
> 
>   POST /some/rsrc/subs?reply-to=http://foo.com/notices/1;repr=delta

Why not a header like "Accepts"?

> But there's a deeper issue:  what does a state change on a given resource mean,
> exactly?  It's not clear that this is generically meaningful for all resources.  If a
> web page, for example, contains a counter that changes every time a GET happens on it,
> should that then trigger a bunch of notifications?  

This is already fuzzy because of caching. Obviously we don't treat every
counter bump as a state change and the HTTP spec. has leeway to allow
that. So the problem isn't specific to subscriptions.

> ... IMO, the issue of what's "in" a
> notification, how to represent it, and when to trigger it are all dependent on the
> application / resource in question.  Each app --- indeed each resource --- should be
> free to define these things however they like.

I agree. We can only standardize the parts that are really general. But
I think that it is possible to define a base behaviour that is widely
applicable and optimizable. In particular:

 * notifications are sent whenever the resource thing changes in a
"meaningful" sense
 * the notification's representation is specified in a header, else it
is just a URL
 * a notification's lifespan is expressed in a header, else it is server
defined

> > > (2)  Supporting subscriptions for a substantial portion of resources hosted by a
> > > particular domain has costs which may not be justified for a given service /
> > > application.
> >
> > The same goes for supporting PUT! That's why most web sites don't
> > support PUT!
> 
> Yup.  Think about that.

I'm content to have WATCH be like PUT, something that we would like to
be widespread some day, but probably not for a while.

>...
> Anyway, recognizing that this problem exists, it seems silly to build something and hope
> it's generally used when there's this kind of built-in adoption friction.

Absolutely agree that WATCH must be like PUT: something you could use
but that you could do without if you're stuck with stupid admins or
coders who want to only learn two methods.

> ...
> If this is strongly true, then I'm (somewhat uneasily) okay with a new method; if the
> spec for a new method *requires* that subscriptions be reified in a general way --- thus
> ensuring parity of method and non-method based, um, methods --- then we're good.  I
> doubt very seriously that this is acceptable to the general HTTP audience, though ---
> the protocol space shouldn't mold the resource model.

Either way the protocol space is molding the resource model. Whether it
is a header or a method, it is "protocol". And anyway, doesn't PUT mold
the resource space? You PUT something you get a new resource. Yu DELETE
something you remove a resource. WATCH creates a new notification
resource.

Another option is for the Server to return a "Subscription-URI:" header
to a GET or HEAD. Then the client knows that it can POST to the
subscription-URI to get a subscription for this resource.

-->
GET /index.html

<---
200 OK
Subscription-URI: /index.html?subscriptions

--->
POST /index.html?subscriptions

This maintains the virtue of allowing *any resource* to declare that it
is watchable without out-of-band arrangement. That's what I'm trying to
preserve. I don't want a bunch of conventions that client and server
have to agree to use through email. For simple cases I want it to "just
work".

>...
> We agree on the value of reifying subscriptions on the server end of things;  similar
> benefits and arguments obtain for reifying subscriptions on the client end of things.
> If you *don't* reify subscriptions on the client end of things, then generally speaking
> the client needs to do much more work to determine what particular subscription a
> particular event notification refers to.  

I agree that you will often want this. But maybe the changed URI is all
you care about. That's all I cared about from netmind.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:141
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 19:39:59
Subject:Re: [rest-discuss] updates posted
Message:

Jeff Bone wrote:
> 
> Lucas Gonze wrote:
> 
> > Note that a DELETE would depend on session state.  Don't know if this clashes
> > with DELETE semantics.
> 
> This is clever, but it does clash.  From rfc2616 sec 9.7:  "The DELETE method
> requests that the origin server delete the resource identified by the
> Request-URI."  If the URI in question represents the object being subscribed to
> rather than the subscription itself, then the meaning of the DELETE is now
> ambiguous and probably not easily disabiguated.

This is a straw man! I asked Lucas to reify the subscription as its own
resource. THAT was what I said could be DELETEd.

> My suggestion:  if the resource of interest is
> 
>    /resource
> 
> then its server-side subscriptions are represented under a collection
> 
>   /resource/subs

I think that specifying URI structures is bad mojo. HTTP doesn't do that
anywhere else. Opaque URIs and all of that. I'm learning this stuff by
osmosis. Consider roy's suggestion here:

http://www.xent.com/pipermail/fork/2001-September/004712.html

"What I would have done (and this was proposed at an early DAV meeting)
is
define a single resource metadata field for HTTP responses that gave a
URI
prefix for operations on properties of that resource.  E.g.,

   Properties: "http://example.com/this_resource;props"

and then simply define that namespace in the same way as old server-side
image maps were defined.  You could then do

   GET http://example.com/this_resource;props?lock HTTP/1.1"

I don't want to build on WebDAV but I like the basic idea that the
server says where a resource's properties go. I think we could use the
same mechanism for subscriptions.

Subscriptions: http://example.com/this_resource/subs

You POST to that to get a new sub.

> * Getting a subscription is a process of doing a POST to /resource/subs.

Agree. Just think that the server should choose the subs location.

> * Getting the list of subs ifor resource s a GET on /resource/subs.

Agree with same caveat.

> * The state of a sub can be changed by an appropriate POST to
> /resource/subs/<someid>.

POST or PUT??? Changing the state of a resource is done with PUT.

> * A sub can be cancelled via a DELETE on /resource/subs/<someid>

Agree.

> Authentication of any / all of these operations is an orthogonal issue, handled in
> any of the usual ways.

Agree.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:142
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 19:52:09
Subject:POST or PUT
Message:

> > * The state of a sub can be changed by an appropriate POST to
> > /resource/subs/<someid>.
>
> POST or PUT??? Changing the state of a resource is done with PUT.

9.5 POST    The POST method is used to request that the origin server accept the
   entity enclosed in the request as a new subordinate of the resource
   identified by the Request-URI in the Request-Line. POST is designed
   to allow a uniform method to cover the following functions:
       - Annotation of existing resources;

9.6 PUT    The PUT method requests that the enclosed entity be stored under the
   supplied Request-URI.

Again, it's src >> dest versus src > dest.

Given that a sub can be a fairly complex object, including parameters like
deltas vs. whole objects, permissions, etc, it seems to me that most state
changes will affect only a subset of parameters.  If we were to use PUT it
should be like:

PUT /subs/resource/permissions/a+w

- Lucas








-----------------------------------------------------------------------------------
Post ID:143
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-22 19:54:21
Subject:Re: [rest-discuss] drafting an asynch http
Message:

Lucas,
More comments about your slides:

Asynch Response:
 - how will status be returned in the final reply?
I'm suggesting using a content-type of message/http-response which would
have all the headers of a response. If parsing is an issue, then this could
be change to a simple 'canonical xml representation of http' (which is
something i've been wanting to do for a while) or some other format
indicating status of the response to the initial client request.










-----------------------------------------------------------------------------------
Post ID:144
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-22 20:00:40
Subject:Re: [rest-discuss] updates posted
Message:

> ----- Original Message -----
> From: Lucas Gonze
> I have posted an update to the strawman, with suggestions incorporated,
better
> explanatory text, etc.
> http://gonze.com/asynch-http/aREST_frame.htm


In the 'notifications' slide, a POST is used to establish a subscription.
What do people think of using a GET with one or more asynch responses? The
GET without asynch response returns the price/info of the stock symbol. The
GET with asynch response(s) returns "202 Accepted" with a Location header
identifying the unique subscription, and the stock data is later posted to
the ReplyTo uri specified in the initial request.

Also, regarding notification, is it useful/required/whatever to know if an
asynch response is an 'intermediate' reponse or a 'final' response? For
example, if subscribed to stock quotes, periodic notifications that the
'value fetcher' has some transient errors might be useful. These would be
indicated in a status code in the asynch response. Or is subscription
fundamentally different than intermediate responses to an asynchronous
operation?








-----------------------------------------------------------------------------------
Post ID:145
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-22 20:19:22
Subject:MIME-RPC, REST, and Asynchrony
Message:

Ok.  I just got back from traveling and reading
all of this email.  I am going to try to put
together answers to Paul and Jeff in one email.

Here is what I think REST says:
Only use HTTP.
Only use HTTP methods (expose objects as URLs).
Only use GET to make idempotent requests
Use XML to represent structured data when
necessary.

My claims:
HTTP GET does not allow requests that you want
MIME-RPC allows delivery of those requests
  (HTTP does not prohibit specific POST from being
  idempotent)
HTTP does not support asynchrony
MIME-RPC does support asynchrony
XML is a bad way to represent some structured data
and a good way to represent others.

Regarding GET and idempotency, Paul says you
should just urlencode everything.  He ignores the
reality that real life HTTP servers and
itermediaries will frequently cut off excessively
long HTTP query strings.  But that is really
beside the point. Jeff's more substantive answer
is:

> The REST position is therefore that you need
> to remodel your application to fit the HTTP model and thereby get all the
> goodness of HTTP, rather than using it as a "dumb" conduit to tunnel other
> protocols and map to other object models.  *Fully expose your application as
> resources that conform to the generic semantics of HTTP.*

This is handwaving away the problem.  You have to
deal with application semantics as is.  Suppose I
want to implement TerroristOrNot.com.  You send it
a par of pictures of someone (front and side) and
it replies whether or not that person is a
terrorist.  The pictures may be in GIF, JPEG, or
PNG format.

Using MIME-RPC over HTTP, you would POST either
a list (multipart/mixed), or a struct
(multipart/form-data) to some URL (e.g.
terroristornot.com/verify).

You cannot sanely do this with GET, therefore I
think you cannot sanely do this with REST.

Note to Paul: packaging the request as an XML
document is also exceedingly ugly (though I now
understand that XML is not part of REST).

> > Claim: REST supports asynchronous messaging
> >
> > Reality: REST appears to require use of HTTP and
> > HTTP does not support asynchronous requests.
>
> This is (a) incorrect, as we've already stated, and (b) rather ludicrous
> anyway.  Asynchrony as an application communication pattern doesn't require
> an asynchronous communication protocol --- if it did, it wouldn't be possible
> to build asynchronous applications with i.e. ONC RPC, CORBA, etc.  But we do
> just that.  Syncronous request-response protocols are sufficient for building
> asynchronous messaging on top of, and vice-versa --- both models are fully
> general.

Ok, I'll be more precise.  HTTP is not a PROTOCOL
for asynchronous messaging.  To do asynchronous
messaging with another party you need a protocol.
Therefore, REST, as it stands does not support
asynchrony!

Note, that you can bulid asynchronous applications
on top of HTTP is irrelevant because the
asynchrony will only be between parties agreeing
on some implicit new protocol.

I can't believe this point is even in
dispute, esp. in light of  the recent discussion
on REST-discuss on this very issue!

With MIME-RPC, I proposed enhancing RFC822
slightly to achieve asynchorny.  Specifically.
initiators send a message-id (as in RFC822)
and a reply-to-url (like reply-to, except it takes
any URL -- so replies can be any uri
scheme, like mailto:, http:,  https:, imap:, ftp:,
file:, etc.).

These  headers may be sent over any MIME transport
(including HTTP or SMTP).

Lucas Gonze has proposed a different enhancement
to HTTP that attempts to achieve the similar
goals
(http://gonze.com/asynch-http/aREST_frame.htm).

I think the biggest difference between the two
proposals is the direct support for other uri
schemes.

I also think that Lucas's proposal covers many
orthogonal messaging issues that are better
handled with separate specs.

I am actually in the process of drafting some of
those right now, but I think they are add-ons to a
much more basic asynchronous messaging spec.
I will try to respond to Lucas post shortly, but
here is my list of add-on services:

* Reliable Delivery/Return-receipt/Expiration
* Polling Delivery (sender has no return address)
* Seriality (messages must be handled in order)
* Atomicity (all-or-none of message group handled)
* Consistency (any fault means none--see atomicity)
* Isolation (no visible side effects until commit)
* Durability
* Prepare (useful for two phase commit)

The main point is that these are add-ons.  For
basic stuff, I think you don't need anything more
sophisticated than email.  Remember:
worse-is-better/simpler-is-better.

> Reality:  REST doesn't claim that applications should add to the HTTP method
> set.  (BTW, that was my loudest and most passionate objection to REST before
> I "got it.")  The REST claim is that almost anything you can think of doing
> can be trivially recast within the context of HTTP's general, powerful
> methods.  (Atomic read+delete is an example of one possible missing method,
> but there aren't many of them.)

I like this idea A LOT.  I just don't think it is
always possible to do so.  I also think that often
programmers just want a way to expose their
existing APIs over the web.  MIME-RPC provides
that as well.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax









-----------------------------------------------------------------------------------
Post ID:146
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 20:19:25
Subject:Re: [rest-discuss] updates posted
Message:

Asynch Messaging wrote:
> 
>...'
> 
> In the 'notifications' slide, a POST is used to establish a subscription.
> What do people think of using a GET with one or more asynch responses? 

And we differentiate a request for a normal GET form an asynch GET just
by the Reply-to header?

What's the advantage?

It feels vaguely like method abuse to me but I can't put my finger on
the detail in the time I have available.

> Also, regarding notification, is it useful/required/whatever to know if an
> asynch response is an 'intermediate' reponse or a 'final' response? For
> example, if subscribed to stock quotes, periodic notifications that the
> 'value fetcher' has some transient errors might be useful. These would be
> indicated in a status code in the asynch response. Or is subscription
> fundamentally different than intermediate responses to an asynchronous
> operation?

I think that our current idea is that you are asking when the thing
changes, perhaps with some filter so that you only get notifications
when it changes in a more significant sense (e.g. above some price
boundary).

If you want to follow a long-running process like a purchase order
floating through a company getting digital signatures, then I think you
would subscribe to a URI that represents its status.

/purchase-orders/po234212/status

Make sense?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:147
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-22 20:28:11
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> This maintains the virtue of allowing *any resource* to declare that it
> is watchable without out-of-band arrangement. That's what I'm trying to
> preserve. I don't want a bunch of conventions that client and server
> have to agree to use through email. For simple cases I want it to "just
> work".

Absolutely.  Me thinks Jeff is straying from the opacity "axiom".

FWIW, we at PF struggled with this some time ago, but what we have now
is *lean*, I mean completely kick ass.  It's a shame we're not even
releasing free binaries (nevermind source).  It does everything you're
talking about here, but so much more.

BTW, as I said to Jeff off-list, we won't be issuing any patents around
this type of stuff - that would be silly, for all the usual reasons.
But that means there's a lot of stuff I can't talk about until we're
ready to talk about it. 8-(

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:148
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 20:40:18
Subject:RE: [rest-discuss] MIME-RPC, REST, and Asynchrony
Message:

> Lucas Gonze has proposed a different enhancement
> to HTTP that attempts to achieve the similar
> goals
> (http://gonze.com/asynch-http/aREST_frame.htm).
>
> I think the biggest difference between the two
> proposals is the direct support for other uri
> schemes.

Sorry, that's a misreading.  The other URI schemes are only meant to show that
such things as store-and-forward and UDP transmission can and should be
implemented as web apps.

>
> I also think that Lucas's proposal covers many
> orthogonal messaging issues that are better
> handled with separate specs.

In some respects, yes.  For example the email binding is completely orthogonal.
But it's supposed to be, and is just there to illustrate (and understand) how
such a thing would work.  In other respects, no.  The third solution wouldn't be
possible without the second.  That is not orthogonality.

- Lucas







-----------------------------------------------------------------------------------
Post ID:149
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-22 20:46:00
Subject:Re: [rest-discuss] Re: [MIME-RPC] Re: MIME-RPC (was Re: REST)
Message:

On Fri, 18 Jan 2002, Paul Prescod wrote:

> "S. Alexander Jacobson" wrote:
> >
> >...
> >
> > In any case, RFC822 says that every mail message
> > should have a globally unique identifier
> > (message-id) and that replies should have
> > "in-reply-to: message-id" in their headers.
>
> How do I dereference those identifiers? If I can't put an identifier in
> a browser URL bar and expect to get some set of bytes back then I don't
> personally think it is really REST-y. But then REST is just a philosophy
> so there will be differences of opinion on that. I would say that
> message-id's should be HTTP URLs that dereference to the message
> contents and that ACLs should be used to say who can and cannot see it.
> Archives of messages (e.g. egroups) could add a header

RFC2111 says that message IDs are just presumed to
be in some accessible message store.  And it is up
to the local implementation to deal with resolving
it.

That being said, I like the idea of making
message-ids resolvable via HTTP and may add that
as a "Should" to the MIME-RPC spec.

> > The last one is important.  XML does not easily
> > allow delivery of multiple XML documents or other
> > opaque data types like graphics or MSOffice files.
> > MIME is designed to do just that.
>
> It is easy to set up an HREF from an XML document to a MIME. I don't
> know whether SOAP does it intelligently or not. In Python it would take
> me a couple of lines to get from an HREF to a MIME part so I don't know
> what MIME-RPC adds.

But then you are not interpreting the XML document
correctly.  What happens when an XML schema
conflicts with an the MIME-type of an href'ed
resource.

> There's nothing wrong with RPC if it meets your needs. And MIME-RPC
> seems a good way to do RPC if you are trying to avoid defining an XML
> vocabulary. But I haven't yet seen how a REST web application would take
> advantage of any of the MIME-RPC conventions.

Ok.  So part of what I am saying is that REST only
works for a fairly limited application domain.
However, in the context of REST, I am also saying
that one may want:

* to communicate asynchronously
* to package primitive types with other types
* to interoperate better with web browsers
* to avoid using XML but have unambiguous
semantics

-Alex-


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:150
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 21:02:31
Subject:response in request
Message:

My preference is to not return responses in requests.  First, it requires code
with a whole new kind of meaning to be written.  Second, it overloads existing
semantics without a strict definition of the replacement.  Third, it creates a
need for callbacks within the caller application without defining an interface
to them.

My favorite reason to do it is that it restricts access in a nice
smart-contracts sort of way.

> Asynch Response:
>  - how will status be returned in the final reply?
> I'm suggesting using a content-type of message/http-response which would
> have all the headers of a response. If parsing is an issue, then this could
> be change to a simple 'canonical xml representation of http' (which is
> something i've been wanting to do for a while) or some other format
> indicating status of the response to the initial client request.







-----------------------------------------------------------------------------------
Post ID:151
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-22 21:04:15
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:


Mark Baker wrote:

> Absolutely.  Me thinks Jeff is straying from the opacity "axiom".

IMO, the opacity axiom doesn't mean that URI can't have semantics in a
particular application domain, it just means that (a) the infrastructure
can't assume anything about those semantics, and (b) they should be confined
to the query string.

Any problem?

jb








-----------------------------------------------------------------------------------
Post ID:152
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-22 21:15:42
Subject:Re: [rest-discuss] response in request
Message:

>
> > Asynch Response:
> >  - how will status be returned in the final reply?
So, how /will/ status be returned in the replies (regardless whether you
consider them responses or requests).







-----------------------------------------------------------------------------------
Post ID:153
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 21:20:26
Subject:RE: [rest-discuss] response in request
Message:

In the response body.

This is a good thing because status notifications will have to deal with things
that aren't HTTP.  delivery notifications/ failures/ successes; application
errors with WATCH semantics (e.g. "resource was here when you asked but is now
gone").

> From: S. Mike Dierken [mailto:mdierken@...]
> > >  - how will status be returned in the final reply?
> So, how /will/ status be returned in the replies (regardless whether you
> consider them responses or requests).
>
>







-----------------------------------------------------------------------------------
Post ID:154
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-22 21:34:47
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> Mark Baker wrote:
> 
> > Absolutely.  Me thinks Jeff is straying from the opacity "axiom".
> 
> IMO, the opacity axiom doesn't mean that URI can't have semantics in a
> particular application domain,

It means just that.  As soon as you assign any meaning to a URI, then
only those privy to that meaning are in on your little secrets (like
appending "/subs" means "subscribers to the URI before /subs").
Interoperability means sacrificing private convention for public
specification.  So you make the URI-to-URI relationship explicit with
a statement, such as is done with an HTTP header or an RDF statement,
etc..

> it just means that (a) the infrastructure
> can't assume anything about those semantics, and (b) they should be confined
> to the query string.

It means that too, though even the query string has limits - it's not
fully transparent.  For example, you shouldn't have to know some secret
query parameter a priori in order to accomplish something.  It's on my
todo list to write up my opacity investigation, btw.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:155
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-22 22:04:35
Subject:Re: [rest-discuss] response in request
Message:

----- Original Message -----
From: "Lucas Gonze" <lucas@...>

>
> > From: S. Mike Dierken [mailto:mdierken@...]
> > > >  - how will status be returned in the final reply?
> > So, how /will/ status be returned in the replies (regardless whether you
> > consider them responses or requests).
> >
>
> In the response body.
>
> This is a good thing because status notifications will have to deal with
things
> that aren't HTTP.  delivery notifications/ failures/ successes;
application
> errors with WATCH semantics (e.g. "resource was here when you asked but is
now
> gone").

And the 'resource is now gone' status will be represented as a "404 Not
Found" value in some way?
Also, does that error status indicate whether it is temporary or permanent?









-----------------------------------------------------------------------------------
Post ID:156
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-22 22:17:27
Subject:Re: [rest-discuss] response in request
Message:

> And the 'resource is now gone' status will be represented as a "404 Not
> Found" value in some way?
> Also, does that error status indicate whether it is temporary or permanent?

Sounds like a job for 410 (Gone).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:157
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 22:15:44
Subject:RE: [rest-discuss] response in request
Message:

> And the 'resource is now gone' status will be represented as a "404 Not
> Found" value in some way?
> Also, does that error status indicate whether it is temporary or permanent?

Well, it's an application-level error, not an HTTP error.  There's no HTTP
analog for "was here but is now gone", and I wouldn't attempt to use 404 for it.
Some yet-to-be-invented status scoped within the application specification like
"927 Resource Temporarily Unavailable" seems more appropriate.

Just as a general point about where I'm coming from here -- I believe that this
functionality, whatever it is called, belongs at the application level.








-----------------------------------------------------------------------------------
Post ID:158
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 22:28:21
Subject:Re: [rest-discuss] response in request
Message:

Maybe another way of saying what Lucas is saying is that a notification
is an HTTP *request*, not a response. By definition there can't really
be an HTTP-level problem yet. Mozilla doesn't contact Apache and say:
"something's really screwed up over here."

I think we do need to be able to differentiate between state changes and
deletions. Maybe a header? But a deletion isn't really an error. It's
just a deletion.

If there are notification-related errors that we need to report then
there could be a header for them. In general, existing HTTP status codes
will not be appropriate.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:159
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 22:57:50
Subject:RE: [rest-discuss] response in request
Message:

>
> Maybe another way of saying what Lucas is saying is that a notification
> is an HTTP *request*, not a response. By definition there can't really
> be an HTTP-level problem yet. Mozilla doesn't contact Apache and say:
> "something's really screwed up over here."

Your channelling is uncanny!  ;)

> I think we do need to be able to differentiate between state changes and
> deletions. Maybe a header? But a deletion isn't really an error. It's
> just a deletion.
>
> If there are notification-related errors that we need to report then
> there could be a header for them. In general, existing HTTP status codes
> will not be appropriate.

I believe that this is wierd to think about because *whose* state is involved is
not, in the case of callbacks to report provider-side errors, the server.  So,
rather than reporting server side status, I propose that callbacks to report
status affect the state of a status resource.

PUT /callbacks/stocks/APLX/status HTTP/1.1

410 GONE










-----------------------------------------------------------------------------------
Post ID:160
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-22 23:00:10
Subject:RE: [rest-discuss] Indicating Notifications in HTTP
Message:

> Another option is for the Server to return a "Subscription-URI:" header
> to a GET or HEAD. Then the client knows that it can POST to the
> subscription-URI to get a subscription for this resource.
...
> This maintains the virtue of allowing *any resource* to declare that it
> is watchable without out-of-band arrangement. That's what I'm trying to
> preserve. I don't want a bunch of conventions that client and server
> have to agree to use through email. For simple cases I want it to "just
> work".

I agree that avoiding out of band arrangements is a primary goal, but I believe
that WSDL already meets this need.  In addition, this is metadata about an
application, not protocol-level functionality, so supporting it via special HTTP
headers etc violates opacity.

Proposed solution: have a single out-of-band communication to specify how to
find the WSDL description.  For example:
"The service provider MAY choose to have a file named watch_services.wsdl at
<some well known location>".

At least one incantation will have to be involved, because the service
description bootstraps the entire interaction.

- Lucas







-----------------------------------------------------------------------------------
Post ID:161
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-22 23:27:57
Subject:Re: [rest-discuss] response in request
Message:


> Maybe another way of saying what Lucas is saying is that a notification
> is an HTTP *request*, not a response. By definition there can't really
> be an HTTP-level problem yet. Mozilla doesn't contact Apache and say:
> "something's really screwed up over here."
A notification is a message that describes a request/response pair - the
event that occurred. The event may have completed successfully, or it may
have had an error, or it may have been denied due to permissions. All these
are useful and interesting to convey. Not all subscribers are interested in
all events, and a filtering ability would be a plus - filtering on
request/response headers (including response status).



>
> I think we do need to be able to differentiate between state changes and
> deletions. Maybe a header? But a deletion isn't really an error. It's
> just a deletion.
If you echo (for the most part) the HTTP request that caused the change,
then you'll have knowledge of the operation (type of state change - create,
read, update, delete, add or remove) that ocurred. And if you echo (for the
most part) the response then you'll have knowledge of whether that operation
succeeded or not.
For example if you DELETE  resource, all the watchers also see a DELETE -
not necessarily as requests for them to delete, but notifications of an
event that occurred. And if someone tries to do a DELETE and is that is
denied due to permissions, the watchers will see the response status code
"403 Forbidden" (if you want to get that fine grained, or some criteria
specifies to forward that stuff).
Handy to be alerted about attempted security violations. Model your
application as an information model and notifications directly become state
change events that describe the resource, the operation and result status.
Provide filtering based on all three and you have a very powerful,
composable event system.
WHERE uri="/mike/buddylist" and method="put" and status="success"
WHERE uri="/mike/buddylist" and method="put" and status="denied"
WHERE uri="/mike/buddylist" and method="get" and status="denied"


>
> If there are notification-related errors that we need to report then
> there could be a header for them. In general, existing HTTP status codes
> will not be appropriate.
I disagree that existing status codes will not be appropriate. Any response
to a client request should be echoed - in whole or in part - to the watchers
(filtering and transformation aside). This keeps the burden on the server to
a minimum.








-----------------------------------------------------------------------------------
Post ID:162
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 23:43:52
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

Lucas Gonze wrote:
> 
> ...
> 
> I agree that avoiding out of band arrangements is a primary goal, but I believe
> that WSDL already meets this need.  

Please let's not bring WSDL in! For one thing it works at a totally
different logical level. For another thing its future is controlled by
big companies and surrounded by hordes of patents.

> ... In addition, this is metadata about an
> application, not protocol-level functionality, so supporting it via special HTTP
> headers etc violates opacity.

I tihnk we should think of what we are doing as an extension to the
protocol, not an application. A particular stock site is an application.
The protocol should allow notifications on any kind of site (whether it
be a stock site or otherwise).

> Proposed solution: have a single out-of-band communication to specify how to
> find the WSDL description.  For example:
> "The service provider MAY choose to have a file named watch_services.wsdl at
> <some well known location>".

If you're going to punt in this way, we might as well make it a binary
file format because the WSDL will hide all of the details from the user
anyway. 

> At least one incantation will have to be involved, because the service
> description bootstraps the entire interaction.

I don't need a service description to hook up a web browser to an HTTP
web service like Google. I don't need a service description to hook up a
WebDAV client like Office 2000 to a WebDAV server like Apache+mod_dav.

A big part of standardization is figuring out what is common (e.g. the
idea of notifications) and what is application-specific (e.g.
notifications when a price goes beyond a limit). But you seem not to
want to relegate anything to the common category. It's all application!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:163
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-22 23:50:13
Subject:Re: [rest-discuss] response in request
Message:

"S. Mike Dierken" wrote:
> 
>...
> A notification is a message that describes a request/response pair - the
> event that occurred. 

I guess that's where we disagree fundamentally. A notification is a
message that something has changed. Nothing more, nothing less. In
general, there is no request/response pair. When a message comes through
an EDI backchannel that a stock price (or temperature) has changed, that
is reflected in a series of notifications being sent. There is no
request/response pair to echo. 

If this particular application thought that the details of the EDI
message were important, then I guess that information could be sent in
the BODY of the response. Similarly, if you feel strongly that
request/response pairs should be sent to your clients then you could do
that in a particular application. But I claim that the only
responsibility of the underlying engine is to report that the resource
has been changed or deleted.

But in my mind, the logical model is just: "That resource you asked
about changed or disappeared." What caused the change is, in general,
not the business of the watchers and will more often than not be through
non-HTTP means anyhow.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:164
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 01:09:55
Subject:Re: [rest-discuss] response in request
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>
To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com>
Sent: Tuesday, January 22, 2002 3:50 PM
Subject: Re: [rest-discuss] response in request


> "S. Mike Dierken" wrote:
> >
> >...
> > A notification is a message that describes a request/response pair - the
> > event that occurred.
>
> I guess that's where we disagree fundamentally. A notification is a
> message that something has changed. Nothing more, nothing less. In
> general, there is no request/response pair. When a message comes through
> an EDI backchannel that a stock price (or temperature) has changed, that
> is reflected in a series of notifications being sent. There is no
> request/response pair to echo.

When a message comes through saying that a temperature changed - that
message is already a notification.
When a message causes the temperature to change - that is a request, which
might spawn notifications.
The thing that originates the notification - what kinds of things would it
want to say?
It would say what resource was affected, how it was affected, possibly who
affected it, etc.
What structure and format of names/values would it use?

>
> If this particular application thought that the details of the EDI
> message were important, then I guess that information could be sent in
> the BODY of the response. Similarly, if you feel strongly that
> request/response pairs should be sent to your clients then you could do
> that in a particular application. But I claim that the only
> responsibility of the underlying engine is to report that the resource
> has been changed or deleted.
I underlying engine should only report that the resource has been changed or
deleted - I agree.
But how does it say 'changed' or 'deleted'? I am saying since the resource
is reflected as a URI - otherwise you couldn't subscribe to it - the
notification should be cast in terms of URI modification operations, i.e.
HTTP concepts.

> But in my mind, the logical model is just: "That resource you asked
> about changed or disappeared." What caused the change is, in general,
> not the business of the watchers and will more often than not be through
> non-HTTP means anyhow.
I'm not talking about what caused the change, but the types of operations
that the resources experience - such as create, read, update, delete and
add/remove for collections. These resource manipulation operations are
available via HTTP and communicating the fact that a resource changed should
try to re-use those same concepts.

I suppose you could define a new set of operations with the meaning 'this
resource operation occurred' that are distince from 'perform this resource
operation', but my position is that you don't have to have a distinct set,
you just need to distinguish between 'request' and 'notify'.









-----------------------------------------------------------------------------------
Post ID:165
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-23 01:29:10
Subject:Re: [rest-discuss] response in request
Message:

"S. Mike Dierken" wrote:
> 
>...
> 
> When a message comes through saying that a temperature changed - that
> message is already a notification.

Okay, but maybe it is on a serial line from a thermometer. It isn't
HTTP.

> When a message causes the temperature to change - that is a request, which
> might spawn notifications.

It isn't necessarily an HTTP request.

> The thing that originates the notification - what kinds of things would it
> want to say?

If it's a thermometer it won't say much. "Temperature changed.
Temperature changed. Temperature changed."

But then the HTTP system has to propogate this out through HTTP
notificatoins.

> It would say what resource was affected, how it was affected, possibly who
> affected it, etc.

Only the first is mandatory. You can figure out how it was affected
(i.e. up or down and how many degrees) by doing a GET. It is probably
not useful to report the GPS location of the termometer!

> What structure and format of names/values would it use?

I think that the only thing that must be standardized are the things
that will be useful for most applications. So I would say that it needs
to be able to report the location that changed. That's an HTTP header.

Arguably it should also be able to deliver a representation of the
change or the resource in a standarized way. If so, that's the HTTP
body.

Otherwise you invent your own body formats, maybe your own headers and
you're off to the races.

>...
> I underlying engine should only report that the resource has been changed or
> deleted - I agree.
> But how does it say 'changed' or 'deleted'? I am saying since the resource
> is reflected as a URI - otherwise you couldn't subscribe to it - the
> notification should be cast in terms of URI modification operations, i.e.
> HTTP concepts.

How about:

HTTP-event: POST
HTTP-event: PUT
HTTP-event: DELETE

So a full notification might look like:

POST /your.event.sync
Target-URI: http://www.the.thing.you.were.watching
HTTP-event: PUT

(some proprietary body, or the resource itself if you asked for that)

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:166
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 01:42:38
Subject:Re: [rest-discuss] response in request
Message:

>
> If it's a thermometer it won't say much. "Temperature changed.
> Temperature changed. Temperature changed."
If the gateway doesn't know the value of the temperature from the sensor,
either it gets it right then in order to forward that as part of the
notification, or the notification doesn't say the 'temperature' change, it
says the 'status of thermometer' changed - the resource that changed isn't
one that holds the value for 'temperature', which would imply two URIs.

This is getting too complicated.
Do you have any HTTP event systems to play with? Doing it with real working
code is much much more educational.

If you don't, go and grab KnowNow's event router and bang out some
javascript listeners.
If you are into Java servlets, check out
http://www.sourceforge.net/projects/destiny/ - i'll see if I can get it
running somewhere public next week.

mike






-----------------------------------------------------------------------------------
Post ID:167
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-23 03:05:11
Subject:Re: [rest-discuss] response in request
Message:

"S. Mike Dierken" wrote:
> 
>...
> If the gateway doesn't know the value of the temperature from the sensor,
> either it gets it right then in order to forward that as part of the
> notification, or the notification doesn't say the 'temperature' change, it
> says the 'status of thermometer' changed - the resource that changed isn't
> one that holds the value for 'temperature', which would imply two URIs.

I am completely not following you.

1. Somehow a physical thermometer changes a byte in RAM or on disk and
informs a piece of software that it has done so.

2. There is Web gateway software that exposes this byte as a resource: 

 * http://www.weather.com/90210/temperature : "5"

3. The Web gateway software tells anyone who has registered to watch
that URL that it has been changed.

4. If they want the new value, they can GET it. Or they could have
registered that they want inline values earlier. The notification
probably looks like this:

POST www.mymicroserver.com/mysubscriptions/23123
Target-URI: http://www.weather.com/90210/temperature
HTTP-method: PUT

(maybe message body here, maybe not)

 5. There is another URI. It *represents* the subscription. If the
client just wants to let the subscription peter out, it can ignore that
URI. If it wants to actively manage it then it needs to work with the
subscription URI.

> This is getting too complicated.
> Do you have any HTTP event systems to play with? Doing it with real working
> code is much much more educational.
> 
> If you don't, go and grab KnowNow's event router and bang out some
> javascript listeners.

I can't see any connection point between what we've been talking about
and what they have implemented. They have a "do_method" thingee that
seems basically RPC-ish. The payload is a header? They have explicit
event routing? It seems to be inherently peer-to-peer whereas HTTP's
underlying model is client/server. Overall, it seems much more
complicated than what I was thinking of.

Most important, I can't figure out how to do what I want to do which is
ask to be notified when a web resource changes its value. As far as I
can tell, the "gateway" would have to publish to the "topic". Merely
changing a resource is not sufficient to trigger a message. But maybe I
misunderstand that part.

> If you are into Java servlets, check out
> http://www.sourceforge.net/projects/destiny/ - i'll see if I can get it
> running somewhere public next week.

I'm not really sure that we should use a message queuing paradigm as a
starting point. I think that an HTTP API for JMS would turn quite
different than a notifications mechanism for the Web.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:168
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-23 04:29:45
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

On Tue, 22 Jan 2002, Jeff Bone wrote:
> Subscription / notification is really a rather application-specific thing.  It's
> not clear to me that a generic subscription / notification mechanism justifies
> polluting the method space rather than just coming up with some generic
> conventions, nor is it clear that adding such a method will spur universal
> development and interoperability of async HTTP applications.  IMO, it's a losing
> proposition all the way around, compared to other alternatives.

Its hard to believe, but I find myself in raging
agreement with Jeff here.  A big reason why is
the degree of control applications need over the
meaning of change and the potential volume of data
being transmitted.

For example, an application subscribing to the
current value of the S&P 500 index might not want
to recieve an update on every trade of every stock
in the S&P 500, but rather might prefer an update
every minute during the trading day (and none when
trading is not happening).

Alternatively, suppose an application subscribes
to a document enumerating the current value of
every stock traded on the exchange.  Repeatedly
sending the URL of this page is much less useful
than just sending the content of each trade.

In theory one might define a generic notion of
sparse (time based) notification, but I am not at
all confident that it would cover all required
application semantics.  Moreover even if one
could, I don't think you could then avoid having
to specify the meaning of delta.

As an aside, doesn't Chunk encoding also cover
some of the application domain.  i.e. open a
connection to some URL and get streamed deltas as
long as the connection is open.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:169
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 04:52:56
Subject:Re: [rest-discuss] response in request
Message:

> >...
> > If the gateway doesn't know the value of the temperature from the
sensor,
> > either it gets it right then in order to forward that as part of the
> > notification, or the notification doesn't say the 'temperature' change,
it
> > says the 'status of thermometer' changed - the resource that changed
isn't
> > one that holds the value for 'temperature', which would imply two URIs.
>
> I am completely not following you.
Okay - my message was convoluted & wrong.
What you say below is goodness. The identification of the resource that
changed and the operation that occurred is what I like. I would also like
status - in order to learn about attempted changes that didn't happen.

>
> 1. Somehow a physical thermometer changes a byte in RAM or on disk and
> informs a piece of software that it has done so.
>
> 2. There is Web gateway software that exposes this byte as a resource:
>
>  * http://www.weather.com/90210/temperature : "5"
>
> 3. The Web gateway software tells anyone who has registered to watch
> that URL that it has been changed.
>
> 4. If they want the new value, they can GET it. Or they could have
> registered that they want inline values earlier. The notification
> probably looks like this:
>
> POST www.mymicroserver.com/mysubscriptions/23123
> Target-URI: http://www.weather.com/90210/temperature
> HTTP-method: PUT
>
> (maybe message body here, maybe not)
>
>  5. There is another URI. It *represents* the subscription. If the
> client just wants to let the subscription peter out, it can ignore that
> URI. If it wants to actively manage it then it needs to work with the
> subscription URI.
>
> > This is getting too complicated.
> > Do you have any HTTP event systems to play with? Doing it with real
working
> > code is much much more educational.
> >
> > If you don't, go and grab KnowNow's event router and bang out some
> > javascript listeners.
>
> I can't see any connection point between what we've been talking about
> and what they have implemented. They have a "do_method" thingee that
> seems basically RPC-ish.
Hey now, I like that do_method thingee. (if they had any balls it would've
been do:method)

> The payload is a header? They have explicit
> event routing? It seems to be inherently peer-to-peer whereas HTTP's
> underlying model is client/server. Overall, it seems much more
> complicated than what I was thinking of.
Some things had to be sacrificed for browser accessibility.

>
> Most important, I can't figure out how to do what I want to do which is
> ask to be notified when a web resource changes its value. As far as I
> can tell, the "gateway" would have to publish to the "topic". Merely
> changing a resource is not sufficient to trigger a message. But maybe I
> misunderstand that part.
Yes, the KN server is a message server, it hosts subscriptions and routes
events. It is not a filter on existing servers.
Somebody could write a mod_watch that did the same stuff and echoed actual
HTTP requests (and their responses)

If you have an application that knows about changes, but isn't directly URI
addressable, you can use their stuff to bounce messages around rather than
implementing your own subscription/notification system.

Here's a sample message exchange

-- create a subscription --
POST http://www.topiczero.com:8000/kn/prescod.net/temperature/ HTTP/1.1
Content-Type: application/x-www-form-url-encoded

do_method=route
&kn_to=http://www.prescod.net/receivers/temperature/

-- some time passes... --

-- post a notification --
POST http://www.topiczero.com:8000/kn/prescod.net/temperature/ HTTP/1.1
Content-Type: application/x-www-form-url-encoded

kn_payload=98.6

-- here comes the message --
POST http://www.prescod.net/receivers/temperature/ HTTP/1.1
Content-Type: application/x-www-form-url-encoded

kn_payload=98.6
&kn_id=uniqueMessageID
&kn_time_t=979273892
&kn_route_id=some_more_useful_stuff


>
> > If you are into Java servlets, check out
> > http://www.sourceforge.net/projects/destiny/ - i'll see if I can get it
> > running somewhere public next week.
>
> I'm not really sure that we should use a message queuing paradigm as a
> starting point. I think that an HTTP API for JMS would turn quite
> different than a notifications mechanism for the Web.
Calling out 'jms' was just a ploy - I want that project to be an asynch HTTP
service implemented as a servlet.
That's one way to get it started - but I'll ensure RESTfulness as I go.








-----------------------------------------------------------------------------------
Post ID:170
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 04:55:55
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> As an aside, doesn't Chunk encoding also cover
> some of the application domain.  i.e. open a
> connection to some URL and get streamed deltas as
> long as the connection is open.

Chunked just allows content to be sent without pre-computing Content-Length.
It must be omitted. Each chunk has its own length, follwed by a zero-length
chunk (or stuff like that).
Each chunk does not represent the full content, only a range. You could do
tricky things with it, like send deltas, but I wouldn't recommend it.
(Unless you are writing a book on 'how to abuse HTTP for dummies').








-----------------------------------------------------------------------------------
Post ID:171
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-23 04:58:30
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

On Tue, 22 Jan 2002, S. Mike Dierken wrote:
> Each chunk does not represent the full content, only a range. You could do
> tricky things with it, like send deltas, but I wouldn't recommend it.
> (Unless you are writing a book on 'how to abuse HTTP for dummies').

This is no more abuse then sending requests as
responses or vice-versa :-).

-Alex-


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:172
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 17:02:22
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> On Tue, 22 Jan 2002, S. Mike Dierken wrote:
> > Each chunk does not represent the full content, only a range. You could
do
> > tricky things with it, like send deltas, but I wouldn't recommend it.
> > (Unless you are writing a book on 'how to abuse HTTP for dummies').
>
> This is no more abuse then sending requests as
> responses or vice-versa :-).
>
I respectfully disagree - sending requests as responses or vice versa is
allowed if the content-type identifies it as such, and the URI behaves like
a first-class web resource.
Sending pieces via chunked encoding is okay of the resource identifies is a
compound resource - a collection. For example, if you defined a content-type
application/folder-contents (or something) and did a GET on a folder,
sending the content of each file in that folder would be reasonable (from
some point of view). Things that can go wrong with this is the sending of
resources not via their URI - but since each resource can any any number of
equivalent URIs I suppose that is okay.







-----------------------------------------------------------------------------------
Post ID:173
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 17:14:00
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> ----- Original Message -----
> From: "Mark Baker" <distobj@...>

>
> FWIW, we at PF struggled with this some time ago, but what we have now
> is *lean*, I mean completely kick ass.  It's a shame we're not even
> releasing free binaries (nevermind source).  It does everything you're
> talking about here, but so much more.

Cool - now that we know it is possible, we'll just built it open source.
Thanks! ;)








-----------------------------------------------------------------------------------
Post ID:174
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-23 17:29:04
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> > On Tue, 22 Jan 2002, S. Mike Dierken wrote:
> > > Each chunk does not represent the full content, only a range. You could
> do
> > > tricky things with it, like send deltas, but I wouldn't recommend it.
> > > (Unless you are writing a book on 'how to abuse HTTP for dummies').
> >
> > This is no more abuse then sending requests as
> > responses or vice-versa :-).
> >
> I respectfully disagree - sending requests as responses or vice versa is
> allowed if the content-type identifies it as such, and the URI behaves like
> a first-class web resource.

I think that opens up a huge pandora's box of issues.

If it's "just another content type", then because the end-to-end model
has to be respected, it's a kind of "mandatory" content type for
intermediaries.  It couldn't just be passed-through as most
intermediaries do, it would have to be cracked open and processed
on each hop.

It's an interesting idea that could probably be specified, but I don't
see a great need for it today, plus mandatory extensions haven't been
deployed and this needs them.  Maybe later.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:175
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-01-23 17:31:19
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "Lucas Gonze" <lucas@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Tuesday, January 22, 2002 7:09 AM
Subject: Re: [rest-discuss] Indicating Notifications in HTTP


>
> > > If so, the header there works quite differently
> > > than just "Reply-To".
> >
> > Explain?
>
> Just like I said here;
>
> http://groups.yahoo.com/group/rest-discuss/message/47
>
> The active header is "Properties" (from DAV), plus the extension is
> really the "watch" modifier of it that says we're looking at the
> watch property.
>

Ooh, I like this. Modeling a 'property' as a collection that is URI
addressable. Using POST to 'add' to a collection (is that create+insert or
just insert?).
But how do people know that 'properties' is a name (in the response headers)
to use? Is defined by DAV or something?
How do people know ";name" is the format of URIs? Have you figured out the
opacity issues?
Given that the technology of the day (.asp .jsp) doesn't allow for 'extra
path info' you will see urls for properties like:
http://www.clewless.com/monitors/subs.asp?customer=27

Try appending ";subscriptions" on the end of that.

Might need multiple response headers or a single multi-valued header.









-----------------------------------------------------------------------------------
Post ID:176
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-23 17:33:01
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> Cool - now that we know it is possible, we'll just built it open source.
> Thanks! ;)

I'm just giving away the basics.  We've got a lot of value-add on top
that is specific for solving wireless integration issues.  We also have
another router that isn't pub/sub, it just does forward and reverse
static routes.  It's actually our most mature product because we started
out with it.  The pub/sub router was an afterthought, but it's now well
integrated into our product line.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:177
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 17:40:49
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>


> > Mark Baker wrote:
> >
> > > Absolutely.  Me thinks Jeff is straying from the opacity "axiom".
> >
> > IMO, the opacity axiom doesn't mean that URI can't have semantics in a
> > particular application domain,
>
> It means just that.  As soon as you assign any meaning to a URI, then
> only those privy to that meaning are in on your little secrets (like
> appending "/subs" means "subscribers to the URI before /subs").
> Interoperability means sacrificing private convention for public
> specification.  So you make the URI-to-URI relationship explicit with
> a statement, such as is done with an HTTP header or an RDF statement,
> etc..
>
That statement (the name and location of the information) is still a little
secret that only those in the know.
However, it may be better to move that out of the URI, and also do something
to ensure backward compatibility - like defining these as 'advisory' and
optional. These turns the http response into a multi-link (or something -
Paul, help me out here) with named references to interesting sub-properities
of the resource. If those sub-properties are addressable, they are also
probably subscribable. So a DAV Properties: specified URI should be
listenable for just property (not content) changes.

If an HTTP WATCH method were to be used, would OPTIONS return that fact?
Does it operate per resource? (ignoring the extra requests to figure stuff
out)









-----------------------------------------------------------------------------------
Post ID:178
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 17:45:37
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "S. Mike Dierken" <mdierken@...>
Cc: "S. Alexander Jacobson" <alex@...>; <rest-discuss@yahoogroups.com>
Sent: Wednesday, January 23, 2002 9:29 AM
Subject: Re: [rest-discuss] Indicating Notifications in HTTP


> > >
> > I respectfully disagree - sending requests as responses or vice versa is
> > allowed if the content-type identifies it as such, and the URI behaves
like
> > a first-class web resource.
>
> I think that opens up a huge pandora's box of issues.
>
> If it's "just another content type", then because the end-to-end model
> has to be respected, it's a kind of "mandatory" content type for
> intermediaries.  It couldn't just be passed-through as most
> intermediaries do, it would have to be cracked open and processed
> on each hop.

I think I understand - since the requests and responses are the way
intermediaries understand the resource system (the Web) and maintain useful
state about them (deleted, created, etc.) if the requests and responses
aren't right there at the top, then they would pass through intermediaries,
but the intermediaries would be blind to the information and not able to
currently reflect the state of the resourc system (no cache updates, etc.)

I hadn't gone to that extent, and while I agree with you, I'm more
interested in providing functionality to firewalled nodes than in preserving
the public state of the resource system, mainly because I don't think the
resources are that public, and also the traffic probably would pass through
a special gateway and beyond that the requests & responses would be at the
top of the stream.












-----------------------------------------------------------------------------------
Post ID:179
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-23 17:51:27
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

Ok.  I'll bite.  Just for fun:
If I want to use chunked encoding to send a
stockmarket feed, then the chunks are just
individual trades over the course of the duration
the stream is fed.  The document content-type
would be something like
application/x-stock-trades.

This is perfectly HTTP legal and not very abusive
because the client has no way to tell if sending
delays are caused by network congestion, server
load, or actually waiting for the trades to
complete.

OTOH, sending a HTTP reply in a request begs all
sorts of questions about error handling, response
structure, proxies, etc.

-Alex-



On Wed, 23 Jan 2002, S. Mike Dierken wrote:

>
> > On Tue, 22 Jan 2002, S. Mike Dierken wrote:
> > > Each chunk does not represent the full content, only a range. You could
> do
> > > tricky things with it, like send deltas, but I wouldn't recommend it.
> > > (Unless you are writing a book on 'how to abuse HTTP for dummies').
> >
> > This is no more abuse then sending requests as
> > responses or vice-versa :-).
> >
> I respectfully disagree - sending requests as responses or vice versa is
> allowed if the content-type identifies it as such, and the URI behaves like
> a first-class web resource.
> Sending pieces via chunked encoding is okay of the resource identifies is a
> compound resource - a collection. For example, if you defined a content-type
> application/folder-contents (or something) and did a GET on a folder,
> sending the content of each file in that folder would be reasonable (from
> some point of view). Things that can go wrong with this is the sending of
> resources not via their URI - but since each resource can any any number of
> equivalent URIs I suppose that is okay.
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:180
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-23 18:00:03
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> I hadn't gone to that extent, and while I agree with you, I'm more
> interested in providing functionality to firewalled nodes than in preserving
> the public state of the resource system, mainly because I don't think the
> resources are that public, and also the traffic probably would pass through
> a special gateway and beyond that the requests & responses would be at the
> top of the stream.

Ok, but that is not really HTTP anymore.  It is
something else entirely.  You probably want to
use MIME-RPC which makes this all fairly
straightforward (and can be carried over HTTP).

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax









-----------------------------------------------------------------------------------
Post ID:181
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-23 18:01:55
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

"S. Alexander Jacobson" wrote:
> 
> On Tue, 22 Jan 2002, Jeff Bone wrote:
> > Subscription / notification is really a rather application-specific thing.  It's
> > not clear to me that a generic subscription / notification mechanism justifies
> > polluting the method space rather than just coming up with some generic
> > conventions, nor is it clear that adding such a method will spur universal
> > development and interoperability of async HTTP applications.  IMO, it's a losing
> > proposition all the way around, compared to other alternatives.
> 
> Its hard to believe, but I find myself in raging
> agreement with Jeff here.  A big reason why is
> the degree of control applications need over the
> meaning of change and the potential volume of data
> being transmitted.

I agree that there must be a way for applications to implement
filtering. I don't think that means that the basic behaviour cannot be
standardized. When I "PUT" a purchase order, the HTTP spec. doesn't tell
me what I should do once I get it. The basic model is that the thing is
available like a file for subsequent GETs. But a particular application
could do much more sophisticated stuff.

Also, how do I "filter" Google when I do a search? It doesn't return the
whole Google database, right? There are an essentially infinite number
or URIs available. So what if you use query parameters to say that the
resource you want to watch is one that only changes every fifteen
minutes, or only changes when a price goes beyond a particular value.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:182
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-23 18:08:36
Subject:Opacity, ";"
Message:

> Ooh, I like this. Modeling a 'property' as a collection that is URI
> addressable. Using POST to 'add' to a collection (is that create+insert or
> just insert?).
> But how do people know that 'properties' is a name (in the response headers)
> to use? Is defined by DAV or something?

Yep.

> How do people know ";name" is the format of URIs? Have you figured out the
> opacity issues?

It's on my todo list.  I haven't figured out ";" yet though, but when I
do I'll write up all my findings on "?" and "/".

Roy used that notation first.  It suggests to me that its meaning can
have a wider scope than just the URI to which it's appended.  If so,
that's pretty darned useful, though less opaque (which is ok, as long
as its interpretation is uniform).  It appears to work like a HTTP
header.  But it is not itself a URI, so perhaps a registry is needed,
or we can figure out a way of making it a URI.

> Given that the technology of the day (.asp .jsp) doesn't allow for 'extra
> path info' you will see urls for properties like:
> http://www.clewless.com/monitors/subs.asp?customer=27
> 
> Try appending ";subscriptions" on the end of that.

I've heard that deployed URI support is actually pretty good, except
maybe in some funky cases like http://foo.com/bar;q?a=b

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:183
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-23 18:12:05
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> I think I understand - since the requests and responses are the way
> intermediaries understand the resource system (the Web) and maintain useful
> state about them (deleted, created, etc.) if the requests and responses
> aren't right there at the top, then they would pass through intermediaries,
> but the intermediaries would be blind to the information and not able to
> currently reflect the state of the resourc system (no cache updates, etc.)

Right.

> I hadn't gone to that extent, and while I agree with you, I'm more
> interested in providing functionality to firewalled nodes than in preserving
> the public state of the resource system, mainly because I don't think the
> resources are that public, and also the traffic probably would pass through
> a special gateway and beyond that the requests & responses would be at the
> top of the stream.

If you're going to do that, you at least need a gateway that can
terminate the HTTP chain so that end-to-end behaviour is guaranteed
(i.e. move the "end" in 8-).  Just recognize that you're doing this,
and don't try to pretend that you're doing HTTP behind the gateway
or that will just cause more trouble.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:184
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 18:48:05
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

----- Original Message -----
From: "S. Alexander Jacobson" <alex@...>


> Ok.  I'll bite.  Just for fun:
> If I want to use chunked encoding to send a
> stockmarket feed, then the chunks are just
> individual trades over the course of the duration
> the stream is fed.  The document content-type
> would be something like
> application/x-stock-trades.
>
> This is perfectly HTTP legal and not very abusive
> because the client has no way to tell if sending
> delays are caused by network congestion, server
> load, or actually waiting for the trades to
> complete.
That is true. If the content type and resource is modeled as a collection of
trades, it looks fine to me (not that I'm any judge...).
And if the resource is modelled as a collection of messages - like a message
queue - the same thing applies (using chunked transfer encoding is a nice
optimization in this case). Thats what the Destiny project on SourceForge
does - keeps returning messages from the collection (the queue).

>
> OTOH, sending a HTTP reply in a request begs all
> sorts of questions about error handling, response
> structure, proxies, etc.
>
Cool. My stuff is more abusive than yours - I'll write the book then. ;)
I agree that tunnelling has more http level problems than long-lived
responses. I just think it is useful for firewalled systems.








-----------------------------------------------------------------------------------
Post ID:185
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 18:52:17
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>


>
> > I hadn't gone to that extent, and while I agree with you, I'm more
> > interested in providing functionality to firewalled nodes than in
preserving
> > the public state of the resource system, mainly because I don't think
the
> > resources are that public, and also the traffic probably would pass
through
> > a special gateway and beyond that the requests & responses would be at
the
> > top of the stream.
>
> If you're going to do that, you at least need a gateway that can
> terminate the HTTP chain so that end-to-end behaviour is guaranteed
> (i.e. move the "end" in 8-).  Just recognize that you're doing this,
> and don't try to pretend that you're doing HTTP behind the gateway
> or that will just cause more trouble.
>

If I wanted to model the resource system as an addressable collection of
messages, what would the HTTP requests and responses look like? Especially
if those messages were literally HTTP request and response formats? Like
blindly logging all web server activity and having an analysis program
consume those from disk via HTTP.






-----------------------------------------------------------------------------------
Post ID:186
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 18:54:13
Subject:Re: [rest-discuss] Opacity, ";"
Message:

> > Given that the technology of the day (.asp .jsp) doesn't allow for
'extra
> > path info' you will see urls for properties like:
> > http://www.clewless.com/monitors/subs.asp?customer=27
> >
> > Try appending ";subscriptions" on the end of that.
>
> I've heard that deployed URI support is actually pretty good, except
> maybe in some funky cases like http://foo.com/bar;q?a=b
>

What do you mean by 'deployed URI support'?
Is the ';' a special character in URI that is meant to be dealt with by
clients parsing URIs?







-----------------------------------------------------------------------------------
Post ID:187
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-23 19:04:35
Subject:Re: [rest-discuss] Opacity, ";"
Message:

> > I've heard that deployed URI support is actually pretty good, except
> > maybe in some funky cases like http://foo.com/bar;q?a=b
> >
> 
> What do you mean by 'deployed URI support'?

Just what's out there in browsers, servers, URI parsing libraries, etc..

> Is the ';' a special character in URI that is meant to be dealt with by
> clients parsing URIs?

Yep.  See RFC 2396.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:188
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-23 19:17:49
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

Mark Baker wrote:

> > Mark Baker wrote:
> >
> > > Absolutely.  Me thinks Jeff is straying from the opacity "axiom".
> >
> > IMO, the opacity axiom doesn't mean that URI can't have semantics in a
> > particular application domain,
>
> It means just that.

Come on.  That's nice in theory, but it's just neither true nor desirable in
practice.  URI *always* (and should!) have some associated semantics in the
higher-level application domain in question.  For example, in the following:

    http://www.amazon.com/exec/obidos/ASIN/0674000781/

the part following ASIN/ has the semantics "an ISBN."  Note that I'm not claiming
that Amazon exposes a particularly RESTful resource model, just that modeling
books as resources identified in some collection via ISBNs does not by itself
violate opacity or break REST.  A better resource model might be:

    http://www.amazon.com/books/ISBNs/0674000781

The opacity axiom simply says that the underlying application --- HTTP ---
shouldn't ever have to know anything about books.  It doesn't say that a
bookselling application shouldn't model and expose those abstractions through the
URI space.  Indeed, doing so is a RESTful thing, isn't it?   It also doesn't say
that a set of book-oriented applications from various developers should not or
could not agree on a conventional method of modeling books, collections of books,
etc. as resources.

> As soon as you assign any meaning to a URI, then
> only those privy to that meaning are in on your little secrets (like
> appending "/subs" means "subscribers to the URI before /subs").

And this is just fine for "applications" that don't live at the same level of
generalization as HTTP.  The issue at hand is whether "events", pub / sub,
notifications, etc. constitute a (or several) higher abstraction / application
domain(s) like "book-oriented applications" (perhaps lower level than that, but
higher level than HTTP per se) or whether they belong at the level of generality
of HTTP.  My argument is that they belong at a higher level, for several reasons:

  (1)  Use of event notification differs from app domain to app domain
  (2)  It's difficult IMO to provide useful notification generalizations
  (3)  The higher levels of abstraction are more "fungible" in some sense
 tentative  (4)  In general we should be reluctant to extend rather than just use
HTTP as-is

> It means that too, though even the query string has limits - it's not
> fully transparent.  For example, you shouldn't have to know some secret
> query parameter a priori in order to accomplish something.

This is another assertion that is meaningful in a philosophical sense but not in
practical application.  It depends on what it is you want to accomplish.  For
example, of course I'm going to need to know a secret (parameter names or order,
etc.) to accomplish something useful in a particular domain --- such as querying a
search engine.

Bottom line, opacity doesn't IMO literally say that URI shouldn't have semantics
*at all.*  It says that those semantics belong outside the realm of HTTP and URI
as such, and rather belong to and should be interpreted in the context of some
application domain.  Defining that context shared by applications in a given
domain is the purview of the developers of those applications, and that context
--- its resource models, conventions, etc. --- do indeed constititute a "shared
secret" among the producers and consumers of the functionality in question.  This
doesn't break interface generality either;  it just recognizes that there's an
irreducible amount of functionality that should be exposed, and leaves it up to
the developer to expose that by leveraging and without breaking the semantics of
HTTP.

That's my current working hypothesis, anyway.  Open to revision.

> It's on my
> todo list to write up my opacity investigation, btw.

Looking forward to it.

jb








-----------------------------------------------------------------------------------
Post ID:189
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-23 19:24:32
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

Jeff Bone wrote:
> 
>...
> 
> The opacity axiom simply says that the underlying application --- HTTP ---
> shouldn't ever have to know anything about books.  It doesn't say that a
> bookselling application shouldn't model and expose those abstractions through the
> URI space.  Indeed, doing so is a RESTful thing, isn't it?   

Agree. 

> ... It also doesn't say
> that a set of book-oriented applications from various developers should not or
> could not agree on a conventional method of modeling books, collections of books,
> etc. as resources.

They can agree on the modelling, if it makes them feel good. But they
should not standardize it in software. If they want to be able to go
(let's say) from a book's page to it's author's page, software should
not blindly add /author. Rather it should look for an
<author>...</author> XML tag. That allows the person maintaining the
site to move author elements to a totally different site if they decide
that is better. They update all of their <author>...</author> tags and
they are done.

Consider if the original web had said that after you are done with a
form it is automatically POSTed to the original URI + /process_form. It
would have seemed fine at the time but then later when people wanted  to
make little form fields that search Google, they wouldn't have been able
to.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:190
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-23 19:30:20
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> > > IMO, the opacity axiom doesn't mean that URI can't have semantics in a
> > > particular application domain,
> >
> > It means just that.
> 
> Come on.  That's nice in theory, but it's just neither true nor desirable in
> practice.  URI *always* (and should!) have some associated semantics in the
> higher-level application domain in question.  For example, in the following:
> 
>     http://www.amazon.com/exec/obidos/ASIN/0674000781/
> 
> the part following ASIN/ has the semantics "an ISBN."  Note that I'm not claiming
> that Amazon exposes a particularly RESTful resource model, just that modeling
> books as resources identified in some collection via ISBNs does not by itself
> violate opacity or break REST.  A better resource model might be:
> 
>     http://www.amazon.com/books/ISBNs/0674000781
> 
> The opacity axiom simply says that the underlying application --- HTTP ---
> shouldn't ever have to know anything about books.  It doesn't say that a
> bookselling application shouldn't model and expose those abstractions through the
> URI space.  Indeed, doing so is a RESTful thing, isn't it?   It also doesn't say
> that a set of book-oriented applications from various developers should not or
> could not agree on a conventional method of modeling books, collections of books,
> etc. as resources.

Hmm, maybe I was unclear on what you meant by "application domain".
Obviously each resource publisher can have their own conventions.
What I thought you were saying was that Amazon and B&N had to have
similar looking URIs.  That would be a Bad Thing.

> > As soon as you assign any meaning to a URI, then
> > only those privy to that meaning are in on your little secrets (like
> > appending "/subs" means "subscribers to the URI before /subs").
> 
> And this is just fine for "applications" that don't live at the same level of
> generalization as HTTP.  The issue at hand is whether "events", pub / sub,
> notifications, etc. constitute a (or several) higher abstraction / application
> domain(s) like "book-oriented applications" (perhaps lower level than that, but
> higher level than HTTP per se) or whether they belong at the level of generality
> of HTTP.  My argument is that they belong at a higher level, for several reasons:
> 
>   (1)  Use of event notification differs from app domain to app domain

Just like how retrieving a picture of a book is different than
retrieving an HTML page of me? 8-)

>   (2)  It's difficult IMO to provide useful notification generalizations
>   (3)  The higher levels of abstraction are more "fungible" in some sense
>  tentative  (4)  In general we should be reluctant to extend rather than just use
> HTTP as-is

Or just make sure "WATCH" is as generic as GET.  Uh oh, I've said
too much. 8-)

> Bottom line, opacity doesn't IMO literally say that URI shouldn't have semantics
> *at all.*  It says that those semantics belong outside the realm of HTTP and URI
> as such, and rather belong to and should be interpreted in the context of some
> application domain.

I couldn't disagree more.  URIs should be as opaque as possible, so that
any information about them and their relationships can be made explicit
within the HTTP application model.  If I can't do a GET on a URI to find
out about its relationships with other resources, then that information
isn't on the Web, and that's naughty.

> That's my current working hypothesis, anyway.  Open to revision.

Good to hear. 8-)

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:191
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-23 19:54:19
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:


"S. Alexander Jacobson" wrote:

> On Tue, 22 Jan 2002, S. Mike Dierken wrote:
> > Each chunk does not represent the full content, only a range. You could do
> > tricky things with it, like send deltas, but I wouldn't recommend it.
> > (Unless you are writing a book on 'how to abuse HTTP for dummies').

Or "How to Abuse HTTP for Fun and Profit."  One of those books on the list of
"if I ever get around to it..." ;-)  Akshully, Mike, weren't we talking about
that at one point?

jb








-----------------------------------------------------------------------------------
Post ID:192
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 20:02:18
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

>
> They can agree on the modelling, if it makes them feel good. But they
> should not standardize it in software. If they want to be able to go
> (let's say) from a book's page to it's author's page, software should
> not blindly add /author. Rather it should look for an
> <author>...</author> XML tag. That allows the person maintaining the
> site to move author elements to a totally different site if they decide
> that is better. They update all of their <author>...</author> tags and
> they are done.

Where <author> is a named property and its value is a reference (whose value
space is the URI space)?

Providing these 'named backpointers' is good - lets address de-referencing
to be changed locally.
There is still coordination between parties, but only on names and semantics
of properties (and their location) and not syntax (references remain
opaque).

It can be problematic to provide these backpointers when also carrying other
content in a response - not that a header won't work, but that some clients
can't get to it. What do you guys think?






-----------------------------------------------------------------------------------
Post ID:193
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-23 20:52:38
Subject:HTTP Event Conventions
Message:

http://www.prescod.net/HTTP_event_conventions.html

I wrote this up in a rush so it isn't 100% coherent but it's a starting
place for what I've been thinking about. It addresses many of the
concerns that people have raised in one message or another. 

Mike B: It can watch any resource.

Mike D: Notifications must say what kind of action happened.

Jeff B: Any notification syntax is allowed. Query-like triggers can be
handled (as they are on today's web) through POST parameters.

Lucas: Limited support for working with environments where you do not
control headers.

Alex: It uses MIME. ;)

It's about a million miles from being complete but in my mind it has a
certain coherence and elegance.

Now I've got to try and do real work for a few days...

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:194
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-23 21:24:40
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:


Paul Prescod wrote:

> http://www.prescod.net/HTTP_event_conventions.html

This is actually really good as a starting point.  Only a few changes and
this could IMO fully describe what I've in the past called "the switchboard
pattern" for handling not only asynchrony but also asymmetry of connectivity
for general HTTP communication.  If it won't step on your toes, Paul, I'm
willing to take the pen and make a rev of this.

> Now I've got to try and do real work for a few days...

I tried to do that over the last 24 hours, and look what happened... ;-)

jb








-----------------------------------------------------------------------------------
Post ID:195
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 21:58:54
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> Or "How to Abuse HTTP for Fun and Profit."  One of those books on the list
of
> "if I ever get around to it..." ;-)  Akshully, Mike, weren't we talking
about
> that at one point?
yep - look like i've got a good one for abusing the messaging
characterstics.
Using chunked encoding to do streaming audio or video might be another - but
that's probably what its meant for so we'd have to do something weird on top
of it.






-----------------------------------------------------------------------------------
Post ID:196
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-23 22:06:27
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:

Er...couldn't we discuss your changes before putting them right in the
spec? Oh damn. I'm not supposed to do any more talking. Okay, go
ahead...but be gentle. It's just a baby spec.

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> > http://www.prescod.net/HTTP_event_conventions.html
> 
> This is actually really good as a starting point.  Only a few changes and
> this could IMO fully describe what I've in the past called "the switchboard
> pattern" for handling not only asynchrony but also asymmetry of connectivity
> for general HTTP communication.  If it won't step on your toes, Paul, I'm
> willing to take the pen and make a rev of this.
> 
> > Now I've got to try and do real work for a few days...
> 
> I tried to do that over the last 24 hours, and look what happened... ;-)
> 
> jb






-----------------------------------------------------------------------------------
Post ID:197
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-23 22:21:42
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:

Some comments;

"X-Event-Subscription".  How about just "Subscriptions", since
that better describes it's role; a container for subscriptions.

If the Location header on a subscription response is a MAY, how does
one unsubscribe?  Should also mention use of 200/201/204 response
codes on a POST action here too.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:198
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 22:23:47
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:

Nifty. I'd like to see one for detailing 'best practices' for "202
Accepted" - but I just don't have the time right now...

All in all this is a really wonderful wrap up of where we are at today!
Who is ready to start coding? If you are Java friendly, I'd like to suggest
starting with http://www.sourceforge.com/projects/destiny - I know it talks
about JMS, but it's more important that it is an HTTP messaging server.

---

Some comments:

1 "The response to the Subscription MAY include a Location..."
Do you mean: "The response to [creating] the subscription..."

2 "Event: (CHANGED|EXTENDED|DELETED|ADDED|(or application defined)) "
I strongly think these should be based on create, read, update, delete
[operations on atomic information] and add and remove [operations on
collections]. There should be a map to what HTTP methods typically would
generate (as you've indicated in the document). I've spent a lot of time
thinking about this one and would like to continue discussions on this
point.
I also believe 'user defined' is to be avoided in the same way that new
methods in http are to be avoided.
If it comes to a problem with flexibility describing the change to the
resource - I highly recommend using 'sub-properties' in the same sense as
pointed out by MarkB relating to the ";" in urls. This 'sub-property' is
controlled by the resource, but not necessarily independently addressable.
If it were addressable, then it would be subscribable, and those
subscriptions would receive the event.
For example, listening to a users online status might be:
Target-URI: http://www.topiczero.com:8000/kn/who/dierken.com/mike/
Property: presence
Operation: update

3 "some form of "difference" may suffice "
Content negotiation is goodness. Personally, I'd avoid 'delta' events, due
to problems with often needing guaranteed delivery and sequence. Sending
temperature as "up:3" isn't as good as "98". But I understand that sometimes
deltas are okay.

4 "the Event Sink may email notifications "
You will probably want user-agent metadata on the subscription (what
user-agent, what content-type, and what form of content-type (like different
approaches to html mail)). Something for the future, but make sure there is
room later.

5 "may define a convention for using query parameters..."
Yay! I realize this is a short-term hack for backward compatibility - but
you gotta do what you gotta do...

6 "HTTP-equiv could also be used "
Nifty.

7 "browser would ask the user"
This would probably (d)evolve into HTML in the same way that HTTP
authentication evolved into custom HTML forms for logging in. Don't
underestimate the power of the marketing side.











-----------------------------------------------------------------------------------
Post ID:199
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-23 22:33:56
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:

----- Original Message ----- 
From: "Mark Baker" <distobj@...>


> Some comments;
> 
> "X-Event-Subscription".  How about just "Subscriptions", since
> that better describes it's role; a container for subscriptions.
> 
> If the Location header on a subscription response is a MAY, how does
> one unsubscribe?  Should also mention use of 200/201/204 response
> codes on a POST action here too.
> 

Look at the bottom of your email:

> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 

a) POST to 'subscribe-uri' and POST to 'unsubscribe-uri' 
b) POST to 'subscriptions-uri' and DELETE to 'subscriptions-uri' 







-----------------------------------------------------------------------------------
Post ID:200
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-23 23:04:58
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

On Wed, 23 Jan 2002, Paul Prescod wrote:
> Also, how do I "filter" Google when I do a search? It doesn't return the
> whole Google database, right? There are an essentially infinite number
> or URIs available. So what if you use query parameters to say that the
> resource you want to watch is one that only changes every fifteen
> minutes, or only changes when a price goes beyond a particular value.

The difference is that I can use both TCP/IP flow
control and connection termination to prevent
myself from being choked if Google did choose to
send its whole database.

In the case of asynch, the notification URL is at
risk of being DOSed by an overwhelming number of
requests.

More generally, it feels like many things are sort
of generic but not generic enough.

e.g.
expiration on time/volume/price
the content of notification (the diff may be
smaller than the URL)
send every x minutes only if changed
etc.

I read your proposal and it looks nice.  I just
don't know how much application domain it really
covers.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:201
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-23 23:07:41
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:


Paul Prescod wrote:

> Er...couldn't we discuss your changes before putting them right in the
> spec?

Sorry, I wasn't implying that I'm highjacking the content.  I was just offering to
do a style / clarity / consistency / completeness pass to push it along while you
get some work done.  :-)  It can always be tossed.  I think substantial extensions
to realize e.g. the full switchboard pattern can wait.

> Oh damn. I'm not supposed to do any more talking. Okay, go
> ahead...but be gentle. It's just a baby spec.

'Natch. :-)

jb








-----------------------------------------------------------------------------------
Post ID:202
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-23 23:17:26
Subject:Re: [rest-discuss] Opacity, ";"
Message:

Dont check a mailbox for two days and look what happens... 128
messages? argh.


On Wed, Jan 23, 2002 at 01:08:36PM -0500, Mark Baker wrote:
> > How do people know ";name" is the format of URIs? Have you
> > figured out the opacity issues?
> 
> It's on my todo list.  I haven't figured out ";" yet though, but
> when I do I'll write up all my findings on "?" and "/".

Would like to see those...


> Roy used that notation first.  It suggests to me that its meaning
> can have a wider scope than just the URI to which it's appended. 
> If so, that's pretty darned useful, though less opaque (which is
> ok, as long as its interpretation is uniform).  It appears to work
> like a HTTP header.  But it is not itself a URI, so perhaps a
> registry is needed, or we can figure out a way of making it a URI.

Do you have any references for these uses? I was under the impression
that parameters were just as opaque as any other URI component;
servers certainly seem to treat them as such. IIRC they were
originally introduced to enable VMS files (with versions) to be
easily URIified.


> I've heard that deployed URI support is actually pretty good, except
> maybe in some funky cases like http://foo.com/bar;q?a=b

Python's urlparse is broken; it assumes that you can only
parameterise the last path segment, not every path segment. As a
result, 
  http://www.example.com/foo;bar/baz?bat
gets parsed as
 ('http', 'www.example.com', 'foo', 'bar/baz' 'bat' '')


-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:203
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-23 23:53:16
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:

You should take a look at WEBI[1][2]; with a bit of work with an eye
to the audience/requirements[3], this could easily be a candidate
(connectivity monitoring is the only thing that really stands out, at
first glance).

I'd very much encourage you to consider this; if someone's
interested, please drop me a line.


[1] http://www.mnot.net/papers/ietf-49-wrec.pdf
[2] http://www.ietf.org/html.charters/webi-charter.html
[3] http://www.ietf.org/internet-drafts/draft-ietf-webi-rup-reqs-02.txt



On Wed, Jan 23, 2002 at 12:52:38PM -0800, Paul Prescod wrote:
> http://www.prescod.net/HTTP_event_conventions.html
> 
> I wrote this up in a rush so it isn't 100% coherent but it's a starting
> place for what I've been thinking about. It addresses many of the
> concerns that people have raised in one message or another. 
> 
> Mike B: It can watch any resource.
> 
> Mike D: Notifications must say what kind of action happened.
> 
> Jeff B: Any notification syntax is allowed. Query-like triggers can be
> handled (as they are on today's web) through POST parameters.
> 
> Lucas: Limited support for working with environments where you do not
> control headers.
> 
> Alex: It uses MIME. ;)
> 
> It's about a million miles from being complete but in my mind it has a
> certain coherence and elegance.
> 
> Now I've got to try and do real work for a few days...
> 
>  Paul Prescod
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:204
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-24 01:28:16
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:

> Look at the bottom of your email:
>
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> > 
> 
> a) POST to 'subscribe-uri' and POST to 'unsubscribe-uri' 
> b) POST to 'subscriptions-uri' and DELETE to 'subscriptions-uri' 

Yah, but a) isn't good container based design, because their states are
entangled; a POST in one effects a delete in the other.  b) is the
proper way to do it.  Hence the need for at least a SHOULD on the
Location header.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:205
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-24 01:31:11
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:

Mark Baker wrote:
> 
>...
> 
> Yah, but a) isn't good container based design, because their states are
> entangled; a POST in one effects a delete in the other.  b) is the
> proper way to do it.  Hence the need for at least a SHOULD on the
> Location header.

Agreed. I was trying to lower the bar for minimal implementations. I
think that Mike's idea of an unsub URI might not be a terrible fallback
for if software doesn't support DELETE.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:206
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-24 01:48:27
Subject:Re: [rest-discuss] Opacity, ";"
Message:

> > Roy used that notation first.  It suggests to me that its meaning
> > can have a wider scope than just the URI to which it's appended. 
> > If so, that's pretty darned useful, though less opaque (which is
> > ok, as long as its interpretation is uniform).  It appears to work
> > like a HTTP header.  But it is not itself a URI, so perhaps a
> > registry is needed, or we can figure out a way of making it a URI.
> 
> Do you have any references for these uses? I was under the impression
> that parameters were just as opaque as any other URI component;
> servers certainly seem to treat them as such. IIRC they were
> originally introduced to enable VMS files (with versions) to be
> easily URIified.

I was just extrapolating from Roy's example.  He's a good reference. 8-)
I'll check out 2396 on the issue later (oh my, is my todo list ever
getting big!).

> > I've heard that deployed URI support is actually pretty good, except
> > maybe in some funky cases like http://foo.com/bar;q?a=b
> 
> Python's urlparse is broken; it assumes that you can only
> parameterise the last path segment, not every path segment. As a
> result, 
>   http://www.example.com/foo;bar/baz?bat
> gets parsed as
>  ('http', 'www.example.com', 'foo', 'bar/baz' 'bat' '')

Yah, I heard that urlparse was quite bad, but I take it that it's an
exception.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:207
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-24 06:39:17
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>
> >...
> >
> > Yah, but a) isn't good container based design, because their states are
> > entangled; a POST in one effects a delete in the other.  b) is the
> > proper way to do it.  Hence the need for at least a SHOULD on the
> > Location header.
>
> Agreed. I was trying to lower the bar for minimal implementations. I
> think that Mike's idea of an unsub URI might not be a terrible fallback
> for if software doesn't support DELETE.
>
It's not really my idea - just pointing out a common way its done in todays
world.








-----------------------------------------------------------------------------------
Post ID:208
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-24 06:40:26
Subject:Reliable HTTP
Message:

Maybe of interest to you:

http://www.prescod.net/reliable_http.html

Comments are welcome.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:209
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-24 07:13:05
Subject:Why is HTTP hard to design with?
Message:

(This has been said by other people in other places, probably better than I,
but here goes anyway...)

I've been going over the discussions about the asynchronous capabilities of
HTTP and what to do about the missing pieces and have some discomforting
thoughts.

We all know what it means when we say 'pub/sub' and 'notification' or
request and response or messaging, but when we say "And now for the HTTP..."
we all disagree.
Here we are, a bunch of bright experienced technology people, and there is
no obvious way to map a known concept like pub/sub into HTTP. It's a grab
bag of methods, uri, headers, content, query terms, uri 'parameters' (where
did those come from?), and so on. "Get any little piece wrong", we say to
ourselves, "and kiss interoperability and scalability goodbye". Sure, there
may be a 'good' way of doing it, but there is no clear right or wrong and
multiple independent attempts will arrive at different results.

I don't think it is just that we are unfamiliar with HTTP, or even that we
are unfamiliar with the concepts of ReST, but I think trying to take a model
(pub/sub or rdbms or whatever) map it to another model (ReST) and at the
same time map it to a 'wire format' - something gets lost in the
translation.

I don't see a trend for web applications converging on common approaches of
using HTTP for a lot of cases, because most web applications talk to
themselves - the only interoperation is through a link and a GET. They can
put data in any slot without breaking anything because they wrote both the
client and the server. Look at the many ways of doing user login - almost
none of them use HTTP security constructs - and things still work.

Through the discussion on this form I've learned a /lot/ about designing
with HTTP. There may be compromises to that design to work with existing
infrastructure (browsers, asp/jsp, etc.), as well as further compromises to
achieve some measure of end-user usability, but I'm happy with what I've
learned.

Something that would help me in the future is to model a large
information-centric applications (including security and events) and create
a direct mapping into URIs and HTTP. If anybody has any thoughts or
experience with this, give me a shout. (The kind of thing I'm thinking about
is like an 'object oriented web' but 'OO' isn't appropriate. Components and
interfaces are closer. Entity-relationship from rdbms and OMT/UML notation
is closer still.)

Mike








-----------------------------------------------------------------------------------
Post ID:210
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-24 07:22:27
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>


> > Look at the bottom of your email:
> >
> > > To unsubscribe from this group, send an email to:
> > > rest-discuss-unsubscribe@yahoogroups.com
> > >
> >
> > a) POST to 'subscribe-uri' and POST to 'unsubscribe-uri'
> > b) POST to 'subscriptions-uri' and DELETE to 'subscriptions-uri'
>
> Yah, but a) isn't good container based design, because their states are
> entangled; a POST in one effects a delete in the other.  b) is the
> proper way to do it.  Hence the need for at least a SHOULD on the
> Location header.
>
(btw 'Entangled' is a great term).

I like the 'collection/container' based approach also, but was just pointing
out a common alternative.

I had a thought - your 'good container design' comment about a) mentions
that a post in one causes a delete in the other. Does this imply that a
resource that is a collection must/should be disjoint from all other
addressable collections? Does this imply aliases are to be avoided?
If aliases or overlapping collections exist, and events are to be routed, an
event in one would/should cause an event in the other(s)? If something is
addressable, it is subscribable. If aliases exist, multiple subscriptions
via the aliases and there should not be one 'preferred' alias.

Also, regarding uri 'parameters' (which I have not read up on, so correct
any and all misconceptions) - if these are unique identifiers yet guaranteed
to informationally subordinate to the non-parameterized uri, then you have
what appears to be an overlapping collection - with the 'parent' resource
channeling events for the 'sub-properties'. The sub-properties may be
available for fine-grained subscriptions (mini-filters) and the main
resource is avialable for catch-all subscriptions. A bit
stream-of-unconciousness, but I hope that made sense.









-----------------------------------------------------------------------------------
Post ID:211
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-24 07:44:43
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:

More comments:
8) Status
If a notification of an event is 'about' a resource, you may want to know
about attempted operations that failed.
The HTTP status codes do a good job of categorizing things (client error,
server error, security, etc.)

9) lifetime
Events are about the lifecycle of resources, and you may want to know about
a resource before it is created and after it is deleted. In a class and
instance based system, you could create a subscription that was interested
in a 'type' of instance being created ('tell me when a new purchase order is
created'). In a purely instance based system (like the web) you typically
use containers to represent that ('tell me when a new resource is added to
'pending purchase orders'). The resource 'pending purchase orders' might
only support events and not enumeration.
When a resource is deleted, the uri is still valid and usable - a saving
grace of the web - so that isn't a problem. I've worked with db systems that
used referential integrity and 'referencing' delete entities was a 'bit' of
a problem.

2b) More 'operation' stuff
If there is a concept of 'add' or 'added', then there is concept of
collection - another fuzzy area of the Web. I commonly use a model that
supports collections in a nice way - resources have named properties,
properties can be an atomic value or a collection. These named properties
(atomic or collection) are subscribable (which implies referenceable), but
not directly addressable (retrievable?). The operations of 'add/remove'
would apply to these collection properties, and 'update' would apply to the
atomic properties. Subscriptions on the resource imply a subscription on all
sub-properties as well. I've also allowed a subscription to indicate
multiple operations, but on the Web I'd be okay with one per subscription
(otherwise you get into managing a collection of criteria... but maybe a
subscription uri with a ";criteria" parameter would work...).

For example:

WATCH http://www.topiczero.com:8000/kn/who/prescod.net/paul;presence
HTTP/1.1
ReplyTo: http://nomad.dierken.com/followme/instantmsg.cgi
Accept: text/xml

WATCH http://www.topiczero.com:8000/kn/who/dierken.com/mike;buddies HTTP/1.1
ReplyTo: http://nomad.dierken.com/followme/instantmsg.cgi
Accept: text/xml



----- Original Message -----
From: "S. Mike Dierken" <mdierken@...>
To: <rest-discuss@yahoogroups.com>; "Paul Prescod" <paul@...>
Sent: Wednesday, January 23, 2002 2:23 PM
Subject: Re: [rest-discuss] HTTP Event Conventions


>
> Nifty. I'd like to see one for detailing 'best practices' for "202
> Accepted" - but I just don't have the time right now...
>
> All in all this is a really wonderful wrap up of where we are at today!
> Who is ready to start coding? If you are Java friendly, I'd like to
suggest
> starting with http://www.sourceforge.com/projects/destiny - I know it
talks
> about JMS, but it's more important that it is an HTTP messaging server.
>
> ---
>
> Some comments:
>
> 1 "The response to the Subscription MAY include a Location..."
> Do you mean: "The response to [creating] the subscription..."
>
> 2 "Event: (CHANGED|EXTENDED|DELETED|ADDED|(or application defined)) "
> I strongly think these should be based on create, read, update, delete
> [operations on atomic information] and add and remove [operations on
> collections]. There should be a map to what HTTP methods typically would
> generate (as you've indicated in the document). I've spent a lot of time
> thinking about this one and would like to continue discussions on this
> point.
> I also believe 'user defined' is to be avoided in the same way that new
> methods in http are to be avoided.
> If it comes to a problem with flexibility describing the change to the
> resource - I highly recommend using 'sub-properties' in the same sense as
> pointed out by MarkB relating to the ";" in urls. This 'sub-property' is
> controlled by the resource, but not necessarily independently addressable.
> If it were addressable, then it would be subscribable, and those
> subscriptions would receive the event.
> For example, listening to a users online status might be:
> Target-URI: http://www.topiczero.com:8000/kn/who/dierken.com/mike/
> Property: presence
> Operation: update
>
> 3 "some form of "difference" may suffice "
> Content negotiation is goodness. Personally, I'd avoid 'delta' events, due
> to problems with often needing guaranteed delivery and sequence. Sending
> temperature as "up:3" isn't as good as "98". But I understand that
sometimes
> deltas are okay.
>
> 4 "the Event Sink may email notifications "
> You will probably want user-agent metadata on the subscription (what
> user-agent, what content-type, and what form of content-type (like
different
> approaches to html mail)). Something for the future, but make sure there
is
> room later.
>
> 5 "may define a convention for using query parameters..."
> Yay! I realize this is a short-term hack for backward compatibility - but
> you gotta do what you gotta do...
>
> 6 "HTTP-equiv could also be used "
> Nifty.
>
> 7 "browser would ask the user"
> This would probably (d)evolve into HTML in the same way that HTTP
> authentication evolved into custom HTML forms for logging in. Don't
> underestimate the power of the marketing side.
>







-----------------------------------------------------------------------------------
Post ID:212
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-24 07:54:08
Subject:Re: [rest-discuss] Reliable HTTP
Message:

Just this part, is worth its weight in gold - all web app developers should
burn this into their brains:

"One way to make sure that your data gets through is to try and try again
until you get a proper acknowledgement. If the action you were completing is
"idempotent" then by definition it is safe to try again and again until it
succeeds. The HTTP GET, PUT and DELETE methods are idempotent. If you think
about them as if they were file system commands it should be clear why. It
never hurts to read a file over and over again. It also does not hurt to
write a file over and over again as long as you are writing the same data.
And deleting a file repeatedly will at most give you an error message.

On the other hand, the POST command is sort of like adding to a file. You
can see how adding the same data to a file over and over again is very
different than merely overwriting the file with the same data over and over
again. POSTed data often accumulates. Because POSTed data accumulates we
need to make certain that we set up our system so that multiple POSTs of the
same data are not harmful."


----- Original Message -----
From: "Paul Prescod" <paul@...>
To: <rest-discuss@yahoogroups.com>; <fnparr@...>;
<mconner@...>; <stephen_todd@...>
Sent: Wednesday, January 23, 2002 10:40 PM
Subject: [rest-discuss] Reliable HTTP


> Maybe of interest to you:
>
> http://www.prescod.net/reliable_http.html
>
> Comments are welcome.
>
>  Paul Prescod
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:213
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-24 07:58:11
Subject:Re: [rest-discuss] Reliable HTTP
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>


> Maybe of interest to you:
>
> http://www.prescod.net/reliable_http.html
>
> Comments are welcome.
>

While you are at it, could you formalize with your golden pen the 'best
practices' regarding "202 Accepted" (asynchronous response)?

Mike








-----------------------------------------------------------------------------------
Post ID:214
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-24 08:01:18
Subject:Re: [rest-discuss] Reliable HTTP
Message:

When I am next in Seattle you can dictate and I'll write down. I don't
know anything about this stuff unless Mark Baker told me it. I am just
the prophet.

Plus I don't have any time to write more right now because I have to
attend to profit. (or at least break-even)

"S. Mike Dierken" wrote:
> 
> ----- Original Message -----
> From: "Paul Prescod" <paul@...>
> 
> > Maybe of interest to you:
> >
> > http://www.prescod.net/reliable_http.html
> >
> > Comments are welcome.
> >
> 
> While you are at it, could you formalize with your golden pen the 'best
> practices' regarding "202 Accepted" (asynchronous response)?
> 
> Mike
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/






-----------------------------------------------------------------------------------
Post ID:215
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-24 08:31:03
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Mike Dierken" wrote:
>
> ...
> 
> I don't think it is just that we are unfamiliar with HTTP, or even that we
> are unfamiliar with the concepts of ReST, but I think trying to take a model
> (pub/sub or rdbms or whatever) map it to another model (ReST) and at the
> same time map it to a 'wire format' - something gets lost in the
> translation.

Is HTTP design harder than object oriented or relational or functional
design? I think it is just another one of those Zens that domain-elite
computer programmers need to pick up and mediocre ones kind of emulate
by osmosis.

Having to deal with a wire format adds some headache but hey, I learned
OO programming using C++. Talk about an additional hurdle! Luckily it
wasn't as frighteningly convoluted in the early days as it is now.

> I don't see a trend for web applications converging on common approaches of
> using HTTP for a lot of cases, because most web applications talk to
> themselves - the only interoperation is through a link and a GET. They can
> put data in any slot without breaking anything because they wrote both the
> client and the server. Look at the many ways of doing user login - almost
> none of them use HTTP security constructs - and things still work.

That's why nobody understands REST. They didn't have to understand the
Web to use it. They memorize a few rules (hopefully!) like GET puts
things in the URL. POST changes a database and so forth.

Web services are different. You want web services to work like "the
web". You want thousands of independently designed clients and servers
for the more interesting ones. Maybe the majority of small point to
point web services will use RPC. If that works for them, fine! But I
hope and expect that the people designing reusable protocols for use
with multiple clients and servers will learn about REST.

> ...
> Something that would help me in the future is to model a large
> information-centric applications (including security and events) and create
> a direct mapping into URIs and HTTP. 

Er. Wasn't that your last job?

In fact, when I started hearing about REST I remember thinking: "that
Dierken lunatic was on to something!"

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:216
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-24 14:47:51
Subject:Markety name
Message:

My article is going to be published in a couple of weeks and I'd like to
think of that as the first wave in a marketing campaign that will get
the web services world to start re-evaluating what we have. The rest of
you geeks are probably more concerned with substance over style so I
doubt I'll get much uptake on this suggestion. Nevertheless...it's worth
a try.

Frankly, I think the name "REpresentational State Transfer" sucks. Maybe
when I get more REST-Zen I'll think that the core idea in the web
architecture is the transfer of state representations but right now I
think that's just one issue, along with unified naming conventions,
generic methods, standardization of content types, client-side
scripting, etc. The whole architecture has no single clear defining
characteristic so I don't think it should be named after a particular
one. 

Okay, REST isn't going away but maybe we can have a different name when
the style is applied to so-called "Web services". I propose World Wide
Web Architectural Style : WWWAS

Using the full form of "the Web" may get people thinking back to roots.
It is not an English word so a single essay will score easily in Google.
WWWAS would individuate itself (informally) from REST over a while by
adopting standardized XML formats that apply to web services problems.
Or maybe WWWAS is REST+XML and everything XML allows.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:217
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-24 15:32:19
Subject:Re: [rest-discuss] Markety name
Message:

> Frankly, I think the name "REpresentational State Transfer" sucks. Maybe

The full name won't make much sense to most people, but "REST" is a
memorable word.  "SOAP" doesn't mean "Simple Object Access Protocol"
anymore, so perhaps you can use the term without getting into what
it means.

> when I get more REST-Zen I'll think that the core idea in the web
> architecture is the transfer of state representations but right now I
> think that's just one issue, along with unified naming conventions,
> generic methods, standardization of content types, client-side
> scripting, etc. The whole architecture has no single clear defining
> characteristic so I don't think it should be named after a particular
> one. 

Well, REST is that.  The implications of doing state transfer include
needing some common minimal interface, need a way to identify the
things that have state, etc..

No single name could capture everything you want to talk about above,
because not all of them are architectural issues.

> Okay, REST isn't going away but maybe we can have a different name when
> the style is applied to so-called "Web services". I propose World Wide
> Web Architectural Style : WWWAS
> 
> Using the full form of "the Web" may get people thinking back to roots.
> It is not an English word so a single essay will score easily in Google.
> WWWAS would individuate itself (informally) from REST over a while by
> adopting standardized XML formats that apply to web services problems.
> Or maybe WWWAS is REST+XML and everything XML allows.

Ick, I don't care for it much.

If I was describing REST, then I would personally feel obligated to
use the name.  The last thing we need is to have to explain the
relationship between REST and whatever new name you come up with
for whatever it is you're trying to identify.  Please try to avoid
defining a new term.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:218
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-24 16:53:21
Subject:Re: [rest-discuss] Markety name
Message:

Paul, I gotta disagree on this one.  I think REST is a good name ---
notwithstanding the problem with existing English terms, it states
specifically and tersely *the* core idea.  (I.e., I think you're wrong --
REpresentational State Transfer *is* the single, clear, defining
characteristic, and the key differentiator between the original Web concept
(transfer object state / representations, all objects have a generic and
distributable interface and semantics) and any of a number of appropriate and
inappropriate technologies that have accreted around the Web.  WWWAS sound
like yet another bs tech-elite jargon / acronym, and surely we've had (a)
enough of those, and (b) enough of those with "www" embedded in them.
Referring to something as WWWAS also runs the risk of being a hotbed of
disagreement as to what constitutes the Web's architecture;  REST runs this
risk, too, but is potentially much more contained.

$0.02,

jb

Paul Prescod wrote:

> My article is going to be published in a couple of weeks and I'd like to
> think of that as the first wave in a marketing campaign that will get
> the web services world to start re-evaluating what we have. The rest of
> you geeks are probably more concerned with substance over style so I
> doubt I'll get much uptake on this suggestion. Nevertheless...it's worth
> a try.
>
> Frankly, I think the name "REpresentational State Transfer" sucks. Maybe
> when I get more REST-Zen I'll think that the core idea in the web
> architecture is the transfer of state representations but right now I
> think that's just one issue, along with unified naming conventions,
> generic methods, standardization of content types, client-side
> scripting, etc. The whole architecture has no single clear defining
> characteristic so I don't think it should be named after a particular
> one.
>
> Okay, REST isn't going away but maybe we can have a different name when
> the style is applied to so-called "Web services". I propose World Wide
> Web Architectural Style : WWWAS
>
> Using the full form of "the Web" may get people thinking back to roots.
> It is not an English word so a single essay will score easily in Google.
> WWWAS would individuate itself (informally) from REST over a while by
> adopting standardized XML formats that apply to web services problems.
> Or maybe WWWAS is REST+XML and everything XML allows.
>
>  Paul Prescod
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:219
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-24 17:00:08
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:

> (btw 'Entangled' is a great term).

Yah, I thought so.  I was recently reading about entangled photons,
and the word stuck.

> I like the 'collection/container' based approach also, but was just pointing
> out a common alternative.
> 
> I had a thought - your 'good container design' comment about a) mentions
> that a post in one causes a delete in the other. Does this imply that a
> resource that is a collection must/should be disjoint from all other
> addressable collections?

Just MAY.  There may be good reasons for not doing this, but absent any
requirements to the contrary, I think this is a cleaner way to go.

> Does this imply aliases are to be avoided?

By "alias", I assume you mean where a single resource publisher has
different URIs that identify the same resource.

That's a good rule, generally, no?

> If aliases or overlapping collections exist, and events are to be routed, an
> event in one would/should cause an event in the other(s)? If something is
> addressable, it is subscribable. If aliases exist, multiple subscriptions
> via the aliases and there should not be one 'preferred' alias.

There appears to be words missing from that last sentence, but if I
understand you correctly, yes, there needs to be consistent behaviour
for what a subscribe/unsubscribe means on aliases.

> Also, regarding uri 'parameters' (which I have not read up on, so correct
> any and all misconceptions) - if these are unique identifiers yet guaranteed
> to informationally subordinate to the non-parameterized uri, then you have
> what appears to be an overlapping collection - with the 'parent' resource
> channeling events for the 'sub-properties'. The sub-properties may be
> available for fine-grained subscriptions (mini-filters) and the main
> resource is avialable for catch-all subscriptions. A bit
> stream-of-unconciousness, but I hope that made sense.

Er, nope. 8-)  What's a subproperty?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:220
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-24 16:58:54
Subject:Re: [rest-discuss] Markety name
Message:

Okay. I didn't think it would go over well. Just a shot in the dark.

Consider that Simple Object Access Protocol sounds MUCH BETTER than SOAP
actually is!

But okay, I won't push it. We'll be stuck with a weird name forever. ;)

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:221
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-24 17:02:15
Subject:Re: [rest-discuss] Reliable HTTP
Message:

> "One way to make sure that your data gets through is to try and try again
> until you get a proper acknowledgement. If the action you were completing is
> "idempotent" then by definition it is safe to try again and again until it
> succeeds. The HTTP GET, PUT and DELETE methods are idempotent. If you think
> about them as if they were file system commands it should be clear why. It
> never hurts to read a file over and over again. It also does not hurt to
> write a file over and over again as long as you are writing the same data.
> And deleting a file repeatedly will at most give you an error message.

PUT is idempotent, but it also has side effects.  You have to be wary of
that.  See;

http://www.w3.org/1999/04/Editing/

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:222
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-24 17:08:44
Subject:Re: [rest-discuss] Reliable HTTP
Message:

> When I am next in Seattle you can dictate and I'll write down. I don't
> know anything about this stuff unless Mark Baker told me it. I am just
> the prophet.

Heh.

> Plus I don't have any time to write more right now because I have to
> attend to profit. (or at least break-even)

The prophet attends to profit. Cute.

> > While you are at it, could you formalize with your golden pen the 'best
> > practices' regarding "202 Accepted" (asynchronous response)?

WRT to reliable HTTP?

202 is one way of managing disconnected operations.  See;

http://lists.xml.org/archives/xml-dev/200201/msg01222.html

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:223
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-24 17:23:51
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

> > ...
> > Something that would help me in the future is to model a large
> > information-centric applications (including security and events) and
create
> > a direct mapping into URIs and HTTP.
>
> Er. Wasn't that your last job?
Yes - but I didn't do a rigorous job with the http parts (headers, etc.) and
had to make it work in a browser, and had to explain why url addressability
is a Good Thing every other week. And try to learn what we were doing and so
on. I failed of course, but I learned a lot.

>
> In fact, when I started hearing about REST I remember thinking: "that
> Dierken lunatic was on to something!"
>
On something, or on to something?







-----------------------------------------------------------------------------------
Post ID:224
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-24 17:27:49
Subject:Re: [rest-discuss] Markety name
Message:

brainstorming - but I like ReST the BeST - 

Web Applications Next Generation (WANG)
XML Applications Next Generation (XANG)
Web Service Interoperability Next Gen (WSing)


----- Original Message ----- 
From: "Paul Prescod" <paul@...>
To: <rest-discuss@yahoogroups.com>
Sent: Thursday, January 24, 2002 6:47 AM
Subject: [rest-discuss] Markety name


> My article is going to be published in a couple of weeks and I'd like to
> think of that as the first wave in a marketing campaign that will get
> the web services world to start re-evaluating what we have. The rest of
> you geeks are probably more concerned with substance over style so I
> doubt I'll get much uptake on this suggestion. Nevertheless...it's worth
> a try.
> 
> Frankly, I think the name "REpresentational State Transfer" sucks. Maybe
> when I get more REST-Zen I'll think that the core idea in the web
> architecture is the transfer of state representations but right now I
> think that's just one issue, along with unified naming conventions,
> generic methods, standardization of content types, client-side
> scripting, etc. The whole architecture has no single clear defining
> characteristic so I don't think it should be named after a particular
> one.
> 
> Okay, REST isn't going away but maybe we can have a different name when
> the style is applied to so-called "Web services". I propose World Wide
> Web Architectural Style : WWWAS
> 
> Using the full form of "the Web" may get people thinking back to roots.
> It is not an English word so a single essay will score easily in Google.
> WWWAS would individuate itself (informally) from REST over a while by
> adopting standardized XML formats that apply to web services problems.
> Or maybe WWWAS is REST+XML and everything XML allows.
> 
>  Paul Prescod
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> 
> 
> 






-----------------------------------------------------------------------------------
Post ID:225
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-24 17:29:14
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:

> > If aliases or overlapping collections exist, and events are to be
routed, an
> > event in one would/should cause an event in the other(s)? If something
is
> > addressable, it is subscribable. If aliases exist, multiple
subscriptions
> > via the aliases and there should not be one 'preferred' alias.
>
> There appears to be words missing from that last sentence, but if I
> understand you correctly, yes, there needs to be consistent behaviour
> for what a subscribe/unsubscribe means on aliases.

Yes - my mistake.

"If aliases exist, multiple subscriptions [exist] via the aliases and there
should not be one 'preferred' alias."







-----------------------------------------------------------------------------------
Post ID:226
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-24 17:28:53
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Mike Dierken" wrote:
> 
> ...
> > In fact, when I started hearing about REST I remember thinking: "that
> > Dierken lunatic was on to something!"
> >
> On something, or on to something?

Yes.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:227
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-24 17:32:54
Subject:RE: [rest-discuss] Why is HTTP hard to design with?
Message:

I don't know yet if HTTP has to be hard to design with, but I agree that it is
at present.  The amount of obscurantia needed is very large; few people outside
of the standards development community have it.  Witness that REST advocates
regularly need to point to primary materials such as
http://www.w3.org/1999/04/Editing/override-entry.txt and RFCs.

What is missing is concise documentation related to HTTP semantics.  Things like
RFC 2616 need to cover too much turf for non-fanatics to find answers in a
timely way.  Eg, wading through a sea of BNF diagrams to glean semantics is
impractical.

I wouldn't blame this on HTTP.  The REST design style is at a stage where lore
is passed on person to person.  This can change if anybody takes the initiative
to develop documentation for a general audience.  The REST Wiki is a beginning.










-----------------------------------------------------------------------------------
Post ID:228
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-24 17:36:30
Subject:Re: [rest-discuss] Reliable HTTP
Message:

Mark Baker wrote:
> 
>> > "One way to make sure that your data gets through is to try and try again
> > until you get a proper acknowledgement. If the action you were completing is
> > "idempotent" then by definition it is safe to try again and again until it
> > succeeds. The HTTP GET, PUT and DELETE methods are idempotent. 
> 
> PUT is idempotent, but it also has side effects.  You have to be wary of
> that.  See;
> 
> http://www.w3.org/1999/04/Editing/

I agree that lost update is a problem. I don't see how it relates to
"PUT also has side effects." Overwriting someone else's data is not a
side effect in the traditional sense!

Do you think that the issue is sufficiently related to reliability to
mention it in that essay?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:229
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-24 18:13:30
Subject:Re: [rest-discuss] Reliable HTTP
Message:

> I agree that lost update is a problem. I don't see how it relates to
> "PUT also has side effects." Overwriting someone else's data is not a
> side effect in the traditional sense!
> 
> Do you think that the issue is sufficiently related to reliability to
> mention it in that essay?

Well, it's just that you said that you can keep invoking PUT over and
over, which is true, but you have to be aware that you may be stomping
over somebody else's changes.  Yes, I think this relates to
reliability quite closely.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:230
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-24 18:49:55
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Wed, 23 Jan 2002, S. Mike Dierken wrote:
> I've been going over the discussions about the asynchronous capabilities of
> HTTP and what to do about the missing pieces and have some discomforting
> thoughts.
> We all know what it means when we say 'pub/sub' and 'notification' or
> request and response or messaging, but when we say "And now for the HTTP..."
> we all disagree.

Thats because we are talking about using HTTP to
implement something that isn't the domain of HTTP.
HTTP was designed to be a synchronous,
client/server, connectionless protocol.  It was
designed to let clients request/update resources
from a server simply and easily.

It was not designed for asynch, p2p, chat, or
distributed computation.  When using HTTP for any
of these things we are simply designing a new
protocol on top of a set of HTTP primitives.  It
is far from clear that the optimal design for an
asynch protocol is to ride on top of HTTP.

Much as it would not be surprising if we disagreed
about the best design for an email system using
C++ and the STL, it should not be at all
surprising that we disgaree when using HTTP.
There is much too much distance between the
application domain and the tools we are using.

> I don't see a trend for web applications converging on common approaches of
> using HTTP for a lot of cases, because most web applications talk to
> themselves - the only interoperation is through a link and a GET. They can
> put data in any slot without breaking anything because they wrote both the
> client and the server. Look at the many ways of doing user login - almost
> none of them use HTTP security constructs - and things still work.

I agree.  That was part of the motivation for
MIME-RPC.  But I would say something stronger.
Most organizations are designing for internal use
or to bind customers/suppliers closer to
themselves.  They prefer to expose their
organizational constructs over the internet rather
than modify their organizational constructs match
those of HTTP.

To put it another way, they are designing
applications not protocols.

> Something that would help me in the future is to model a large
> information-centric applications (including security and events) and create
> a direct mapping into URIs and HTTP. If anybody has any thoughts or
> experience with this, give me a shout. (The kind of thing I'm thinking about
> is like an 'object oriented web' but 'OO' isn't appropriate. Components and
> interfaces are closer. Entity-relationship from rdbms and OMT/UML notation
> is closer still.)

I tried to open this discussion earlier, but got
no response.   I asked for a REST consisten way of
implementing terrorist_or_not.com (a made up
application).

The idea is that security checkpoints send front
and side views of individuals to some server and
the server sends back information about whether
the person looks like a known terrorist in the
database.

We can add the complexity that processing the
request may take long enough for the response to
arrive back asynchronously (but sometimes the
server can decide quickly).

I think the implementation is straightforward
using MIME-RPC (because it can get much closer to
application level semantics).  The REST
implementation is much less obvious (at least to
me).

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:231
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-24 19:07:45
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

----- Original Message -----
From: "S. Alexander Jacobson" <alex@...>
>
> Thats because we are talking about using HTTP to
> implement something that isn't the domain of HTTP.
> HTTP was designed to be a synchronous,
> client/server, connectionless protocol.  It was
> designed to let clients request/update resources
> from a server simply and easily.
>
> It was not designed for asynch, p2p, chat, or
> distributed computation.  When using HTTP for any
> of these things we are simply designing a new
> protocol on top of a set of HTTP primitives.  It
> is far from clear that the optimal design for an
> asynch protocol is to ride on top of HTTP.

I'm talking also about designing resource-centric systems. I see problems in
'consistent/correct' use of HTTP in those cases also.






-----------------------------------------------------------------------------------
Post ID:232
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-24 19:13:17
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

> Thats because we are talking about using HTTP to
> implement something that isn't the domain of HTTP.

No, Alex, that's not true.  HTTP was designed to support *all* the
things you mentioned below.  Why?  Because it defines a very general
application model that all of them can be mapped onto.  You just have to
model the application properly to make it fit the REST application model.
Granted, some applications will fit better than others, and some will
have too much trouble fitting at all, but my rule of thumb on this is
straightforward; if you're doing it now with TCP, you can do it with
HTTP.  It has served me well.

> HTTP was designed to be a synchronous,
> client/server, connectionless protocol.

Correction.  It was designed to be a stateless, request/response
protocol.  It is not necessarily synchronous, nor is it "client/server"
in the traditional sense of the term where each actor plays a fix
role as either client or server, but not both.  HTTP permits actors
playing both roles.

>  It was
> designed to let clients request/update resources
> from a server simply and easily.

More or less, yes.  Now name an app that can't be modelled as a set
of resources which are manipulated with the HTTP method set.

> It was not designed for asynch, p2p, chat, or
> distributed computation.

All of those can be modelled the way I described.  I use it for chat
(and sometimes p2p) on a daily basis.  See http://www.snapchannels.net

> > Something that would help me in the future is to model a large
> > information-centric applications (including security and events) and create
> > a direct mapping into URIs and HTTP. If anybody has any thoughts or
> > experience with this, give me a shout. (The kind of thing I'm thinking about
> > is like an 'object oriented web' but 'OO' isn't appropriate. Components and
> > interfaces are closer. Entity-relationship from rdbms and OMT/UML notation
> > is closer still.)
> 
> I tried to open this discussion earlier, but got
> no response.   I asked for a REST consisten way of
> implementing terrorist_or_not.com (a made up
> application).
> 
> The idea is that security checkpoints send front
> and side views of individuals to some server and
> the server sends back information about whether
> the person looks like a known terrorist in the
> database.
> 
> We can add the complexity that processing the
> request may take long enough for the response to
> arrive back asynchronously (but sometimes the
> server can decide quickly).
> 
> I think the implementation is straightforward
> using MIME-RPC (because it can get much closer to
> application level semantics).  The REST
> implementation is much less obvious (at least to
> me).

This would be pretty easy.  POST the picture to /terrorists,
which would add the picture to a database, and the response to the
POST could include a text/plain message saying "Terrorist!!" or
"Not a terrorist".  The response could also be a 201 response
(indicating that a resource was created), which returned a URI
that identified that particular picture in the database.  So an
HTML response could say;

...
<a href="that-uri">This person</a> is not a terrorist.
...

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:233
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-24 19:18:10
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

> I tried to open this discussion earlier, but got
> no response.   I asked for a REST consisten way of
> implementing terrorist_or_not.com (a made up
> application).
>
> The idea is that security checkpoints send front
> and side views of individuals to some server and
> the server sends back information about whether
> the person looks like a known terrorist in the
> database.
>
> We can add the complexity that processing the
> request may take long enough for the response to
> arrive back asynchronously (but sometimes the
> server can decide quickly).
>
> I think the implementation is straightforward
> using MIME-RPC (because it can get much closer to
> application level semantics).  The REST
> implementation is much less obvious (at least to
> me).

My view is that HTTP is centered on read/write and it looks like you want
'find'. I suppose you can do a 'find' as a parameterized 'read' - only your
parameters are image bits, not text. That makes it kind of hard to use GET
to do the read.
One way to do it is:

(add a suspect) ==>
POST http://www.terrorist_or_fed.com/suspects/ HTTP/1.1
Content-Type: mulitpart/related

--- image 1 ---

--- image 2 ---

<==
202 Accepted
Location: http://www.terrorist_or_fed.com/suspects/12345/

(get status of suspect) ==>
GET http://www.terrorist_or_fed.com/suspects/12345/ HTTP/1.1
Accept: text/xml

<==
200 Success
Content-Type: text/xml

<suspect>
 <status>verified</status>
 <category>terrorist</category>
</suspect>










-----------------------------------------------------------------------------------
Post ID:234
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-24 19:57:24
Subject:Re: [rest-discuss] Reliable HTTP
Message:

On Wed, 23 Jan 2002, S. Mike Dierken wrote:
> Just this part, is worth its weight in gold - all web app developers should
> burn this into their brains:
>
> "One way to make sure that your data gets through is to try and try again
> until you get a proper acknowledgement. If the action you were completing is
> "idempotent" then by definition it is safe to try again and again until it
> succeeds. The HTTP GET, PUT and DELETE methods are idempotent. If you think
> about them as if they were file system commands it should be clear why. It
> never hurts to read a file over and over again. It also does not hurt to
> write a file over and over again as long as you are writing the same data.
> And deleting a file repeatedly will at most give you an error message.

Developers should be very careful here.   All of
these methods are time dependent and there is no
guarantee that multiple idempotent requests won't
interfere with one another.  Order matters.

Suppose you decide to increment a value by 1 and
then by 100.  Now suppose you GET the value 25.
You then PUT the value 26, but it fails so you
keep trying.  While this is happening you GET the
value 25 again, and PUT the value 125.  At the end
of this process the resource value will be either
26 or 125, but the correct value would have been
126.

Order matters.  Idempotency doesn't help you much.

Paul's RPOST proposal has a similar problem.
There is no way for the client to guarantee that
RPOSTS will actually get posted in the correct
order.

Even if the server is issuing message-ids and only
processes RPOSTS in order of message-ids:
a. Nothing in the spec says that clients have to
use message-id's in the order in which they were
issued.
b. It is impossible to guarantee that the client
uses all message-Ids so the server has no way to
guarantee in-orderness.

It is really hard to get all this right without
implementing a lot of layers of transactions.

I tried to document this for mime-rpc (see
http://www.mime-rpc.com/serviceSpec.html).

The general points are:
1. clients should issue their own message-ids.  If
they don't want to get stepped on, they should
make them sufficiently unique (and secret).

2. reliable messaging looks like repeat requests

3. you may want to support a seriality protocol in
which clients send a cardinality header (I haven't
decided if this should really be an ordinality
header, leaving the cardinality header for the
transaction protocols).

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:235
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-24 20:42:54
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> > If you're going to do that, you at least need a gateway that can
> > terminate the HTTP chain so that end-to-end behaviour is guaranteed
> > (i.e. move the "end" in 8-).  Just recognize that you're doing this,
> > and don't try to pretend that you're doing HTTP behind the gateway
> > or that will just cause more trouble.
> >
> 
> If I wanted to model the resource system as an addressable collection of
> messages, what would the HTTP requests and responses look like? Especially
> if those messages were literally HTTP request and response formats?

But they wouldn't be, past a certain point.  That point is the gateway.

> Like
> blindly logging all web server activity and having an analysis program
> consume those from disk via HTTP.

Erm, I thought you were doing this because you've only got on way comms
with your resource?

Sure, you could log all messages by doing that, but in that case you're
not tunneling because the message are truly opaque.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:236
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-24 20:46:55
Subject:Re: [rest-discuss] Indicating Notifications in HTTP
Message:

> > > IMO, the opacity axiom doesn't mean that URI can't have semantics in a
> > > particular application domain,
> >
> > It means just that.  As soon as you assign any meaning to a URI, then
> > only those privy to that meaning are in on your little secrets (like
> > appending "/subs" means "subscribers to the URI before /subs").
> > Interoperability means sacrificing private convention for public
> > specification.  So you make the URI-to-URI relationship explicit with
> > a statement, such as is done with an HTTP header or an RDF statement,
> > etc..
> >
> That statement (the name and location of the information) is still a little
> secret that only those in the know.
> However, it may be better to move that out of the URI, and also do something
> to ensure backward compatibility - like defining these as 'advisory' and
> optional. These turns the http response into a multi-link (or something -
> Paul, help me out here) with named references to interesting sub-properities
> of the resource. If those sub-properties are addressable, they are also
> probably subscribable. So a DAV Properties: specified URI should be
> listenable for just property (not content) changes.

Ok.

> If an HTTP WATCH method were to be used, would OPTIONS return that fact?
> Does it operate per resource? (ignoring the extra requests to figure stuff
> out)

OPTIONS works on the whole req/resp chain, including the resource
(except when "*" is used).  Yah, it should have the Allow header
in the response which would tell you what methods were supported.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:237
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-24 21:00:48
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Thu, 24 Jan 2002, Mark Baker wrote:
> No, Alex, that's not true.  HTTP was designed to support *all* the
> things you mentioned below.  Why?  Because it defines a very general
> application model that all of them can be mapped onto.  You just have to
> model the application properly to make it fit the REST application model.
> Granted, some applications will fit better than others, and some will
> have too much trouble fitting at all, but my rule of thumb on this is
> straightforward; if you're doing it now with TCP, you can do it with
> HTTP.  It has served me well.

I think everything is looking like a nail to you.
I don't deny that HTTP is a wonderful thing.
However, I could quite reasonably make the claim
that you can do everything you can do in HTTP
using SMTP.

More generally, I think there are a large class of
applications in which you are using HTTP simply to
get access to TCP and that it would actually be
more efficient just to use TCP directly.

To put it another way, you can send TPC over
carrier pigeon.  That doesn't mean that you always
want to do so.

The real reason to use HTTP is the amount of
existing plumbing to support it.

If your application isn't really going to be able
to take advantage of that plumbing it isn't so
useful.

For example, if I wanted to implement a Presence
server for clients that may be behind firewalls.
I could do it via HTTP  by having the clients
ping every n seconds, but that would be an
inefficient use of network resources.

A better solution might be to rely on TCP
directly and have clients simply hold open a TCP
connections.  The server can then determine
presence simply by checking whether it still has a
connection to the client. (yes, I'm leaving out
lots of details, but you get my point)

> > HTTP was designed to be a synchronous,
> > client/server, connectionless protocol.
>
> Correction.  It was designed to be a stateless, request/response
> protocol.  It is not necessarily synchronous, nor is it "client/server"
> in the traditional sense of the term where each actor plays a fix
> role as either client or server, but not both.  HTTP permits actors
> playing both roles.

No.  HTTP only has a client making a request and a
server responding to the request.  The server
can't send a request unless it plays the role of
client.

Even in traditional client/server (long
connections), there was nothing that prevented
this from happening.  Its just that the protocol
itself is defined in terms of clients making
requests of servers.

> >  It was
> > designed to let clients request/update resources
> > from a server simply and easily.
>
> More or less, yes.  Now name an app that can't be modelled as a set
> of resources which are manipulated with the HTTP method set.

Ok, name an app that can't be modelled as a set of
email addresses.

The issue is whether the app SHOULD be modelled as
a set of HTTP resources or a email addresses or
whatever.

See the presence example above.

Think of it this way.   Just because every
computer language is turing complete, that
doesn't mean every language is equivalently useful
for implementing your application.

Not everything is the nail to your HTTP hammer.

> > It was not designed for asynch, p2p, chat, or
> > distributed computation.
>
> All of those can be modelled the way I described.  I use it for chat
> (and sometimes p2p) on a daily basis.  See http://www.snapchannels.net

Congratulations.  Looks cool.  Doesn't mean that
was the best way to go.  For example, would you
use HTTP for an IM client (if you needed to
support large numbers of them)?  Having millions
of clients polling for messages seems like a bad
idea.

> This would be pretty easy.  POST the picture to /terrorists,
> which would add the picture to a database, and the response to the
> POST could include a text/plain message saying "Terrorist!!" or
> "Not a terrorist".  The response could also be a 201 response
> (indicating that a resource was created), which returned a URI
> that identified that particular picture in the database.  So an
> HTML response could say;
> ...
> <a href="that-uri">This person</a> is not a terrorist.
> ...

I'm not sure you read the problem correctly.

The client is simply making a query to the server
and getting a yes/no response.

In other words, it is making an idempotent
request.  Accoding to REST, the client should use
GET for such a a request, but I don't know how you
send two pictures using GET.  So I'm not sure you
can use REST.

There is no requirement that the server maintain a
copy of the pictures so you would not need a 201.

The server may take a long time to respond to
the query so it may issue a 202 Accepted.  But,
if it does, then we also need a convention for
delivery of the reply.

I think MIME-RPC provides these conventions and
allows this application to be deployed over
SMTP almost exactly as it would be deployed over
HTTP.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:238
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-24 21:14:38
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Thu, 24 Jan 2002, S. Mike Dierken wrote:
> My view is that HTTP is centered on read/write and it looks like you want
> 'find'. I suppose you can do a 'find' as a parameterized 'read' - only your
> parameters are image bits, not text. That makes it kind of hard to use GET
> to do the read.
> [...post images then  get results...]

Hmm.  This is a start, but:
* If HTTP is centered on read/write and I want
find, then perhaps I want a different protocol.
But, then why does the URI spec have a query
string?  It feels like we are now hacking around
either the inadequacies of HTTP or the
inadequacies of REST.

* I think you would PUT rather than POST the
images (you are not appending to anything)

* either PUT or POST is bad, because the server
now needs to maintain a copy of the results for
some indeterminate period of time -- which is
ugly.

* if processing the request takes a while, the
client has to keep polling the GET url until it
gets a response -- which is also ugly.

The best protcol for this may not be HTTP, but to
the extent we want to use it, I think the best
design is for the Client to POST the two images
as multpart/mixed with reply-to-url/message-id
headers.  And then for the Server to reply
back with the answer or reply 202 and eventually
send result to the callback url.

That being said, if we want to expose the
application to web browsers, the correct answer is
for the server to handle multipart/form-data, and
either respond with the answer, or response with a
form asking where the answer should be delivered.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:239
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-24 21:16:58
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

----- Original Message -----
From: "S. Alexander Jacobson" <alex@...>

>
> The real reason to use HTTP is the amount of
> existing plumbing to support it.
>
> If your application isn't really going to be able
> to take advantage of that plumbing it isn't so
> useful.
>
Ask not what the Web can do for you, rather ask what you can do for the Web.







-----------------------------------------------------------------------------------
Post ID:240
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-24 21:15:49
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:

> More generally, I think there are a large class of
> applications in which you are using HTTP simply to
> get access to TCP and that it would actually be
> more efficient just to use TCP directly.

Ah, glasshoppah, I see where you are failing.  You have not yet passed through
the No Barrier.  You have not yet achieved true Web Zen.  The satori, the total
consciousness of Webby Sabi has yet to visit the tempestuous storm crashing
over your lobes.  You must do the following:  sit on a serene hillside far from
the troubles of man, fast, and repeat the following until you achieve
enlightenment:  "HTTP is not a protocol, it is a universal application.  HTTP
is not a protocol, it is a universal application.  HTTP is not a protocol...."

;-)

jb

PS - Deja vu, Alex.  You're cribbing *my* old position.  I was woefully
wrong....









-----------------------------------------------------------------------------------
Post ID:241
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-24 21:42:23
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

Alex, no offense dude, but you don't get REST yet.  It would really
help things a lot in this discussion if you stopped pulling a Dave
Winer by thinking you understand it, and dismissing it so quickly
as unsuitable.

> I think everything is looking like a nail to you.

You're damned right.  Putting something on the Web requires being able
to see things as a nail.  Some things won't ever be nails, but with
REST, the vast majority of things can be seen as nails.

> I don't deny that HTTP is a wonderful thing.
> However, I could quite reasonably make the claim
> that you can do everything you can do in HTTP
> using SMTP.

Nope.  How would you retrieve information with SMTP, without additional
a priori agreement?

> For example, if I wanted to implement a Presence
> server for clients that may be behind firewalls.
> I could do it via HTTP  by having the clients
> ping every n seconds, but that would be an
> inefficient use of network resources.
> 
> A better solution might be to rely on TCP
> directly and have clients simply hold open a TCP
> connections.  The server can then determine
> presence simply by checking whether it still has a
> connection to the client. (yes, I'm leaving out
> lots of details, but you get my point)

HTTP can use persistent connections on a GET to receive information.
This is safe if the information that's received isn't another protocol
(like an encapsulated message/http).

But you first have to model your presence app as a set of resources.
e.g. each user gets a URI, a persistent GET to that URI returns a
stream of presence messages as their presence status changes, etc..

> Even in traditional client/server (long
> connections), there was nothing that prevented
> this from happening.  Its just that the protocol
> itself is defined in terms of clients making
> requests of servers.

Name a protocol that doesn't work this way.

> > >  It was
> > > designed to let clients request/update resources
> > > from a server simply and easily.
> >
> > More or less, yes.  Now name an app that can't be modelled as a set
> > of resources which are manipulated with the HTTP method set.
> 
> Ok, name an app that can't be modelled as a set of
> email addresses.

The Web.

> The issue is whether the app SHOULD be modelled as
> a set of HTTP resources or a email addresses or
> whatever.

In part, that's true.  But often (unless you've been doing this as long
as I have 8-), you won't know until you try.  You're not even trying.

> > All of those can be modelled the way I described.  I use it for chat
> > (and sometimes p2p) on a daily basis.  See http://www.snapchannels.net
> 
> Congratulations.  Looks cool.  Doesn't mean that
> was the best way to go.  For example, would you
> use HTTP for an IM client (if you needed to
> support large numbers of them)?  Having millions
> of clients polling for messages seems like a bad
> idea.

If I could offload to a proxy farm, sure.  Proxies are an integral part
of REST for this and other reasons.

But as I said, if you can use TCP, you can probably use HTTP.  Can that
IM app use TCP?

> I'm not sure you read the problem correctly.
> 
> The client is simply making a query to the server
> and getting a yes/no response.
> 
> In other words, it is making an idempotent
> request.

You mean that if a picture of a terrorist was submitted, that nobody
would want to store it?  Seriously?

If there is a chance that it might not be idempotent, then you have to
use POST.

But as Paul and I discussed a while ago, HTTP is missing a method to
support idempotent operations on content, like transcoding or whatever.
This is not a failing in REST, it is a missing feature of HTTP, but it
could easily be added.

>  Accoding to REST, the client should use
> GET for such a a request, but I don't know how you
> send two pictures using GET.  So I'm not sure you
> can use REST.

Well, no, it's according to TimBL, not REST.  I have some issues with
Tim's views of this too;

http://lists.w3.org/Archives/Public/www-tag/2002Jan/0075.html

That is, other idempotent requests are fine (OPTIONS is one), so long as
it doesn't act on the information space formed by GET, and that GET
remains the only method used for URI resolution (i.e. when you click on
a URI, it can only ever mean GET).  A new idempotent data submission
method would be fine.

> The server may take a long time to respond to
> the query so it may issue a 202 Accepted.  But,
> if it does, then we also need a convention for
> delivery of the reply.

One convention is described in RFC 2616.  Put a URI in the body of
the 202 response that represents the completed request.

> I think MIME-RPC provides these conventions and
> allows this application to be deployed over
> SMTP almost exactly as it would be deployed over
> HTTP.

That's because you're building a new protocol and tunneling it over
SMTP and HTTP.  i.e. you're disregarding the view of the world that
each of these other application protocols attempts to enforce.
You've also got a hammer it seems; one that likes to flatten
everything to ensure a consistent view of the world.  8-)

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:242
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-24 22:56:30
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:
>
> ...
> 
> Much as it would not be surprising if we disagreed
> about the best design for an email system using
> C++ and the STL, it should not be at all
> surprising that we disgaree when using HTTP.

There is always a gap between one model and another. The problem is
we've learned to think about it one way and now we must learn to think
about it another. If you taught someone REST and you taught them sockets
and asked them to invent an email system I think they would find it
easier to do it using HTTP and REST.

>...
> To put it another way, they are designing
> applications not protocols.

Big mistake. Maintaining applications is extremely expensive. A purchase
order application is no easier to maintain in the long run than an email
application. How many companies have their own email applications?
Rather they buy interoperable products implementing the same protocol.

> The idea is that security checkpoints send front
> and side views of individuals to some server and
> the server sends back information about whether
> the person looks like a known terrorist in the
> database.
> 
> We can add the complexity that processing the
> request may take long enough for the response to
> arrive back asynchronously (but sometimes the
> server can decide quickly).

I don't now if anyone answered you yet. Here's how I would go about
thinking about it.

You want it to be asyncronous. That means that the server must have
"persistent state" that survives longer than a single connection and yet
is meaningful to the client. That suggests to me that you are creating a
new reasource (if only a temporary one). So you do a POST of the
picture. mime/multipart could be used if there is a associated XML
metadatda. The server returns a Location: for the new resource.

If you want a web interface then you can use a POST form.

The new resource represents the computation. The client can do a GET on
it any time to see how the computation is progressing. When it is done
the computation result could appear there. In the meantime, status
reports are there so that the client can check back whenever it wants.

If you want a web interface, consider a META http-equiv=refresh thing.

The client may also want an asyncronous notification of when this status
resource changes. In the interests of layering and distribution of
processing, I would think of this as a completely unrelated part of the
system. Some clients could poll. Others could ask for a notification.
Maybe the resource for status and for the final result should be
separate...I can't see big tradeoffs one way or the other off the top of
my head.

If there was a web interface, a button on the HTML could give the user
the asych notification option.

Conventions for asyncronous notification are here:

 * http://www.prescod.net/HTTP_event_conventions.html

If you had some kind of mod_asych then adding asynch support would
require no extra effort. And you could easily support either or both of
email and HTTP-based notification.

Anyhow, that's how I would model it. Notice how I try to think about the
web interface at each step. It allows me to envision the process in
concrete terms and ensure that I am always creating resources that are
useful to the client. Using content-negotiation I can really create
these HTML forms for testing purposes even if the main goal of the
service is for automated users.

As these pictures are large, you might want to consider allowing users
to submit some kind of a hash to check if the picture is already on the
site. That's another benefit of modelling the system so that results are
resources. You could point someone at an existing result in your
"cache". REST rewards you for making things into resources as functional
programming rewards you for making your functions small and reusable.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:243
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-24 23:53:59
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

Mark Baker wrote:
> 
>...
> 
> But as I said, if you can use TCP, you can probably use HTTP.  

If this turns out to be literally true, so that one day there is only
one TCP-based protocol then TCP won't be very useful. It's like an
operating system that can only be used for one application. Why not just
code the application to the bare metal if you're not amortizing any
costs.

On the other hand, I suspect that people will always resist
resource-modelling their application so TCP will be a rich home for RPC
applications forever.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:244
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 00:04:09
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> Hmm.  This is a start, but:
> * If HTTP is centered on read/write and I want
> find, then perhaps I want a different protocol.

Yeah, that's what I heard Google did. ;)

> But, then why does the URI spec have a query
> string?  It feels like we are now hacking around
> either the inadequacies of HTTP or the
> inadequacies of REST.

PUT/POST/DELETE/GET are primitives. You build things on top of them.
Like CPU instructions. Modern CPUs don't have an evaluate polynomial
instruction. It was found that it was really expensive to have
instructions that catered only to one kind of problem or another. RPCs
are like that.

> * I think you would PUT rather than POST the
> images (you are not appending to anything)

I believe PUT is only good if the client already has an address to PUT
the thing. If not, then yes you are creating something and the new thing
is considered a "sub-resource" (appendage) of the old thing.

> * either PUT or POST is bad, because the server
> now needs to maintain a copy of the results for
> some indeterminate period of time -- which is
> ugly.

PUT or POST do not require this, really, but maintaing the data is good
for caching and it is more polite in my opinion to send the client a URL
than the data. What if it is a handheld computer? If they want all of
the data they should be able to get it but if they want only a link then
the server should be willing to serve it for a while.

> * if processing the request takes a while, the
> client has to keep polling the GET url until it
> gets a response -- which is also ugly.

If it wants to poll it can do so. Otherwise it can ask for a
notification. 

>...
> That being said, if we want to expose the
> application to web browsers, the correct answer is
> for the server to handle multipart/form-data, and
> either respond with the answer, or response with a
> form asking where the answer should be delivered.

More or less my design also. And inventing a new protocol to do this
would have only made your life harder. Working with sockets. No caching.
Can't use PHP, Zope or JSP. Can't use web browsers. Would require a
"client library" for each language. Etc. Etc.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:245
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 00:14:19
Subject:Re: [rest-discuss] Reliable HTTP
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> Developers should be very careful here.   All of
> these methods are time dependent and there is no
> guarantee that multiple idempotent requests won't
> interfere with one another.  Order matters.
> 
> Suppose you decide to increment a value by 1 and
> then by 100.  Now suppose you GET the value 25.
> You then PUT the value 26, but it fails so you
> keep trying.  While this is happening you GET the
> value 25 again, and PUT the value 125. 

But the "failure" and "keep trying" parts have nothing to do with this
problem. That's why I think it is orthogonal. Between your *original*
GET and your PUT someone could have twiddled the data.

Also, in this case it would probably be better to let the server merge
the data using POST. Of course the lost update problem is unavaoidable
when only the client can merge the data (i.e. with human authors).

>...
> Even if the server is issuing message-ids and only
> processes RPOSTS in order of message-ids:
> a. Nothing in the spec says that clients have to
> use message-id's in the order in which they were
> issued.

Are we talking about multiple clients or a single client? If a single
client then the single client can sychronize its own messages! Why
should the server worry about that?

If we're talking about multiple clients, then the service should be
implemented so that order doesn't matter. If syncronization is important
then I guess we need some kind of "lock" resources to keep clients in
order. I can't think of an application of this off the top of my head. 

>...
> 1. clients should issue their own message-ids.  If
> they don't want to get stepped on, they should
> make them sufficiently unique (and secret).

I'm not happy trusting the clients not to step on each other.

> 2. reliable messaging looks like repeat requests

To the server application it should not. The reliable messaging
infrastructure (i.e. part of the web application framework) should merge
them.

> 3. you may want to support a seriality protocol in
> which clients send a cardinality header (I haven't
> decided if this should really be an ordinality
> header, leaving the cardinality header for the
> transaction protocols).

I don't understand why the server is responsible for the client keeping
its ducks in a row and I don't think that the clients should trust the
server to verify the semantics of an "optional" header. Many servers
could just let this pass quietly.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:246
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 00:16:45
Subject:Re: [rest-discuss] Reliable HTTP
Message:

Mark Baker wrote:
> 
> > I agree that lost update is a problem. I don't see how it relates to
> > "PUT also has side effects." Overwriting someone else's data is not a
> > side effect in the traditional sense!
> >
> > Do you think that the issue is sufficiently related to reliability to
> > mention it in that essay?
> 
> Well, it's just that you said that you can keep invoking PUT over and
> over, which is true, but you have to be aware that you may be stomping
> over somebody else's changes.  Yes, I think this relates to
> reliability quite closely.

Let me ask this the way I asked Alex.

Is there anything about this problem that is *cause* by the repeat-try
reliability solution that would not occur in a system that had
inherently reliable once-only message delivery? Even in a perfect world
where messages are delivered once and only once you can get the phantom
write problem. PUTting over and over again may increase the chances just
because of time passing but the problem is essentially the same.

If I understand that correctly then I'll put in a footnote about that.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:247
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 00:25:47
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:


Paul Prescod wrote:

> If this turns out to be literally true, so that one day there is only
> one TCP-based protocol then TCP won't be very useful. It's like an
> operating system that can only be used for one application. Why not just
> code the application to the bare metal if you're not amortizing any
> costs.

Answers:  generality, simplicity, loose coupling.  Think of how the
filesystem namespace and the generic file io interface is (a) both a
universal metaphor --- devices, versioning systems, servers, the process
abstraction, virtual memory, network streams, etc. can and are all presented
as "files" in the filesystem in various flavors of UNIX.  (Many UNIX purists
think that the introduction of a new namespace and API with Berkeley sockets
was the beginning of the end;  Plan 9 stands as a wonderful existance proof
of the benefits of keeping everything in one namespace with a generic
interface, sort of UNIX "as it should have evolved.")

> On the other hand, I suspect that people will always resist
> resource-modelling their application so TCP will be a rich home for RPC
> applications forever.

Quite possibly.  It's unfortunate how much complexity people will wantonly
introduce, for no good reason at all.

:-(

jb








-----------------------------------------------------------------------------------
Post ID:248
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 00:33:56
Subject:Question about the spec
Message:

Paul,

Cleared off some time to take another look at your event spec thisevening, but
looking at the list it seems that there's been a lot of discussion and feedback
that would impact it;  you've probably got more of a clear idea how the
discussion has molded it.  Here's a suggestion:  how about we put it up on the
REST Wiki?  I'll be happy to transfer it over, format it, etc.  Then, assuming
everybody doesn't go morph the hell out of it, we can manage evolution of the
document in place.

Having this many interesting parties collaborate on a document online may be a
bit of an exercise in discipline, but I think it's manageable.  You?

jb








-----------------------------------------------------------------------------------
Post ID:249
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 00:37:01
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:


Jeff Bone wrote:

> Paul Prescod wrote:
>
> > If this turns out to be literally true, so that one day there is only
> > one TCP-based protocol then TCP won't be very useful. It's like an
> > operating system that can only be used for one application. Why not just
> > code the application to the bare metal if you're not amortizing any
> > costs.
>
> Answers:  generality, simplicity, loose coupling.  Think of how the
> filesystem namespace and the generic file io interface is (a) both a

Missed the (b) / second part:  it also serves as a generic integration framework
for plugging arbitrary components together.  Much like the Web.

:-)

jb








-----------------------------------------------------------------------------------
Post ID:250
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 00:52:19
Subject:Re: Question about the spec
Message:

Can we encourage people to add comments without changing the text until
we've got some kind of consensus?

Actually, I didn't go through the comments in detail yet because I
thought you had write perms. The only ones that I thought through were:

> Some comments;
> 
> "X-Event-Subscription".  How about just "Subscriptions", since
> that better describes it's role; a container for subscriptions.

 * Sounds good to me.


> If the Location header on a subscription response is a MAY, how does
> one unsubscribe?  Should also mention use of 200/201/204 response
> codes on a POST action here too.

 * Location: should be at least a SHOULD if not a MUST

 * Mike D said an Unsub-URI: might be a good hack for servers that find
resource modelling difficult
 * Mike D had about a hundred other suggestions that I haven't thought
through yet.

http://groups.yahoo.com/group/rest-discuss/message/198
http://groups.yahoo.com/group/rest-discuss/message/211

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:251
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 00:55:45
Subject:Re: Question about the spec
Message:

I'll transfer it over after dinner and make these changes in the process.
We can't prevent people from mucking things up directly --- that openness
is a part of the Wiki Way ;-) --- but we can ask them nicely to on the
document.  Also, our wiki has built-in versioning, so we can always
trivially recover / roll back if somebody gets ugly.

:-)

jb


Paul Prescod wrote:

> Can we encourage people to add comments without changing the text until
> we've got some kind of consensus?
>
> Actually, I didn't go through the comments in detail yet because I
> thought you had write perms. The only ones that I thought through were:
>
> > Some comments;
> >
> > "X-Event-Subscription".  How about just "Subscriptions", since
> > that better describes it's role; a container for subscriptions.
>
>  * Sounds good to me.
>
> > If the Location header on a subscription response is a MAY, how does
> > one unsubscribe?  Should also mention use of 200/201/204 response
> > codes on a POST action here too.
>
>  * Location: should be at least a SHOULD if not a MUST
>
>  * Mike D said an Unsub-URI: might be a good hack for servers that find
> resource modelling difficult
>  * Mike D had about a hundred other suggestions that I haven't thought
> through yet.
>
> http://groups.yahoo.com/group/rest-discuss/message/198
> http://groups.yahoo.com/group/rest-discuss/message/211
>
>  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:252
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-25 02:00:07
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

> Mark Baker wrote:
> > 
> >...
> > 
> > But as I said, if you can use TCP, you can probably use HTTP.  
> 
> If this turns out to be literally true, so that one day there is only
> one TCP-based protocol then TCP won't be very useful. It's like an
> operating system that can only be used for one application. Why not just
> code the application to the bare metal if you're not amortizing any
> costs.

You got it.  Yes, it may allow for some interesting things to occur,
such as replacing IP and DNS.

> On the other hand, I suspect that people will always resist
> resource-modelling their application so TCP will be a rich home for RPC
> applications forever.

Yah, just like all those renegade SNA and DECNET users. 8-)

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:253
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-25 02:02:20
Subject:Re: [rest-discuss] Reliable HTTP
Message:

> Let me ask this the way I asked Alex.
> 
> Is there anything about this problem that is *cause* by the repeat-try
> reliability solution that would not occur in a system that had
> inherently reliable once-only message delivery? Even in a perfect world
> where messages are delivered once and only once you can get the phantom
> write problem. PUTting over and over again may increase the chances just
> because of time passing but the problem is essentially the same.
> 
> If I understand that correctly then I'll put in a footnote about that.

Ah, well phrased.  Yes, there's nothing special about the lost update
problem with HTTP.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:254
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 02:02:57
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

Jeff Bone wrote:
> 
>....
> 
> Missed the (b) / second part:  it also serves as a generic integration framework
> for plugging arbitrary components together.  Much like the Web.

I don't follow. If the interface all applications use for streamed
processing is "httplib.HTTPConnection()" then why does anyone care
whether TCP is underneath or not?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:255
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 03:46:55
Subject:Paul's HttpEvents Spec
Message:

(Btw, I decided to just call it HttpEvents for the time being, as that's a
valid Wikiword.  Hope this doesn't offend, it's purely a pragmatic decision.)

I've copied Paul's HttpEvents spec (formerly YEHEA ;-) over to the REST
Wiki.  The purpose of putting it there is to have a collaborative medium for
*writing the document.*  It shouldn't take the place of *discussing those
changes* here on the list.  I haven't made any substantive changes yet other
than the ones suggested by various folks and collected by Paul, mostly just
formatted for the Wiki.

    http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents

Fyi,

jb









-----------------------------------------------------------------------------------
Post ID:256
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 04:07:37
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

Paul Prescod wrote:

> > Missed the (b) / second part:  it also serves as a generic integration framework
> > for plugging arbitrary components together.  Much like the Web.
>
> I don't follow. If the interface all applications use for streamed
> processing is "httplib.HTTPConnection()" then why does anyone care
> whether TCP is underneath or not?

Nonononono...  sorry, let me be more clear.  People *don't* care if TCP is underneath,
that's not the issue.  I'm pointing out that HTTP etc. is a framework which allows
arbitrary applications supporting a generic interface to be plugged together in
arbitrary ways to achieve new functionality --- just like the filesystem namespace and
file / stream- IO on UNIX.  Consider the following:

ls /foo > /tmp/foo; wc -l /tmp/foo

What have I done there?  I've *written a program* that counts the files in a
particular directory, and I've done it by *composing* (plugging together) two
different components that don't know anything about each other.  How am I able to do
that?  Well, all resources in "true" UNIX (okay, so the paradigm didn't get pushed far
enough until Plan 9, but anyway) are represented in the filesystem namespace and have
a common generic interface:  open, read, etc.  They all look like named bytestreams.
In a sense, the UNIX abstractions support a crude kind of compositional algebra of
operations for stream processing.  And this is a very powerful integration framework.

The Web is similar, it's just harder to see because we don't have good dataflow /
stream scripting tools and conventions.  GET, PUT, DELETE, etc. are very analogous to
the file IO system calls in UNIX.  The fact that most people access the Web through
more procedural interfaces (e.g. "httplib.HTTPConnection()") often obscures this fact,
but it's a fact nonetheless.  Application domains which are appropriately modeled as
resources with appropriate semantics for the standard methods can therefore use each
other in arbitrary and ad-hoc ways that the original developers didn't necessarily
anticipate.

The motivation for re-modeling various application domains as resources on the Web is
much the same motivation for pushing all kinds of abstractions (such as the process
table, network connections, etc.) into the filesystem in various UNIX variants:  it
lowers the cost of reusing / integrating those components.  Sure, you can model your
chat application as an entirely new protocol, but then it makes it harder to integrate
with other things.  Having HTTP as *the* one generic model for doing distributed
computation *increases* the overall value of the Web, because it increases
exponentially the number of connections available between network-available
information and services, while at the same time vastly simplifying the process of
plugging those things together.

That's all I was pointing out.

jb










-----------------------------------------------------------------------------------
Post ID:257
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 04:16:15
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:


Jeff Bone wrote:

> Having HTTP as *the* one generic model for doing distributed
> computation *increases* the overall value of the Web,

Sorry, Internet.  I.e., to the extent that the Web and the Internet become
indistinguishable through the use of a global modeling paradigm and generic interfaces, it
exponentially magnifies the value of the thing as a whole.  Separate protocols increase
balkanization and dimish total potential value.  Metcalfe's, etc.

jb








-----------------------------------------------------------------------------------
Post ID:258
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-25 04:42:28
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

> Sorry, Internet.  I.e., to the extent that the Web and the Internet become
> indistinguishable through the use of a global modeling paradigm and generic interfaces, it
> exponentially magnifies the value of the thing as a whole.  Separate protocols increase
> balkanization and dimish total potential value.  Metcalfe's, etc.

Yup, absolutely.  10 years from now, nothing but Web.  That's when
the fun begins.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:259
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 05:46:51
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Thu, 24 Jan 2002, Mark Baker wrote:
> Alex, no offense dude, but you don't get REST yet.  It would really
> help things a lot in this discussion if you stopped pulling a Dave
> Winer by thinking you understand it, and dismissing it so quickly
> as unsuitable.

Mark, please don't accuse me of pulling a Dave
Winer :-)  You would agree that it is possible to
understand REST without agreeing that it is the
solution to all problems.

Unless REST is a religion, I think it comes down
to this:
1. Is HTTP really the best model for your app.
2. If not, is it worth implementing in HTTP anyway
to gain the advantages of reusability,
interoperation, etc.

I think there are many cases where it is not.
I think many of your arguments in favor of HTTP
are not in favor of a real HTTP but rather some
hypothetical HTTP.

That being said, I've learned a lot in this
discussion and will strive to implement more
consistently with HTTP in the future.

> You're damned right.  Putting something on the Web requires being able
> to see things as a nail.  Some things won't ever be nails, but with
> REST, the vast majority of things can be seen as nails.

Yes.  I get this and agree.

> > I don't deny that HTTP is a wonderful thing.
> > However, I could quite reasonably make the claim
> > that you can do everything you can do in HTTP
> > using SMTP.
>
> Nope.  How would you retrieve information with SMTP, without additional
> a priori agreement?

How do autoreplies work?  Send an empty message to
an email address and get an autoreply.  There are
lots of more sophisticated versions of this.

Btw, implementing asynch with HTTP also requires
prior agreement.

> HTTP can use persistent connections on a GET to receive information.
> This is safe if the information that's received isn't another protocol
> (like an encapsulated message/http).

Talk about HTTP abuse!  Given that most real HTTP
clients/servers will time out a connection, I
think this one is impractical.

Note, the reason for closing connections is that
holding open a thread or child process(!!) for
each client is expensive.

In theory one could design a special purpose web
server that does polling, but that is not the same
one you would use for CGI or servlets.

Once you have to write your own HTTPd for the
application, re-using HTTP seems much less
exciting.

> But you first have to model your presence app as a set of resources.
> e.g. each user gets a URI, a persistent GET to that URI returns a
> stream of presence messages as their presence status changes, etc..

Again, that may be, but since you also have to
write a custom client, I don't see the bonus of
HTTP here.

A simpler approach might just be to have the
client open a socket connection with some auth
information, and to multiplex chat messages back
and forth on that socket.

You might argue that the HTTP approach is better
because it is more likely to get through the
firewall.  However, it is equally likely that the
firewall will shut down excesively long HTTP
connections.

> > Even in traditional client/server (long
> > connections), there was nothing that prevented
> > this from happening.  Its just that the protocol
> > itself is defined in terms of clients making
> > requests of servers.
>
> Name a protocol that doesn't work this way.

That is my point.  Doing P2P with HTTP also
requires "additional a priori agreement."
You seemed to be claiming otherwise.

My general point then is that once you require a
priori agreement, you might as well use protocols
for which that a priori agreement is already well
defined.

For messaging, that would be SMTP.
For news distribution, that would be NNTP
For presence, it need not be HTTP and it might
very well be IRC.

> > Ok, name an app that can't be modelled as a set of
> > email addresses.
>
> The Web.

See above, re auto-replies.

> > The issue is whether the app SHOULD be modelled as
> > a set of HTTP resources or a email addresses or
> > whatever.
>
> In part, that's true.  But often (unless you've been doing this as long
> as I have 8-), you won't know until you try.  You're not even trying.

I am trying.  But in general I am trying to use
whatever protocol people are already using for
whatever I am doing.

> > Congratulations.  Looks cool.  Doesn't mean that
> > was the best way to go.  For example, would you
> > use HTTP for an IM client (if you needed to
> > support large numbers of them)?  Having millions
> > of clients polling for messages seems like a bad
> > idea.
>
> If I could offload to a proxy farm, sure.  Proxies are an integral part
> of REST for this and other reasons.

My point is that you would rather design a
protocol that doesn't impose so much load on your
server.  I'd rather run 1 presence server on my
own protocl than 10 proxy servers using HTTP.

> But as I said, if you can use TCP, you can probably use HTTP.  Can that
> IM app use TCP?

Sure.  Client keeps a socket open.  Server watches
TCP to make sure the connection is still open.

This is hugely lighter weight than your HTTP
implementation.

> > I'm not sure you read the problem correctly.
> >
> > The client is simply making a query to the server
> > and getting a yes/no response.
> >
> > In other words, it is making an idempotent
> > request.
>
> You mean that if a picture of a terrorist was submitted, that nobody
> would want to store it?  Seriously?

The client stores it and has procedures for
delivering the message to the master terrorist
database if recognition happens.  The local
terrorist server has a local copy of the database.
(whatever).

> If there is a chance that it might not be idempotent, then you have to
> use POST.

Your talking about a different application.

> But as Paul and I discussed a while ago, HTTP is missing a method to
> support idempotent operations on content, like transcoding or whatever.
> This is not a failing in REST, it is a missing feature of HTTP, but it
> could easily be added.

But it not part of HTTP!!!
There is the theory of HTTP and the reality of the
HTTP protocol and the further reality of its
implementations.


> That is, other idempotent requests are fine (OPTIONS is one), so long as
> it doesn't act on the information space formed by GET, and that GET
> remains the only method used for URI resolution (i.e. when you click on
> a URI, it can only ever mean GET).  A new idempotent data submission
> method would be fine.

If you are using POST then you lose the benefit of
caching and therefore much of the benefit of HTTP.

But, more to the point, sending multiple pictures
to a server is NOT modeling the application as a
set of resources (whether you use GET or POST).
It is a form of RPC!

> > The server may take a long time to respond to
> > the query so it may issue a 202 Accepted.  But,
> > if it does, then we also need a convention for
> > delivery of the reply.
>
> One convention is described in RFC 2616.  Put a URI in the body of
> the 202 response that represents the completed request.

HTTP doesn't deliver.  RFC2616 is incredibly
vague on this issue.  The result is that
applications are forced into a priori
negotiations.  I am trying, in MIME-RPC to firm
it up, so that two applications written by
strangers can talk to each other.

Do you have a better idea?

> > I think MIME-RPC provides these conventions and
> > allows this application to be deployed over
> > SMTP almost exactly as it would be deployed over
> > HTTP.
>
> That's because you're building a new protocol and tunneling it over
> SMTP and HTTP.  i.e. you're disregarding the view of the world that
> each of these other application protocols attempts to enforce.
> You've also got a hammer it seems; one that likes to flatten
> everything to ensure a consistent view of the world.  8-)

MIME-RPC isn't really a new protocol.  It is just
a recognition that we are all already using MIME
and should enjoy it with the transport that makes
sense for your application.

RFC2045: When you want asynchronous messaging,
send MIME over SMTP
RFC2616: When you want to do synchronous
messaging, send MIME over HTTP.
RFC977: When you want to distribute/replicate
messages, use MIME over NNTP
RFCxxx: When you want to do p2p messaging, send
MIME over ____?

This is the Internet.  I'm just pointing it out.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax









-----------------------------------------------------------------------------------
Post ID:260
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 06:02:38
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> > > Missed the (b) / second part:  it also serves as a generic integration framework
> > > for plugging arbitrary components together.  Much like the Web.
> >
> > I don't follow. If the interface all applications use for streamed
> > processing is "httplib.HTTPConnection()" then why does anyone care
> > whether TCP is underneath or not?
> 
> Nonononono...  sorry, let me be more clear.  People *don't* care if TCP is underneath,
> that's not the issue.  .... etc. etc....

Whoa, Jeff. Are you in FoRK withdrawl? The question was whether it made
sense in the future to merge TCP and HTTP so as to get rid of the extra
overhead of TCP. As long as there are many TCP protocols, the TCP layer
is a useful common basis. When there is only one application protocol it
makes sense to optimize away the generality underneath it.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:261
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 06:10:21
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Thu, 24 Jan 2002, Paul Prescod wrote:
> There is always a gap between one model and another. The problem is
> we've learned to think about it one way and now we must learn to think
> about it another. If you taught someone REST and you taught them sockets
> and asked them to invent an email system I think they would find it
> easier to do it using HTTP and REST.

The more comparable example is if you asked them
to set up an asynchronous peer to peer
messaging system (aka email). Would they choose
HTTP or SMTP?



> > The idea is that security checkpoints send front
> > and side views of individuals to some server and
> > the server sends back information about whether
> > the person looks like a known terrorist in the
> > database.
> >
> If you want a web interface then you can use a POST form.

See my reply to MB.  This is not modeling the
application in terms of resources.  It is RPC.

Returning a URL and then asking the client to
watch the new URL seems like a lot of overhead and
waste.

> The client may also want an asyncronous notification of when this status
> resource changes. In the interests of layering and distribution of
> processing, I would think of this as a completely unrelated part of the
> system. Some clients could poll. Others could ask for a notification.
> Maybe the resource for status and for the final result should be
> separate...I can't see big tradeoffs one way or the other off the top of
> my head.

Good argument, but the polling is ugly.  A
callback system is much nicer and much ligher on
system resources!

> Conventions for asyncronous notification are here:
>
>  * http://www.prescod.net/HTTP_event_conventions.html

Ok.  So that is another new protocol.  It is not
real life HTTP.  It also seems no better than just
sending a reply-to in the first place.

> Anyhow, that's how I would model it. Notice how I try to think about the
> web interface at each step.

I am doing the same thing.  The whole point of
MIME-RPC is to model the web interface.  Which
uses MIME rather than SOAP or XML-RPC.

> As these pictures are large, you might want to consider allowing users
> to submit some kind of a hash to check if the picture is already on the
> site.

Again, the pictures are taken at the client site
so the server won't have copies.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:262
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 06:14:20
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Thu, 24 Jan 2002, Paul Prescod wrote:
> > That being said, if we want to expose the
> > application to web browsers, the correct answer is
> > for the server to handle multipart/form-data, and
> > either respond with the answer, or response with a
> > form asking where the answer should be delivered.
>
> More or less my design also. And inventing a new protocol to do this
> would have only made your life harder. Working with sockets. No caching.
> Can't use PHP, Zope or JSP. Can't use web browsers. Would require a
> "client library" for each language. Etc. Etc.

I am all in favor of using existing protocols.  I
want to use HTTP for request/response and SMTP for
asynch.  I want to use MIME as the content for
both.

What you are missing is that the browser post is
RPC!

-Alex-



___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:263
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 06:26:16
Subject:Re: [rest-discuss] Reliable HTTP
Message:

On Thu, 24 Jan 2002, Paul Prescod wrote:
> But the "failure" and "keep trying" parts have nothing to do with this
> problem. That's why I think it is orthogonal. Between your *original*
> GET and your PUT someone could have twiddled the data.

The point is that HTTP does not promise to be
"Reliable"  Your spec does.

> > Even if the server is issuing message-ids and only
> > processes RPOSTS in order of message-ids:
> > a. Nothing in the spec says that clients have to
> > use message-id's in the order in which they were
> > issued.
>
> Are we talking about multiple clients or a single client? If a single
> client then the single client can sychronize its own messages! Why
> should the server worry about that?

Even if with a single client.  The server is not
guaranteeing to process messages in any order at
all!

Assuming the server issues sortable message ids,
and the client sends them in order.  How should
the server handle recieving:

  RPOST 4 Jane
  RPOST 2 Tarzan
  RPOST 3 You
  RPOST 1 Me

> If we're talking about multiple clients, then the service should be
> implemented so that order doesn't matter. If syncronization is important
> then I guess we need some kind of "lock" resources to keep clients in
> order. I can't think of an application of this off the top of my head.

This is a chat application.  The Posts append
messages to a chat window.  The user is typing:

  Me Submit
  Tarzan Submit
  You Submit
  Jane Submit

You need to handle order in a reliable protocol.

> >...
> > 1. clients should issue their own message-ids.  If
> > they don't want to get stepped on, they should
> > make them sufficiently unique (and secret).
>
> I'm not happy trusting the clients not to step on each other.

Message Ids and passwords are no different.  As
long as you don't leak message-ids among clients
you are safe.  A client that wants security just
issues a sufficiently random message-id.  (You
trust clients to be safe with their passwords
too).

> > 2. reliable messaging looks like repeat requests
>
> To the server application it should not. The reliable messaging
> infrastructure (i.e. part of the web application framework) should merge
> them.

Yes.  I agree.  This was just shorthand.

> > 3. you may want to support a seriality protocol in
> > which clients send a cardinality header (I haven't
> > decided if this should really be an ordinality
> > header, leaving the cardinality header for the
> > transaction protocols).
>
> I don't understand why the server is responsible for the client keeping
> its ducks in a row and I don't think that the clients should trust the
> server to verify the semantics of an "optional" header. Many servers
> could just let this pass quietly.

See above re "Me Tarzan, You Jane"

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:264
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 06:29:15
Subject:Re: [rest-discuss] Reliable HTTP
Message:

On Thu, 24 Jan 2002, Paul Prescod wrote:
> Is there anything about this problem that is *cause* by the repeat-try
> reliability solution that would not occur in a system that had
> inherently reliable once-only message delivery? Even in a perfect world
> where messages are delivered once and only once you can get the phantom
> write problem. PUTting over and over again may increase the chances just
> because of time passing but the problem is essentially the same.

HTTP does not claim to be Reliable.  Idempotency
is irrelevant.  You need Reliability on all
methods.

You might want to call the protocol Reliable
Delivery of POST requests.  But even then, you
still need a semantic for delivery failure (which
MAY happen).

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:265
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-25 07:34:48
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

----- Original Message -----
From: "S. Alexander Jacobson" <alex@...>


>
> Note, the reason for closing connections is that
> holding open a thread or child process(!!) for
> each client is expensive.
The KnowNow servers supposedly does 10K clients per Solaris box. I don't
know if that is expensive or not.
[honest, i'm not trying to plug them, but they're the only example of http
events that I can point to with any amount of understanding]

>
> > But you first have to model your presence app as a set of resources.
> > e.g. each user gets a URI, a persistent GET to that URI returns a
> > stream of presence messages as their presence status changes, etc..
>
> Again, that may be, but since you also have to
> write a custom client, I don't see the bonus of
> HTTP here.
I wrote a buddy list/IM clone in just HTML & JavaScript - sure it was
'custom', but I can now give it away to 10K script kiddies to innovate with.
Change graphics, chat with their thermometers, etc.
The bonus is that the client is just like 10 million other clients, with a
large support staff - all are different dynamically loaded modules within
the WebApp called WWW.









-----------------------------------------------------------------------------------
Post ID:266
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-25 09:11:44
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Thu, Jan 24, 2002 at 11:34:48PM -0800, S. Mike Dierken wrote:
> > Note, the reason for closing connections is that holding open a
> > thread or child process(!!) for each client is expensive.
>
> The KnowNow servers supposedly does 10K clients per Solaris box. I don't
> know if that is expensive or not.
> [honest, i'm not trying to plug them, but they're the only example of http
> events that I can point to with any amount of understanding]

A decent event loop/queue (different kind of event ;) could easily
scale to many tens or even hundreds of thousands of open connections;
you're really only limited by memory...


-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:267
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 13:41:52
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Thu, 24 Jan 2002, S. Mike Dierken wrote:
> > Note, the reason for closing connections is that
> > holding open a thread or child process(!!) for
> > each client is expensive.
> The KnowNow servers supposedly does 10K clients per Solaris box. I don't
> know if that is expensive or not.
> [honest, i'm not trying to plug them, but they're the only example of http
> events that I can point to with any amount of understanding]

I just took a look at the two knownow demos...
If you are talking about the knownow web clients,
they don't open a peristent GET, they just make
repeated requests, (polling the server).  This is
a workaround for the lack of sockets in
javascript.  And is much less efficient than a
straight socket conection would be.

If you are talking about the knownow event
routers, it sounds like they are implementing
listservs.  If they are sending out 10k concurrent
email messages, that is very nice.  If they are
sending out only 100-1000 concurrent messages and
just claim a max of 10k listeners, that is
incredibly unimpressive.

Either way, this has little to do with persistent
GET and the merits of HTTP for presence
applications.  The main point is that HTTP is
suboptimal for this application (but you may need
it if the client is a web browser).

> > Again, that may be, but since you also have to
> > write a custom client, I don't see the bonus of
> > HTTP here.
> I wrote a buddy list/IM clone in just HTML & JavaScript - sure it was
> 'custom', but I can now give it away to 10K script kiddies to innovate with.
> Change graphics, chat with their thermometers, etc.
> The bonus is that the client is just like 10 million other clients, with a
> large support staff - all are different dynamically loaded modules within
> the WebApp called WWW.

Yeah. Me too.  How many chat clients can your web
server support?  According to (1), a typical test
Apache server can handle ~250 requests per second.
Assuming your clients poll once per second, you
max out at 250 simulatenous clients.  That sucks!
Even if your server could handle higher capacity
the bandwidth of handling large numbers of pings
will also eventually overwhelm you.

Alternatively, you could also document a
more scalable protocol like Jabber, IRC, or Kazaa,
give away the source, get the same hackers to
work on it, and perhaps get bought by AOL!

-Alex-

(1) http://www.acme.com/software/thttpd/benchmarks.html

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:268
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 13:42:09
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:


Paul Prescod wrote:

> Whoa, Jeff. Are you in FoRK withdrawl?

Quite possibly. I'll be headed to the methadone clinic shortly to help avoid similar
withdrawal today.  ;-)  (I misparsed your original point.)

jb








-----------------------------------------------------------------------------------
Post ID:269
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-25 14:22:08
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

> The main point is that HTTP is
> suboptimal for this application

HTTP is suboptimal for *all* applications.  You can *always* do better
performance wise by building an application protocol specific to the
task.  The issue is, what can be gained by sacrificing this ability and
optimizing for the general case instead?  As it turns out, a whole
freaking lot.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:270
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 14:58:13
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, Mark Baker wrote:
> > The main point is that HTTP is
> > suboptimal for this application
>
> HTTP is suboptimal for *all* applications.  You can *always* do better
> performance wise by building an application protocol specific to the
> task.  The issue is, what can be gained by sacrificing this ability and
> optimizing for the general case instead?  As it turns out, a whole
> freaking lot.

1 server versus 100 servers seems like a good
reason not to use HTTP for presence/chat.

If I were doing asynch, I would much rather reuse
the very well tested and widely deployed SMTP
infrastructure than a new HTTP infrastructure.

For Reliable delivery (a subcategory of Asynch), I
would again rather rely on SMTP than HTTP.

For the basic terrorist_or_not.com, HTTP is a
great protocol, but, as we have seen, REST
is not.

For many applications, RPC (over HTTP) makes
sense, but REST does not.

So...
Sometimes you don't want HTTP.
Sometimes you want HTTP, but not REST.
Sometimes you want HTTP and REST.

As always, you do what makes sense for your
application.  YMMV.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:271
Sender:"scarhill" <jim@...>
Post Date/Time:2002-01-25 15:32:14
Subject:Re: Paul's HttpEvents Spec
Message:

I'm a REST newbie, but I've been following the discussions
here, and thinking about event delivery in other contexts as well. I'm
posting this not some much as serious proposal to enhance the spec,
but more to get some feedback on whether I'm "getting" REST.

In Paul's spec at
http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents,  the
various scenarios all involve using the Event-Target header to specify
a URI where events will be delivered. This URI might be a micro server
on the application client, or a third party event queuing/forwarding
service.

One additional scenario occurred to me. Suppose the server application
is willing to queue events for the client. In that case, the Client
could POST to the Subscription URI without the Event-Target header.
The response to the Subscription would still include the Location:
header (a URI that represents the subscription). The Client would then
POST to the subscription URI to retrieve queued events, or DELETE to
end the susbscription. 

I originally was thinking that the client could GET the subscription
URI in order to retrieve queued events, but now I think that that
would be wrong, because a GET in this case would change the state of
the resource by returning any queued events. I suppose a GET might
instead return an HTML page or XML document describing the current
supscription state.

So, does this proposal make sense? If not, I'd like to learn where I
went wrong.

Thanks,

Jim Ancona
jim@...







-----------------------------------------------------------------------------------
Post ID:272
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 16:41:39
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:


"S. Alexander Jacobson" wrote:

> 1 server versus 100 servers seems like a good
> reason not to use HTTP for presence/chat.

There's no data to support that assertion -wrt- scaling in that application
context.

> If I were doing asynch, I would much rather reuse
> the very well tested and widely deployed SMTP
> infrastructure than a new HTTP infrastructure.

Me to.  But no new HTTP infrastructure is needed, really.

> For Reliable delivery (a subcategory of Asynch), I
> would again rather rely on SMTP than HTTP.

Okay.

> For the basic terrorist_or_not.com, HTTP is a
> great protocol, but, as we have seen, REST
> is not.

You want to run that through by me again?  REST is the overall architectural
style of HTTP.  I don't see how you distinguish the two.

> For many applications, RPC (over HTTP) makes
> sense, but REST does not.

It only makes sense because you don't understand REST yet. ;-)

jb








-----------------------------------------------------------------------------------
Post ID:273
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 16:54:02
Subject:HttpEvents: Subscription Expiration, Authentication
Message:

One terminological suggestion, two problems, two suggested solutions.

Suggestion:  rather than calling the target of event notifications an
"event target" why not reify the notion of the subscriber and simply
call the header that indicates that URI "Subscriber"?  NB:  we should
probably work on making terminology consistent with the general
metaphors, roles, and activities of pub / sub.

----

Subscription lifetimes are problematic.  They shouldn't last forever;
doing so places an undue and unnecessary burden on the resource in
question.  The server for a subscribable resource (Publisher?) should be
able to indicate when a subscription expires, and should provide a
mechanism by which the subscriber can renew the subscription.  (Note
that this is an *extremely* useful concept in modeling presence, for
example.  It's also simply a good idea rom a robustness and scalability
perspective.)

Suggested solution:  when a Subscriber (client) obtains a subscription
via the URI indicated in the "Subscription" header, the response SHOULD
contain a header "Expiration" which indicates when the subscription
expires.  If an Expiration is indicated, the Subscriber MUST "renew" the
subscription at some point before the Expiration date in some fashion.
(How?  Presumably via a POST of some sort to the particular
subscription's Location: URI?)  If a Subscriber fails to renew a
subscription by the indicated expiration, the server MAY at any
subsequent point remove the subscription resource and stop sending
notifications to the Subscriber.

----

The mechanism Paul describes is potentially very dangerous;  it needs a
kind of authentication beyond simple principal / session
authentication.  Consider:  Mallory wants to DoS Alice.  To do so,
Mallory subscribes to Bob, but gives Alice's URI to Bob as the
Subscriber / EventTarget.  Even if Bob authenticates Mallory --- indeed,
even if Mallory is a valid user from Bob's perspective --- that still
doesn't prevent Mallory from using Bob to attack Alice.  Somehow, the
"client" that requests a subscription needs to be verifiably the "same"
in some sense as the Subscriber / EventTarget.

Suggested solution:  the response to the Subscription POST SHOULD
contain a SubscriptionID header with some arbitrary token.  The
Subscriber MUST return this header in the responses to all notifications
POSTED by the Publisher (server) to the Subscriber URI.  The Publisher
MAY delete any subscription and cease notifications for any Subscriber
that fails to return the appropriate SubscriptionID in the response to
any notification.

----

$0.02,

jb










-----------------------------------------------------------------------------------
Post ID:274
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-25 17:25:35
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

----- Original Message -----
From: "S. Alexander Jacobson" <alex@...>

>
> I just took a look at the two knownow demos...
> If you are talking about the knownow web clients,
> they don't open a peristent GET, they just make
> repeated requests, (polling the server).  This is
> a workaround for the lack of sockets in
> javascript.  And is much less efficient than a
> straight socket conection would be.
They use a persistent response. If the connection is closed, they re-open
it. That might be where the 'repeated requests' are coming from. Those are
very infrequent.

>
> If you are talking about the knownow event
> routers, it sounds like they are implementing
> listservs.  If they are sending out 10k concurrent
> email messages, that is very nice.  If they are
> sending out only 100-1000 concurrent messages and
> just claim a max of 10k listeners, that is
> incredibly unimpressive.
Oh. Remember, I don't have real numbers as I do not work there - it could be
bigger and I would have no way of knowing.
These are 10K concurrent listeners, I don't know the fan-out of an event
(how many listeners per event average).
This is only one node in a cluster - I don't know that there is a limit to
the cluster size.

>
> Either way, this has little to do with persistent
> GET and the merits of HTTP for presence
> applications.  The main point is that HTTP is
> suboptimal for this application (but you may need
> it if the client is a web browser).
If the client were another server, would http be sufficient?

>
> > > Again, that may be, but since you also have to
> > > write a custom client, I don't see the bonus of
> > > HTTP here.
> > I wrote a buddy list/IM clone in just HTML & JavaScript - sure it was
> > 'custom', but I can now give it away to 10K script kiddies to innovate
with.
> > Change graphics, chat with their thermometers, etc.
> > The bonus is that the client is just like 10 million other clients, with
a
> > large support staff - all are different dynamically loaded modules
within
> > the WebApp called WWW.
>
> Yeah. Me too.  How many chat clients can your web server support?
10,000. Like I said, the KN server can handle 10k concurrent browser clients
per cluster node.

> According to (1), a typical test
> Apache server can handle ~250 requests per second.
> Assuming your clients poll once per second, you
> max out at 250 simulatenous clients.  That sucks!
Yeah - good thing nobody except strawman.org does that.

> Even if your server could handle higher capacity
> the bandwidth of handling large numbers of pings
> will also eventually overwhelm you.
>
> Alternatively, you could also document a
> more scalable protocol like Jabber, IRC, or Kazaa,
> give away the source, get the same hackers to
> work on it, and perhaps get bought by AOL!
Or examine your assumptions.

Nobody here is suggesting polling is the preferred way to go. A server that
transparently handled polling for backward compatibility would help in many
situations, as long as the scalability/traffic problems don't surface.








-----------------------------------------------------------------------------------
Post ID:275
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-25 17:34:14
Subject:Re: [rest-discuss] HttpEvents: Subscription Expiration, Authentication
Message:

----- Original Message -----
From: "Jeff Bone" <jbone@...>

>
> The mechanism Paul describes is potentially very dangerous;  it needs a
> kind of authentication beyond simple principal / session
> authentication.
Very good point.

> Consider:  Mallory wants to DoS Alice.  To do so,
> Mallory subscribes to Bob, but gives Alice's URI to Bob as the
> Subscriber / EventTarget.  Even if Bob authenticates Mallory --- indeed,
> even if Mallory is a valid user from Bob's perspective --- that still
> doesn't prevent Mallory from using Bob to attack Alice.  Somehow, the
> "client" that requests a subscription needs to be verifiably the "same"
> in some sense as the Subscriber / EventTarget.
>
> Suggested solution:  the response to the Subscription POST SHOULD
> contain a SubscriptionID header with some arbitrary token.  The
> Subscriber MUST return this header in the responses to all notifications
> POSTED by the Publisher (server) to the Subscriber URI.  The Publisher
> MAY delete any subscription and cease notifications for any Subscriber
> that fails to return the appropriate SubscriptionID in the response to
> any notification.
>
Another way to think about this particular approach of creating
subscriptions is that it is creating a 'route' from a source to a target.
The agent creating that route needs permissions to read from the source and
write to the target. In addition, since the target is receiving information
about the source, the target needs permissions to read from the source. And
if the permissions change, then the 'route' needs to be updated to reflect
that - for example if Alice is denied permission to read the source, the
route/subscription should be disabled (if you can't 'see' a resource, you
shouldn't be able to 'hear' it either). (you can argue that it should be
deleted, but re-enabling permissions isn't going to tell you what
subscriptions need to be re-created.)
details details...









-----------------------------------------------------------------------------------
Post ID:276
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 17:40:19
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:
> 
> On Thu, 24 Jan 2002, Paul Prescod wrote:
> > There is always a gap between one model and another. The problem is
> > we've learned to think about it one way and now we must learn to think
> > about it another. If you taught someone REST and you taught them sockets
> > and asked them to invent an email system I think they would find it
> > easier to do it using HTTP and REST.
> 
> The more comparable example is if you asked them
> to set up an asynchronous peer to peer
> messaging system (aka email). Would they choose
> HTTP or SMTP?

If they understood REST I think that they would choose HTTP. Better
applications can be built if you model data elements and processes as
resources rather than endpoints. If you're building a *new* application
then you need to write the software on the client and server sides
anyhow. We all know how little effort it takes to put HTTP on the client
side. I've shipped products with HTTP servers written in four different
languages.

>...
> > If you want a web interface then you can use a POST form.
> 
> See my reply to MB.  This is not modeling the
> application in terms of resources.  It is RPC.

I don't know why you say it is RPC. The definition in my mind of RPC is
that the incoming message has a tag or identifier that instructs the
server what to do with it. But this "endpoint" resource would have one
and only one task. It would expect the input to be appropriate for that
task.

> Returning a URL and then asking the client to
> watch the new URL seems like a lot of overhead and
> waste.

No, it is just a separation of concerns. Yes it takes more round-trips
than the SMTP system. It is also much more functional. The client can
check for status whenever it wants. Other clients can be attached to the
*same* computation because it is a first-class resource. Clients can
share information about what computations they are watching by sharing
the URI. Disconnected clients have the option of polling which they do
not with SMTP (unless there is a mailbox intermediary).

>...
> Good argument, but the polling is ugly.  A
> callback system is much nicer and much ligher on
> system resources!

The point is that the same system could support *both*. This would be
much harder to do with SMTP. 

> > Conventions for asyncronous notification are here:
> >
> >  * http://www.prescod.net/HTTP_event_conventions.html
> 
> Ok.  So that is another new protocol.  It is not
> real life HTTP.  

If I use XHTML or RSS am I using XML? It is real life HTTP up until the
point that where I start doing things against the HTTP model such as
inventing private namespaces or telling the server what to do through
method names or using POST for logical queries.

> ... It also seems no better than just
> sending a reply-to in the first place.

If you just send a reply-to then the client and server have no mutually
visible resource that represents the transaction. That means that the
client can't monitor it. The client can't cancel it. You could invent
some kind of UUID system but now you're inventing a private namespace.

> > Anyhow, that's how I would model it. Notice how I try to think about the
> > web interface at each step.
> 
> I am doing the same thing.  The whole point of
> MIME-RPC is to model the web interface.  Which
> uses MIME rather than SOAP or XML-RPC.

When I say "web interface" I mean HTML web application.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:277
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 17:54:54
Subject:Re: [rest-discuss] Reliable HTTP
Message:

"S. Alexander Jacobson" wrote:
> 
> ...
> 
> Even if with a single client.  The server is not
> guaranteeing to process messages in any order at
> all!
> 
> Assuming the server issues sortable message ids,
> and the client sends them in order.  How should
> the server handle recieving:
> 
>   RPOST 4 Jane
>   RPOST 2 Tarzan
>   RPOST 3 You
>   RPOST 1 Me

Why would a single client CHOOSE to send the messages in the wrong
order???? I need you to explain why the client is not written so that
the RPOST 3 message always comes after the RPOST 2 message and before
the RPOST 4 message. The "default" way to write such an application
would be to fully handle one message before even considering the next. I
don't see how this is the server's responsibility.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:278
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 18:19:18
Subject:Re: [rest-discuss] Re: Paul's HttpEvents Spec
Message:

scarhill wrote:
> 
> ...
> One additional scenario occurred to me. Suppose the server application
> is willing to queue events for the client. In that case, the Client
> could POST to the Subscription URI without the Event-Target header.
> The response to the Subscription would still include the Location:
> header (a URI that represents the subscription). The Client would then
> POST to the subscription URI to retrieve queued events, or DELETE to
> end the susbscription.

You could certainly define a web service this way. I am on the fence
about whether it makes sense to handle this case in the general spec
instead of simplifying things by requiring the Queue to be a separate
component. It could go either way.

> I originally was thinking that the client could GET the subscription
> URI in order to retrieve queued events, but now I think that that
> would be wrong, because a GET in this case would change the state of
> the resource by returning any queued events. 

I would prefer to make each event into a separate resource and do a
GET/DELETE on that resource. The top-level subscription resource would
contain an index of these sub-resources.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:279
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-25 18:02:41
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, Jan 25, 2002 at 08:41:52AM -0500, S. Alexander Jacobson wrote:
> 
> Yeah. Me too.  How many chat clients can your web
> server support?  According to (1), a typical test
> Apache server can handle ~250 requests per second.
> Assuming your clients poll once per second, you
> max out at 250 simulatenous clients.  That sucks!
[..]
> (1) http://www.acme.com/software/thttpd/benchmarks.html

Err, that's hits per second, not concurrent connections. You're using
a benchmark of Apache by an Apache competitor as an indication of how
all Web servers perform in general? Tsk. It's widely acknowledged
that Apache is performance-limited, in a trade-off for stability,
developability, etc.

Let me be more explicit: I know of at least two vendors who have HTTP
implementations that can handle 50,000+ concurrent persistent
connections on commodity hardware. 

It's much more instructive to look at intermediary implementations
when you're talking about the performance overhead of HTTP; they're
more optimised for performance, and they're not doing anything with
the payload; it's all just overhead. It's relatively easy to achieve
1000+ reqs/sec [1]. Most modern HTTP intermediaries can approach or
exceed wire speed.

I'd note that these numbers don't include any of the larger
commercial vendors (with more developed implementations) who
participated in past years, but now don't want their numbers made
public, as it starts a performance war...


[1] http://www.measurement-factory.com/results/public/cacheoff/N04/raw.html



-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:280
Sender:Jim Ancona <jim@...>
Post Date/Time:2002-01-25 18:30:16
Subject:Re: [rest-discuss] Re: Paul's HttpEvents Spec
Message:

--- Paul Prescod <paul@...> wrote:
> I would prefer to make each event into a separate resource and do a
> GET/DELETE on that resource. The top-level subscription resource would
> contain an index of these sub-resources.

So how would the client find out which event resources were available? By doing
a GET on the top-level subscription resource? Then it would have to do a
GET/DELETE on each event. Sounds like a lot of round trips.

Jim

=====
Jim Ancona
jim@...                     jancona@...

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com






-----------------------------------------------------------------------------------
Post ID:281
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 18:32:04
Subject:Re: [rest-discuss] Reliable HTTP
Message:

"S. Alexander Jacobson" wrote:
> 
> On Thu, 24 Jan 2002, Paul Prescod wrote:
> > But the "failure" and "keep trying" parts have nothing to do with this
> > problem. That's why I think it is orthogonal. Between your *original*
> > GET and your PUT someone could have twiddled the data.
> 
> The point is that HTTP does not promise to be
> "Reliable"  Your spec does.

I guess we have a different definition of reliable. I mean that the
message gets through. I consider ordering issues to be orthogonal. Part
of the web zen is loose coupling between components. If responsibility
for ordering can be pushed off completely onto the client then I think
it should be.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:282
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 18:35:16
Subject:Re: [rest-discuss] Reliable HTTP
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> HTTP does not claim to be Reliable.  Idempotency
> is irrelevant.  You need Reliability on all
> methods.

Idempotency is relevant. I'm trying to define the minimum "protocol"
extension needed to allow once and only once delivery. Idempotency means
that I need do nothing with GET and PUT because by definition, eleven
deliveries are the same as one. Locking, ordering, lost updates etc. are
all orthogonal issues.

> You might want to call the protocol Reliable
> Delivery of POST requests.  But even then, you
> still need a semantic for delivery failure (which
> MAY happen).

The client will know if it failed to deliver. How coud the protocol
help? You want an HTTP server to report to an HTTP client that the
network cable is unplugged?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:283
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-25 18:40:09
Subject:Re: [rest-discuss] Re: Paul's HttpEvents Spec
Message:

>
> I originally was thinking that the client could GET the subscription
> URI in order to retrieve queued events, but now I think that that
> would be wrong, because a GET in this case would change the state of
> the resource by returning any queued events. I suppose a GET might
> instead return an HTML page or XML document describing the current
> supscription state.
>
If you ensure multiple GETs don't pop the head off the queue then you can
use it.
You'd need an explicit 'ack' to pop the head off the queue. Perhaps DELETE
would do it, but I don't know whether that is correct or not - whether that
breaks the 'queue modelled as a resource' concept.
GET returning an explicit list of messages with ids might be more resty...
hard to say.






-----------------------------------------------------------------------------------
Post ID:284
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-25 18:39:27
Subject:security of callbacks
Message:

HTTP callbacks create new security issues.  In the following message I present
an orderly way to approach those issues.

An HTTP request is asymetric with regard to state.  Client state is opaque,
except that it must have enough state to interpret a response.  Server state is
exposed using HTTP methods.  Clients have always been less prone to security
problems than servers, because they expose so much less state.  The only client
resource exposed is the state machine that performs the request.  For a callback
sink to be no less secure than a client request, the only resource the sink can
expose is a similar state machine.

What's in that state machine?  There is a contractual obligation to perform
standard syntactic operations like reading the number of bytes specified in the
Content-Length response header.  There is implicit knowledge of a reader process
with an open socket, some memory allocated, maybe some access restrictions.
There is implicit knowledge of context: the reader assumes that the writer is
the same process it initially contacted.  Etc -- this is not an exhaustive list.
One thing that is not exposed is information about the sink state after the
transaction is completed.

Any approach to callbacks that directly addressed security could be evaluated by
comparison with the above baseline.  For the purpose of doing such an
evaluation, it is useful to define a new pseudo-method as follows: this method
exposes no more server state than is in a requester state machine.  A reasonable
name for this pseudo-method is NOTIFY.  A NOTIFY method MAY affect any
properties of sink state that a response MAY affect; it MUST affect any elements
of sink state that a response MUST affect; etc.

NOTIFY is not necessarily a new actual method.  It is just a convenience for
discussion.  It should be possible to define it as a synonym for existing HTTP
operations.  For example, we might be able to POST to a well-known list of
properties, with one property for every aspect of a requester state machine.
EG,
POST $root_uri/properties/headers/Content-Length/ HTTP/1.1
POST $root_uri/properties/assumptions/source_identity/ HTTP/1.1
POST $root_uri/properties/states/message_send_complete/ HTTP/1.1

A sink MUST NOT expose any properties that a request state machine wouldn't.
So, to the degree that properties of request state machines can be known in
advance, the list of exposable properties can be known in advance.  A source
MUST NOT POST a value to $root_uri/properties/headers/ that would not be a legal
value in a response header.  A sink MUST accept any value in
$root_uri/properties/headers/ that would be a legal value in a response header.

Given this equipment, we can place Jeff's comments about authentication and
expiration.  Expiration is the inverse of caching, therefore sink URIs and
values related to expiration would be defined based on cache-response-directives
in section 14.9 of RFC 2616.  A requester can assume authentication, but a
callback sink can't.  (There are probably other assumptions in the state machine
of a requester.)  These can be tackled one by one and addressed by a URI
hierarchy exposing them as properties.  EG,
POST $root_uri/properties/assumptions/source_identity/ HTTP/1.1

Some miscellaneous comments:
* Mike Dierken's reply-in-request is an obvious reference point here.  It
strikes me as surprizingly sensible now.
* It is unavoidable for the state machine that accepts POST callbacks at the
sink to leak state in a different way from the state machine of a requester.
However, well-made HTTP servers should already keep this leakage to a minimum,
since they are necessarily more paranoid than HTTP clients.

Summarizing, exposed sink properties must be a small and strictly limited subset
of all POSTable properties.  Given that exposed sink properties are a 1-1 match
with reply properties, then it should be possible to perform callbacks without
creating new security leaks.

- Lucas








-----------------------------------------------------------------------------------
Post ID:285
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 18:42:47
Subject:Re: [rest-discuss] Re: Paul's HttpEvents Spec
Message:

Jim Ancona wrote:
> 
> --- Paul Prescod <paul@...> wrote:
> > I would prefer to make each event into a separate resource and do a
> > GET/DELETE on that resource. The top-level subscription resource would
> > contain an index of these sub-resources.
> 
> So how would the client find out which event resources were available? By doing
> a GET on the top-level subscription resource? Then it would have to do a
> GET/DELETE on each event. Sounds like a lot of round trips.

With persistent connections, I don't think that this is any worse than
POP or IMAP. Actually consider this level of chatter:

+OK paulp has 9 visible messages (0 hidden) in 29777 octets.
448: Client to Server (6 bytes)
STAT
448: Server to Client (13 bytes)
+OK 9 29777
448: Client to Server (6 bytes)
LIST
448: Server to Client (39 bytes)
+OK 9 visible messages (29777 octets)
448: Server to Client (75 bytes)
1 4107
2 3284
3 3819
4 2889
5 2966
6 3219
7 1792
8 3724
9 3977
.
448: Client to Server (6 bytes)
UIDL
448: Server to Client (28 bytes)
+OK uidl command accepted.
448: Server to Client (219 bytes)
1 dNS"!H~+!!9o>!!Qj("!
2 73n"!p2<!!(h\"!m*(!!
3 B#<"!<!g!!XZ&#!5*&"!
4 -P^"!-L6!!^i7"!4>]!!
5 ZT%#!nTH"!P0)#!PMI!!
6 Z(`"!K\>!!<JS"!~aD"!
7 [A["!GP`!!)\c"!+=V"!
8 *aV"!m2E"!7YO"!nLF"!
9 CE+!!mAH!!DEG!!["_!!
.
448: Client to Server (8 bytes)
RETR 1
448: Server to Client (17 bytes)
+OK 4107 octets


 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:286
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-25 18:45:59
Subject:Re: [rest-discuss] Re: Paul's HttpEvents Spec
Message:

>
> So how would the client find out which event resources were available? By
doing
> a GET on the top-level subscription resource? Then it would have to do a
> GET/DELETE on each event. Sounds like a lot of round trips.
>
Round trips are needed for reliability - confirming that the message
actually made it down to the client and was successfully processed.
You could PUT a status of 'accepted' on inital delivery and after some time
passes do a final ack via DELETE. (or use PUT for both and have the
collection defined to be messaging only in a certain state, or not, and have
the client filter... lots of choices)






-----------------------------------------------------------------------------------
Post ID:287
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 18:45:55
Subject:Re: [rest-discuss] HttpEvents: Subscription Expiration, Authentication
Message:


> Another way to think about this particular approach of creating
> subscriptions is that it is creating a 'route' from a source to a target.
> The agent creating that route needs permissions to read from the source and
> write to the target. In addition, since the target is receiving information
> about the source, the target needs permissions to read from the source. And
> if the permissions change, then the 'route' needs to be updated to reflect
> that - for example if Alice is denied permission to read the source, the
> route/subscription should be disabled (if you can't 'see' a resource, you
> shouldn't be able to 'hear' it either). (you can argue that it should be
> deleted, but re-enabling permissions isn't going to tell you what
> subscriptions need to be re-created.)
> details details...

All good thoughts.  For the most generic purposes, though, I think this is more
complexity than is required.  It takes the task out of the realm of simple
authentication --- not of principal but of transaction --- and into a realm of
authentication + authorization.  (To clarify the distinction:  authentication
is proving continuity of identity for some purpose, authorization is deciding
whether / proving that some authenticated principal has permission to do
something.)

With a scheme similar to the one I proposed, you're only doing the most basic
kind of authentication --- you're simply proving that the Subscriber event sink
"knows" and (continuously) "approves of" the subscription that was requested on
its behalf.  With Mike's more sophisticated scheme, it seems that you need to
introduce some notion of permissions and authorization vis-a-vis those
permissions.  This may be useful or even necessary for some applications, but
IMO it's not really necessary for the most basic uses of HttpEvents.  And, it
can be built on top of the simpler mechanism.

jb









-----------------------------------------------------------------------------------
Post ID:288
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 19:01:19
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, Jeff Bone wrote:

>
>
> "S. Alexander Jacobson" wrote:
>
> > 1 server versus 100 servers seems like a good
> > reason not to use HTTP for presence/chat.
>
> There's no data to support that assertion -wrt- scaling in that application
> context.

Mark Nottingham noted:
  A decent event loop/queue (different kind of
  event ;) could easily scale to many tens or even
  hundreds of thousands of open connections;
  you're really only limited by memory...

Mike noted that the state of the art know-now
server scales to 10k.  I think Mike is
overestimating, but that is another mail.

Even if Mike is correct, you are looking at at
least an order of magnitude difference in
deployment costs between the two systems.

Note: In theory one could implement an HTTPd using
an event loop/queue (e.g. Medusa), in practice one
doesn't and the rest of the HTTP infrastructure
doesn't really support this scale.

> > If I were doing asynch, I would much rather reuse
> > the very well tested and widely deployed SMTP
> > infrastructure than a new HTTP infrastructure.
>
> Me to.  But no new HTTP infrastructure is needed, really.

!!!!What is most of the recent discussion about!?
In contrast, here is a short version of "reliable
delivery" using SMTP:

   Send the message to the address using SMTP.

Here is a short version of asynchronous callbacks
using SMTP:

   Send the message to the reply-to address using SMTP

Contrast this with all of Pauls various specs.

> > For the basic terrorist_or_not.com, HTTP is a
> > great protocol, but, as we have seen, REST
> > is not.
>
> You want to run that through by me again?  REST is the overall architectural
> style of HTTP.  I don't see how you distinguish the two.

Terrorist_or_not.com uses RPC to deliver the
queries.  The target of the POST is a function not
a resource.

I think the format of the POST should me
multipart/form-data.  XML-RPC folks prefer XML-RPC
and SOAP people prefer SOAP envelopes.
These are all RPC.

No one here has given a persuasive non-RPC version
of the application.

> > For many applications, RPC (over HTTP) makes
> > sense, but REST does not.
>
> It only makes sense because you don't understand REST yet. ;-)

I think I understand REST.  I'm not sure you do :-).
If you do, explain how to make
terrorist_or_not.com non-RPC and why it would be
better that way.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax









-----------------------------------------------------------------------------------
Post ID:289
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-25 19:08:40
Subject:RE: [rest-discuss] security of callbacks
Message:

A couple misc points:
* I don't know that a URI hierarchy is the right way to expose properties.  This
creates a stateful way of sending messages property by property which is not so
good.  It can be avoided by PUTting an entire callback to the sink instead of
POSTing a series of callback properties.
* Status codes and replies returned by the sink should not expose state that a
requester can't expose.  Therefore sink replies MUST NOT have an entity-body, a
source MUST NOT GET sink properties, a sink MUST NOT return 301 Moved
Permanently, etc.








-----------------------------------------------------------------------------------
Post ID:290
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 19:15:15
Subject:Re: [rest-discuss] security of callbacks
Message:

I'm going to read it again, but...  I don't get it.  Yet, probably.  It looks like
you are in fact reifying the whole notion of a response.  I'm not sure how that
could be useful.  A couple of bits of feedback:

> Given this equipment, we can place Jeff's comments about authentication and
> expiration.  Expiration is the inverse of caching,

I don't think so.  The expiry we're talking about is expiration of the commitment on
the part of the source to notify the sink.  That commitment is the subscription
abstraction, and can and probably should be reified.  Expiration defines a sort of
TTL for an instance of that subscription abstraction.  (Actually, Expiration should
probably be expressed as TTL rather than any absolute date or time construct.)

WRT caching, expiration and notification are both mechanisms for invalidating cached
objects, but IMO these are mostly orthogonal to the issue of how to model a
publisher / subscriber relationship.

jb









-----------------------------------------------------------------------------------
Post ID:291
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 19:20:30
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, S. Mike Dierken wrote:
> > I just took a look at the two knownow demos...
> > If you are talking about the knownow web clients,
> > they don't open a peristent GET, they just make
> > repeated requests, (polling the server).
> They use a persistent response. If the connection is closed, they re-open
> it. That might be where the 'repeated requests' are coming from. Those are
> very infrequent.

What is a persisent response?  I think they may do
keep-alive my repeatedly asking the server "any
messages, any messages,....", but that is still
polling and it is still ugly (a waste of resources
and bandwidth).

> >
> > If you are talking about the knownow event
> > routers, it sounds like they are implementing
> > listservs.  If they are sending out 10k concurrent
> > email messages, that is very nice.  If they are
> > sending out only 100-1000 concurrent messages and
> > just claim a max of 10k listeners, that is
> > incredibly unimpressive.
> Oh. Remember, I don't have real numbers as I do not work there

If you don't have real numbers then lets drop
knownow.

> > Either way, this has little to do with persistent
> > GET and the merits of HTTP for presence
> > applications.  The main point is that HTTP is
> > suboptimal for this application (but you may need
> > it if the client is a web browser).
> If the client were another server, would http be sufficient?

Not if you only want to send messages when the
client is "available."

> > Yeah. Me too.  How many chat clients can your web server support?
> 10,000. Like I said, the KN server can handle 10k concurrent browser clients
> per cluster node.

Ok.  Great.  What is the polling frequency?
My point is that whatever the number, a server
that allows clients to hold open connections for
long periods of time will perform orders of
magnitude better.

You could implement with HTTP if the server chunk
encoded delivery of messages and the client held
the connection open long enough, but as you noted
this is a serious abuse of HTTP and as I noted,
most servers and intermediaries aren't happy to
let an HTTP connection stay silent for too long.

> > Even if your server could handle higher capacity
> > the bandwidth of handling large numbers of pings
> > will also eventually overwhelm you.
> >
> > Alternatively, you could also document a
> > more scalable protocol like Jabber, IRC, or Kazaa,
> > give away the source, get the same hackers to
> > work on it, and perhaps get bought by AOL!
> Or examine your assumptions.
>
> Nobody here is suggesting polling is the preferred way to go. A server that
> transparently handled polling for backward compatibility would help in many
> situations, as long as the scalability/traffic problems don't surface.

The issue is that HTTP requires polling to
establish presence.

Let me ask it all another way, do you want to use
HTTP instead of telnet/ssh (to interact with the
shell)?

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax









-----------------------------------------------------------------------------------
Post ID:292
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-25 18:56:40
Subject:Re: [rest-discuss] HTTP Event Conventions
Message:

I was so excited about this, I put together a draft [1] that night.
It does have some commonality with Paul's proposal, but it's
optimised for the problem domain.

Comments appreciated. I'd be happy to add some people as co-authors
if they're interested, but I don't know that you'd want to get
involved in the politics of WEBI ;)

Please discuss here; it's not ready for discussion in WEBI yet.


[1] http://test.mnot.net/wni.txt



On Wed, Jan 23, 2002 at 03:53:16PM -0800, Mark Nottingham wrote:
> 
> You should take a look at WEBI[1][2]; with a bit of work with an eye
> to the audience/requirements[3], this could easily be a candidate
> (connectivity monitoring is the only thing that really stands out, at
> first glance).
> 
> I'd very much encourage you to consider this; if someone's
> interested, please drop me a line.
> 
> 
> [1] http://www.mnot.net/papers/ietf-49-wrec.pdf
> [2] http://www.ietf.org/html.charters/webi-charter.html
> [3] http://www.ietf.org/internet-drafts/draft-ietf-webi-rup-reqs-02.txt
> 
> 
> 
> On Wed, Jan 23, 2002 at 12:52:38PM -0800, Paul Prescod wrote:
> > http://www.prescod.net/HTTP_event_conventions.html
> > 
> > I wrote this up in a rush so it isn't 100% coherent but it's a starting
> > place for what I've been thinking about. It addresses many of the
> > concerns that people have raised in one message or another. 
> > 
> > Mike B: It can watch any resource.
> > 
> > Mike D: Notifications must say what kind of action happened.
> > 
> > Jeff B: Any notification syntax is allowed. Query-like triggers can be
> > handled (as they are on today's web) through POST parameters.
> > 
> > Lucas: Limited support for working with environments where you do not
> > control headers.
> > 
> > Alex: It uses MIME. ;)
> > 
> > It's about a million miles from being complete but in my mind it has a
> > certain coherence and elegance.
> > 
> > Now I've got to try and do real work for a few days...
> > 
> >  Paul Prescod
> > 
> > 
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> > 
> >  
> > 
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> > 
> > 
> 
> -- 
> Mark Nottingham
> http://www.mnot.net/
>  
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:293
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-25 19:25:29
Subject:Re: [rest-discuss] HttpEvents: Subscription Expiration, Authentication
Message:

----- Original Message -----
From: "Jeff Bone" <jbone@...>

>
>
> > Another way to think about this particular approach of creating
> > subscriptions is that it is creating a 'route' from a source to a
target.
> > The agent creating that route needs permissions to read from the source
and
> > write to the target. In addition, since the target is receiving
information
> > about the source, the target needs permissions to read from the source.
And
> > if the permissions change, then the 'route' needs to be updated to
reflect
> > that - for example if Alice is denied permission to read the source, the
> > route/subscription should be disabled (if you can't 'see' a resource,
you
> > shouldn't be able to 'hear' it either). (you can argue that it should be
> > deleted, but re-enabling permissions isn't going to tell you what
> > subscriptions need to be re-created.)
> > details details...
>
> All good thoughts.  For the most generic purposes, though, I think this is
more
> complexity than is required.  It takes the task out of the realm of simple
> authentication --- not of principal but of transaction --- and into a
realm of
> authentication + authorization.  (To clarify the distinction:
authentication
> is proving continuity of identity for some purpose, authorization is
deciding
> whether / proving that some authenticated principal has permission to do
> something.)
>
> With a scheme similar to the one I proposed, you're only doing the most
basic
> kind of authentication --- you're simply proving that the Subscriber event
sink
> "knows" and (continuously) "approves of" the subscription that was
requested on
> its behalf.  With Mike's more sophisticated scheme, it seems that you need
to
> introduce some notion of permissions and authorization vis-a-vis those
> permissions.  This may be useful or even necessary for some applications,
but
> IMO it's not really necessary for the most basic uses of HttpEvents.  And,
it
> can be built on top of the simpler mechanism.
>

You are probably right. I wasn't intending that these authorization concepts
be visible in any message exchange - just that there are many applications
of subscribing that need to take these issues into consideration. The
minimal communication is just authentication aware. For example, when the
subscription is used to deliver an event, and the event server provided the
authentication credentials of the creator of the subscription, the receiver
may reject the events (401, etc) - the event server (as an intermediary) may
disable that subscription and perhaps echo that rejection back to the
subscriber so they can deal with the delivery error.

Is an event server that we are talking about in reality an intermediary -
with issues of credential hand-off, etc.?











-----------------------------------------------------------------------------------
Post ID:294
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 19:35:02
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:

> Mark Nottingham noted:
>   A decent event loop/queue (different kind of
>   event ;) could easily scale to many tens or even
>   hundreds of thousands of open connections;
>   you're really only limited by memory...
>
> Mike noted that the state of the art know-now
> server scales to 10k.  I think Mike is
> overestimating, but that is another mail.

Go do some homework re: scalability considerations on network servers of various
kinds.  The constraining factor for our buddies at KN is how many open sockets and
how much data can reasonably be handled by / pumped through various OS kernels,
etc.  It's network protocol stack considerations.  A Web-based service has the
same *fundamental* constraints as any other TCP-based service;  the problem is
compounded by various factors, but scalability in terms of users / machine is
going to be same-order for a Web-based solution and any other TCP-based solution,
all other things being equal.  (UDP offers some advantages, but just as many
disadvantages.  Our event notification protocol at Activerse was a sort of
mucked-up HTTP-alike over UDP, and its a design decision I've regretted ever since
then.)

> Even if Mike is correct, you are looking at at
> least an order of magnitude difference in
> deployment costs between the two systems.

No offense, but this just isn't true.  Any differences are functions of the
various HTTP implementations, not anything having to do with HTTP itself.  Any
TCP-based solution is going to hit roughly the same limits on the same hardware.

> !!!!What is most of the recent discussion about!?

How to *use HTTP* --- not how to fill in the holes.  It's a subtle point.  You'll
get it eventually.

> > > For the basic terrorist_or_not.com, HTTP is a
> > > great protocol, but, as we have seen, REST
> > > is not.
> >
> > You want to run that through by me again?  REST is the overall architectural
> > style of HTTP.  I don't see how you distinguish the two.
>
> Terrorist_or_not.com uses RPC to deliver the
> queries.  The target of the POST is a function not
> a resource.

(a) The point is that REST is not a protocol, HTTP is a protocol
(b) REST is the architectural style of HTTP + URI
(c) If HTTP is a great protocol, then REST is a great style ;-)
(d) If you're using HTTP to do RPCs, you aren't using HTTP
(e) Instead, you're tunneling some other protocol *through* HTTP
(f) If you're tunneling other protocols through HTTP, you just don't get HTTP
(g) If you don't get HTTP, you can't understand REST

> I think the format of the POST should me
> multipart/form-data.  XML-RPC folks prefer XML-RPC
> and SOAP people prefer SOAP envelopes.
> These are all RPC.

I think Mark's perspective --- certainly my own perspective --- is that the
XML-RPC and SOAP communities and the RPC-oriented "web services" efforts that we
see all over the place today --- largely represent the same kind of sadly futile
tail-chasing that lots of *very smart people* in our industry are prone to getting
into every few years with new technology.  DCE.  CORBA.  PUSH.  All of these
things are interesting, but they've all ended up in a kind of complexity death
spiral that absolutely limits their proliferation.  The Web, by contrast, is all
about maximum proliferation.  Given the Web as an existance proof, we should look
at it to learn what characteristics it has that influence adoption, scalability,
etc.

> If you do, explain how to make
> terrorist_or_not.com non-RPC and why it would be
> better that way.

I'll take that challenge.  Next message.

jb








-----------------------------------------------------------------------------------
Post ID:295
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 19:44:23
Subject:Re: [rest-discuss] HttpEvents: Subscription Expiration, Authentication
Message:

Jeff Bone wrote:
> 
> One terminological suggestion, two problems, two suggested solutions.
> 
> Suggestion:  rather than calling the target of event notifications an
> "event target" why not reify the notion of the subscriber and simply
> call the header that indicates that URI "Subscriber"?  

Okay.

> ...
> Suggested solution:  when a Subscriber (client) obtains a subscription
> via the URI indicated in the "Subscription" header, 

We need to differentiate between the subscription factory and the
subscription...

i.e. there is National Geographic. The subscribed-to resource.
There is "publisher's clearinghouse". The subscription factory.
And there is MY subscription. The thing that I need to spend money to
upkeep.

> ... the response SHOULD
> contain a header "Expiration" which indicates when the subscription
> expires.

Okay. But there must be a way to retreive this later or the expiration
data is "information not on the web." It should always be available at
the "my subscription" resource. In fact the ability to get it in the
original subscription transaction should be viewed as an optimization to
avoid a hop.

> ...  If an Expiration is indicated, the Subscriber MUST "renew" the
> subscription at some point before the Expiration date in some fashion.
> (How?  Presumably via a POST of some sort to the particular
> subscription's Location: URI?) 

I don't want to end up overloading POST to the subscription URI. I guess
right now we don't have any behaviour there yet so it should be okay to
use that for renewal. I guess you can "suggest" a renewal period and the
POST will return one.

> ... If a Subscriber fails to renew a
> subscription by the indicated expiration, the server MAY at any
> subsequent point remove the subscription resource and stop sending
> notifications to the Subscriber.

Fine. Maybe there should be a way to let them "piggy back" notifications
with expiration information. i.e. as long as we talk to each other in
the next hour I'll extend your subscription for an hour. But let's leave
that out for now and see if there is demand for it later.

> The mechanism Paul describes is potentially very dangerous;  it needs a
> kind of authentication beyond simple principal / session
> authentication.  Consider:  Mallory wants to DoS Alice.  To do so,
> Mallory subscribes to Bob, but gives Alice's URI to Bob as the
> Subscriber / EventTarget.  Even if Bob authenticates Mallory --- indeed,
> even if Mallory is a valid user from Bob's perspective --- that still
> doesn't prevent Mallory from using Bob to attack Alice. 

Attack is a strong word. I would say that annoyance is the best you
could achieve with any reasonable web service. Plus, if the web service
has authenticated Mallory, and thus has a form of accountability, then
what's worse about this than having Mallory directly send data to a URI
at Alice? Why bother with the intermediary?

> ... Somehow, the
> "client" that requests a subscription needs to be verifiably the "same"
> in some sense as the Subscriber / EventTarget.

The client needs to say that it really does want the messages. Whether
it is the same or not is irrelevant. i.e. if I sign you up for FoRK,
that's only a problem if you happen to be a FoRK addict and you're
trying to quit. If you WANT FoRK then what does it matter whether you
signed yourself up or not?

This suggests that the original subscription should be jiggered so that
it expires after the first message. It should require a confirmation for
further messages. The confirmation does not have to be as complicated as
a subscriptionID. A simple "please continue this subscription" should
suffice.

I feel like somehow this is related to expiration. Some subscriptions
expire after a certain amount of time. Others expire after a certain
number of messages. Most SHOULD start in a state such that they expire
after the first message.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:296
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 19:47:52
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, Paul Prescod wrote:
> > The more comparable example is if you asked them
> > to set up an asynchronous peer to peer
> > messaging system (aka email). Would they choose
> > HTTP or SMTP?
> If they understood REST I think that they would choose HTTP. Better
> applications can be built if you model data elements and processes as
> resources rather than endpoints.

That's nuts.  Then you not only have to write
software you have to invent a whole new
protocol!!!  In particular, you have to
rewrite RFC2821(SMTP) to ride on top of HTTP.

Thats a major PITA!

(That being said, I think SMTP could be
substantially improved and would love it if
someone were willing to do so and could get it
widely deployed)

> If you're building a *new* application
> then you need to write the software on the client and server sides
> anyhow. We all know how little effort it takes to put HTTP on the client
> side. I've shipped products with HTTP servers written in four different
> languages.

Writing a dumb SMTP server is pretty straightforward too.  BFD.

> > > If you want a web interface then you can use a POST form.
> >
> > See my reply to MB.  This is not modeling the
> > application in terms of resources.  It is RPC.
>
> I don't know why you say it is RPC. The definition in my mind of RPC is
> that the incoming message has a tag or identifier that instructs the
> server what to do with it. But this "endpoint" resource would have one
> and only one task. It would expect the input to be appropriate for that
> task.

Then your definition of RPC is incoherent.
Suppose that XML-RPC were modified so that the
method name appeared in the URL rather than the
body, would it stop being RPC?

Terrorist_or_not.com passes two arguments to a
procedure on the server and that procedure returns a
value.

You cannot intepret the interaction as anything
like either reading, writing, or appending to a
file.

> > Returning a URL and then asking the client to
> > watch the new URL seems like a lot of overhead and
> > waste.
>
> No, it is just a separation of concerns. Yes it takes more round-trips
> than the SMTP system. It is also much more functional. The client can
> check for status whenever it wants. Other clients can be attached to the
> *same* computation because it is a first-class resource. Clients can
> share information about what computations they are watching by sharing
> the URI. Disconnected clients have the option of polling which they do
> not with SMTP (unless there is a mailbox intermediary).

Nothing prevents the server from returning a
status URL AND commiting to deliver via email.
Then you get the best of both worlds, anyone can
check status and still no polling.

Your point about disco clients is just insane.
Have you heard of SMTP relay?

> > Good argument, but the polling is ugly.  A
> > callback system is much nicer and much ligher on
> > system resources!
>
> The point is that the same system could support *both*. This would be
> much harder to do with SMTP.

I am not objecting to supporting both!  My
contention is simply that using HTTP only
precludes callbacks.

As I said before, sometimes you want something
other than HTTP.  Sometimes you want something
other than REST.

> > > Conventions for asyncronous notification are here:
> > >
> > >  * http://www.prescod.net/HTTP_event_conventions.html
> >
> > Ok.  So that is another new protocol.  It is not
> > real life HTTP.
>
> If I use XHTML or RSS am I using XML? It is real life HTTP up until the
> point that where I start doing things against the HTTP model such as
> inventing private namespaces or telling the server what to do through
> method names or using POST for logical queries.

Terrorist_or_not.com uses POST for logical
queries?  Is that a problem?  How would you solve
it?

My general point is that you are defining a new
protocol on which endpoints have to have made
"a priori agreement" (to use MBs words).

Since endpoints do not yet understand WATCH,
CHANGED, DELETED, etc, you are not talking about
HTTP.  You are inventing a new protocol.

Your argument is like saying that HTTP is not a
new protocol because it already uses TCP/IP.

> > ... It also seems no better than just
> > sending a reply-to in the first place.
>
> If you just send a reply-to then the client and server have no mutually
> visible resource that represents the transaction. That means that the
> client can't monitor it. The client can't cancel it. You could invent
> some kind of UUID system but now you're inventing a private namespace.

Again, if it is important to have monitoring, you
can also send a location header that points to the
request status (which is what RFC2616 actually
says to do!).  Again, I'm not objecting to
monitoring.  I am objecting to polling.

To be clear both to you and to Mike.  I am
objecting to polling and to the work involved in
reinventing the wheel on asynch.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:297
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 19:54:31
Subject:Re: [rest-discuss] Reliable HTTP
Message:

On Fri, 25 Jan 2002, Paul Prescod wrote:
> > Even if with a single client.  The server is not
> > guaranteeing to process messages in any order at
> > all!
> >
> > Assuming the server issues sortable message ids,
> > and the client sends them in order.  How should
> > the server handle recieving:
> >
> >   RPOST 4 Jane
> >   RPOST 2 Tarzan
> >   RPOST 3 You
> >   RPOST 1 Me
>
> Why would a single client CHOOSE to send the messages in the wrong
> order????

I am saying that:
1. your spec does not specify that the client
should use message IDs in any particular order.
2. even if it did and clients sent message-IDs in
that order, there is no guarantee that the server
would recieve them in that order
3. even if the server did recieve them in order,
there is no guarantee that it processes them in
order.

For example,
suppose the client does RPOSTs to four load
balanced intermediaries.  None of the
intermediaries can reach the endpoint so they just
ping away until they get a connection.  Once they
get a connection, there is no reason to assume
that the server recieve the messages in any
particular order.

Note, there is also no mechanism to feedback error
messages if delivery fails.  You are so into
status notification, w/r/t terrorist_or_not.com.
You seem not to care about delivery failure here.
SMTP takes care of delivery failure.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:298
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 19:59:32
Subject:Re: [rest-discuss] Reliable HTTP
Message:

On Fri, 25 Jan 2002, Paul Prescod wrote:
> I guess we have a different definition of reliable. I mean that the
> message gets through. I consider ordering issues to be orthogonal. Part
> of the web zen is loose coupling between components. If responsibility
> for ordering can be pushed off completely onto the client then I think
> it should be.

It can't be.  You need to handle it.  See my prior
message on this.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:299
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 20:06:48
Subject:Re: [rest-discuss] Reliable HTTP
Message:

On Fri, 25 Jan 2002, Paul Prescod wrote:
> > You might want to call the protocol Reliable
> > Delivery of POST requests.  But even then, you
> > still need a semantic for delivery failure (which
> > MAY happen).
>
> The client will know if it failed to deliver. How coud the protocol
> help? You want an HTTP server to report to an HTTP client that the
> network cable is unplugged?

Well SMTP notifies senders of delivery failure.
How does RPOST work w/r/t proxies?
Is your assumption that the client keeps a socket
open until a connection happens?

This seems ugly.  I don't see why you don't just
want to use SMTP which already takes care of these
problems.

-Alex-


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:300
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 20:14:19
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:
> 
> ...
> 
> !!!!What is most of the recent discussion about!?
> In contrast, here is a short version of "reliable
> delivery" using SMTP:
> 
>    Send the message to the address using SMTP.

I don't claim to be an SMTP expert but I find that very hard to believe.

What happens if a network outage occurs such that the server believes
that it received a complete message and properly closed the session but
the client does not know that the session was considered closed. Or vice
versa. SMTP has the same issue that HTTP does and I see nothing in the
SMTP spec to indicate that there is a way to recognize that the client
is retry-ing the send.

            S: MAIL FROM:<Smith@...>
            R: 250 OK

            S: RCPT TO:<Jones@...>
            R: 250 OK

            S: RCPT TO:<Green@...>
            R: 550 No such user here

            S: RCPT TO:<Brown@...>
            R: 250 OK

            S: DATA
            R: 354 Start mail input; end with <CRLF>.<CRLF>
            S: Blah blah blah...
            S: ...etc. etc. etc.
            S: <CRLF>.<CRLF>
            R: 250 OK

> Here is a short version of asynchronous callbacks
> using SMTP:
> 
>    Send the message to the reply-to address using SMTP

You can do the same in HTTP. Just return a reply-to address. *BUT*.
*BUT*. *BUT*. The part you're missing is that we are trying to identify
what makes the web such a great, scalable, interoperable, popular system
and extend that into the domain of asynch, events, etc. reply-to is
trivial. But what if you want to say that you DON'T want the reply any
more? What if you want to have a centralized list of the things you are
expecting replies about? If you haven't given the reply-request a URI
then you can't do these things.

>...
> 
> Terrorist_or_not.com uses RPC to deliver the
> queries.  The target of the POST is a function not
> a resource.

That is not the definition of RPC. What's wrong with a function being a
resource? It becomes RPC when the function starts dispatching on method
names and setting up private namespaces.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:301
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 20:23:40
Subject:Re: [rest-discuss] Reliable HTTP
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> Well SMTP notifies senders of delivery failure.

You're talking about *relaying* failures. Not *protocol* failures. It's
a totally different problem.

> How does RPOST work w/r/t proxies?

Do you mean proxies or relays? A proxy's job is to pretend it doesn't
exist.

Relays: Unrelated. Totally different problem. Part of the virtue of REST
is that you assemble systems from logical components. 

> Is your assumption that the client keeps a socket
> open until a connection happens?

??? We're talking about delivery of *one* message. Of course I expect it
to keep a socket open if it can. But if it can keep a socket open then
why is it having trouble delivering the message?

> This seems ugly.  I don't see why you don't just
> want to use SMTP which already takes care of these
> problems.

Because it doesn't.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:302
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 20:32:49
Subject:Re: [rest-discuss] Reliable HTTP
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 1. your spec does not specify that the client
> should use message IDs in any particular order.

If the client is happy with out of order delivery, so should the server
be.

> 2. even if it did and clients sent message-IDs in
> that order, there is no guarantee that the server
> would recieve them in that order

If I open a TCP connection to machine X and send a message, that message
has, by definition, arrived before any other messages I send.

> 3. even if the server did recieve them in order,
> there is no guarantee that it processes them in
> order.

If the server application needs to care about order then it should
syncronize them. If it doesn't, it shouldn't. 

> For example,
> suppose the client does RPOSTs to four load
> balanced intermediaries. 

Now you're bringing in intermediaries. Clients do not typically do load
balancing. Servers do load balancing. If a client wants to set up a
system to do load balancing using intermdiaries then it needs to find a
way to syncronize them. If a particular REST server wants to provide
message ordering to the clients as a feature then fine, it can do that.
I'm not going to put something in the spec that is only useful to a tiny
percentage of all users.

> ...  None of the
> intermediaries can reach the endpoint so they just
> ping away until they get a connection.  

The client made a mistake sending time-ordered messages over
intermediaries that are not synchronized.

>...
> Note, there is also no mechanism to feedback error
> messages if delivery fails.  

We're back into this zone where you are talking about relaying and I
haven't mentioned it. If you want to define a spec for reliable delivery
of HTTP messages over *relays* then go ahead. That's a totally different
problem.

In any client/server protocol (including SMTP) it makes no sense to try
and give feedback that there is a problem at the TCP layer. "It looks
like my packets aren't getting through to you. I just thought you should
know."

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:303
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-25 20:55:17
Subject:RE: [rest-discuss] security of callbacks
Message:

> It looks like
> you are in fact reifying the whole notion of a response.  I'm not
> sure how that
> could be useful.

I am saying that the sink API should do nothing but reify the whole notion of a
response.  It should have the same capabilities, no more, no less.  If there are
capabilities needed beyond that the implementation of choice should be requests
performed by the sink.  If there are capabilities that have to be in the sink
API then they have a high burden of proof WRT security.

For example, we can say a priori that the sink accepting mime headers is not a
new security risk, but we can't say the same about the sink doing Kerberos
authentication.

> > Expiration is the inverse of caching,
>
> I don't think so.  The expiry we're talking about is expiration of the
commitment on the part of the source to notify the sink.  That commitment is the
subscription abstraction, and can and probably should be reified.  Expiration
defines a sort of TTL for an instance of that subscription abstraction.
(Actually, Expiration should probably be expressed as TTL rather than any
absolute date or time construct.)


The only parts of the sink API that should address caching are reply headers
related to caching.  There's not much relevant there, so this is moot.  Because
of that we can make a affirmative statement that the sink API is not the place
to address expiration.

- Lucas







-----------------------------------------------------------------------------------
Post ID:304
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 20:57:56
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> That's nuts.  Then you not only have to write
> software you have to invent a whole new
> protocol!!!  

There is nothing wrong with inventing a new protocol to solve new
problems or to solve old problems better.

> .. In particular, you have to
> rewrite RFC2821(SMTP) to ride on top of HTTP.

Well, millions of people access their email through HTTP (with or
without HTML). And millions of people do File Transfers without the File
Transfer Protocol. So I don't see why SMTP will remain immune to the
onslaught of HTTP.

But anyhow, we're talking about inventing new protocols anyhow. If
you're sending purchase orders over SMTP and you have complex workflows
etc., you are inherently inventing a new protocol. Here's what an essay
I am writing says:

<p>There is a subtlety here: people think that they can get network
effects by switching from HTTP to SMTP (e.g. for asychronous
messaging). Of course there is some truth in this. If you were writing
an email client today it would not make sense to support HTTP instead
of SMTP. That's simple support for a legacy code base -- like
supporting CICS.

<p>On the other hand, if you were developing a new application
then the network effects in SMTP's favour are not so strong. Getting
bits from one machine to another asynchronously is the least of your
problems in a complicated buzzword-compliant, secure, work-flow based
business-to-business application. The hard problems involve security
and accountability. And those hard problems are easier solved with a
universal addressing mechanism like the one built into HTTP.

<p>People
believe that SMTP is great because it allows asynchronous notifications
but KnowNow has shown how a few hundred bytes of JavaScript can
implement peer-to-peer asynchronous notifications using HTTP. Would an
SMTP solution be any smaller or simpler?

>...
> > If you're building a *new* application
> > then you need to write the software on the client and server sides
> > anyhow. We all know how little effort it takes to put HTTP on the client
> > side. I've shipped products with HTTP servers written in four different
> > languages.
> 
> Writing a dumb SMTP server is pretty straightforward too.  BFD.

Right. So choosing based on what server you have hanging around makes no
sense. You should choose based on which will help you to model your app
in the most flexible, scalable, extensible, secure, reliable way. HTTP
has URIs. They allow all of that stuff. SMTP does not. It makes that
stuff really hard.

>...
> Then your definition of RPC is incoherent.
> Suppose that XML-RPC were modified so that the
> method name appeared in the URL rather than the
> body, would it stop being RPC?

It depends? Are they setting up private namespaces in the parameters? Or
are all parameters either URIs or resource representations?

>...
> > No, it is just a separation of concerns. Yes it takes more round-trips
> > than the SMTP system. It is also much more functional. The client can
> > check for status whenever it wants. Other clients can be attached to the
> > *same* computation because it is a first-class resource. Clients can
> > share information about what computations they are watching by sharing
> > the URI. 
> 
> Nothing prevents the server from returning a
> status URL AND commiting to deliver via email.

Fine. Now you are starting to make your solution more complex so that it
starts to resemble mine in scope and features. How does your client
cancel the request if it realizes that the computation is wasted?

>...
> Your point about disco clients is just insane.
> Have you heard of SMTP relay?

Can you read?

> > Disconnected clients have the option of polling which they do
> > not with SMTP (unless there is a mailbox intermediary).

SMTP relay *is* the mailbox intermediary. Sometimes polling is a better
solution. That's why POP uses it. My solution allows polling *and*
direct notification *and* intermediated queued notification. And as a
new RESTer pointed out it would be easy to add server-queued
notification.

>...
> > The point is that the same system could support *both*. This would be
> > much harder to do with SMTP.
> 
> I am not objecting to supporting both!  My
> contention is simply that using HTTP only
> precludes callbacks.

I have no idea what you're saying. How can using HTTP preclude
callbacks?

> ...
> > If I use XHTML or RSS am I using XML? It is real life HTTP up until the
> > point that where I start doing things against the HTTP model such as
> > inventing private namespaces or telling the server what to do through
> > method names or using POST for logical queries.
> 
> Terrorist_or_not.com uses POST for logical
> queries?  Is that a problem?  How would you solve
> it?

If you want asynch then you are involving server state, so you need to
use POST. 

> My general point is that you are defining a new
> protocol on which endpoints have to have made
> "a priori agreement" (to use MBs words).

Call it a new protocol. What does it matter? Terrorist.com is going to
require a new "protocol" in some sense regardless. Especially if you set
up a status URI then you are setting up a protocol that spans *two
other* protocols.

We're going to take the "common problem" of asynch notifications and
develop standard conventions. If you want to call that a new protocol
then that's okay too. As longas we don't abuse HTTP as POSTing
getStateName does, then what does it matter what we call it?

The point is that everything that is already in HTTP is basically
*right* and we are building on it, rather than working around the flaws
in it.

>...
> Your argument is like saying that HTTP is not a
> new protocol because it already uses TCP/IP.

Are cookies a new protocol? Or an extension to HTTP? 

>...
> To be clear both to you and to Mike.  I am
> objecting to polling and to the work involved in
> reinventing the wheel on asynch.

Polling is just an option. Not a requirement. HTTP asych does not
require polling. 

Reinventing the wheel is necessary if we want to bring asnch to the web.
SMTP has no concept of URI. Therefore it is not web aware. That isn't
surprising since it predates the web. This is a big limitation that
makes it infeasible for many applications. Asynch HTTP is not an option.
It is something that needs to happen. Whether you use it for your
application or not is up to you.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:305
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-25 21:15:43
Subject:RE: [rest-discuss] Reliable HTTP
Message:

> If the client is happy with out of order delivery, so should the server
> be.

This is way too far head.  In-order delivery is a real issue, but a RESTy
solution isn't even a possibility until notifications are doable.








-----------------------------------------------------------------------------------
Post ID:306
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 21:23:41
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, Jeff Bone wrote:
> > !!!!What is most of the recent discussion about!?
>
> How to *use HTTP* --- not how to fill in the holes.  It's a subtle point.

HTTP uses TCP/IP.  It does not fill in holes.
Please clarify your point?

> (d) If you're using HTTP to do RPCs, you aren't using HTTP

Uhm.  So, SOAP and XML-RPC aren't using HTTP?

> > I think the format of the POST should me
> > multipart/form-data.  XML-RPC folks prefer XML-RPC
> > and SOAP people prefer SOAP envelopes.
> > These are all RPC.
>
> I think Mark's perspective --- certainly my own perspective --- is that the
> XML-RPC and SOAP communities and the RPC-oriented "web services" efforts that we
> see all over the place today

blah blah blah.  I think most web apps (of
which terrorist_or_not.coom is an example) are
RPC.  The issue here is whether they are or
aren't.

The other RESTers here seemed to have no problem
with the overall design of posting
multipart/form-data to some URL.

I just fail to see why that is REST.
I think you and I agree that it isn't.  Perhaps
if you explain why to Mark and Paul, they will
understand it better than if I do. ;-)

> > If you do, explain how to make
> > terrorist_or_not.com non-RPC and why it would be
> > better that way.
>
> I'll take that challenge.  Next message.

Looking forward.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:307
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 21:41:41
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:

> HTTP uses TCP/IP.  It does not fill in holes.
> Please clarify your point?

Forget it, I'm lost, you're lost, we're all off in the weeds.  Next point.

> > (d) If you're using HTTP to do RPCs, you aren't using HTTP
>
> Uhm.  So, SOAP and XML-RPC aren't using HTTP?

It may be possible to use SOAP with HTTP --- Mark's got a better read on the current
state of that effort (keeping SOAP from becoming unavoidably RPC-based) than I do.
It's almost certainly *not* possible to use XML-RPC with HTTP without breaking HTTP.
I.e., if you use e.g. XML-RPC, you aren't using HTTP, you're tunneling RPCs through
HTTP.

> blah blah blah.  I think most web apps (of
> which terrorist_or_not.coom is an example) are
> RPC.  The issue here is whether they are or
> aren't.

I don't have any issue here.  I think you're probably right --- most probably are.
But that doesn't really say anything except that most developers don't really
understand HTTP, and it's easier for them to superimpose their own procedural or OO
view of the world on top of HTTP.

> The other RESTers here seemed to have no problem
> with the overall design of posting
> multipart/form-data to some URL.

I'm lost again.  I don't have any problem with the idea of posting any particular kind
of data to some URL, cf. my own example.

> I just fail to see why that is REST.

It's REST because it's HTTP.  That's what POST *is for,* per the HTTP spec.

> I think you and I agree that it isn't.  Perhaps
> if you explain why to Mark and Paul, they will
> understand it better than if I do. ;-)

Mark and Paul aren't objecting to the use of POST in this fashion per se, AFAICT.
Perhaps they could comment.  I find it hard to see why they would.  I suspect that
you're failing to understand their objections.

jb








-----------------------------------------------------------------------------------
Post ID:308
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 22:20:07
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

Jeff Bone wrote:
> 
>...
> 
> Mark and Paul aren't objecting to the use of POST in this fashion per se, AFAICT.
> Perhaps they could comment.  I find it hard to see why they would.  I suspect that
> you're failing to understand their objections.

I'm lost too. The most important thing is that you don't start setting
up private naming schemes in parameters. That's when you start going off
into the RPC weeds.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:309
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 22:32:13
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, Paul Prescod wrote:
> There is nothing wrong with inventing a new protocol to solve new
> problems or to solve old problems better.

Remember worse is better.

> > .. In particular, you have to
> > rewrite RFC2821(SMTP) to ride on top of HTTP.
>
> Well, millions of people access their email through HTTP (with or
> without HTML). And millions of people do File Transfers without the File
> Transfer Protocol. So I don't see why SMTP will remain immune to the
> onslaught of HTTP.

You are talking about user-agents, not MTAs or
relays.

> But anyhow, we're talking about inventing new protocols anyhow. If
> you're sending purchase orders over SMTP and you have complex workflows
> etc., you are inherently inventing a new protocol.

Only if you think any use of an HTTP endpoint is a
protocol.  If I send POs over SMTP and they get
sent back approved or rejected, I am defining
something that endpoints are doing.  I am not
inventing a new transport protocol.

>  Here's what an essay
> <p>There is a subtlety here: people think that they can get network
> effects by switching from HTTP to SMTP (e.g. for asychronous
> messaging). Of course there is some truth in this. If you were writing
> an email client today it would not make sense to support HTTP instead
> of SMTP. That's simple support for a legacy code base -- like
> supporting CICS.

The same is true of the presence application.  You
know the joke about the creationist talking to the
programmer.  The creationist said: God created the
world in 6 days.  The Programmer responded "Yeah,
thats because he didn't have an installed base"

You reuse what is available and have to be
compatible.

> <p>On the other hand, if you were developing a new application
> then the network effects in SMTP's favour are not so strong. Getting
> bits from one machine to another asynchronously is the least of your
> problems in a complicated buzzword-compliant, secure, work-flow based
> business-to-business application. The hard problems involve security
> and accountability. And those hard problems are easier solved with a
> universal addressing mechanism like the one built into HTTP.

Asynchronous delivery may be one of your  problems
and SMTP does a decent  job.  And if your project
is that big, I think you would rather reuse SMTP
than invent a new asynch protocol just for your
project.  The hard problems of security and
accountability are orthogonal issues.

> <p>People
> believe that SMTP is great because it allows asynchronous notifications
> but KnowNow has shown how a few hundred bytes of JavaScript can
> implement peer-to-peer asynchronous notifications using HTTP. Would an
> SMTP solution be any smaller or simpler?

If you have a fixed set of players then perhaps
KnowNow is the best solution.  But I don't think
you want every party to be permanently connected
to every other just to recieve messages.

I do think you may want to interop with
organizations that do not use KnowNow.

Where is the KnowNow RFC?

> Right. So choosing based on what server you have hanging around makes no
> sense. You should choose based on which will help you to model your app
> in the most flexible, scalable, extensible, secure, reliable way. HTTP
> has URIs. They allow all of that stuff. SMTP does not. It makes that
> stuff really hard.

When you want asynchronous messaging, use SMTP.
When you want synchronous tracking, use HTTP.
These are orthogonal.

> > Then your definition of RPC is incoherent.
> > Suppose that XML-RPC were modified so that the
> > method name appeared in the URL rather than the
> > body, would it stop being RPC?
>
> It depends? Are they setting up private namespaces in the parameters? Or
> are all parameters either URIs or resource representations?

Obviously function names in URLs are private
namespaces because URLs are opaque.

All parameters are not URIs.  They are form-data
delivered via HTTP post.

You know all this.  You are avoiding the issue.

> > Nothing prevents the server from returning a
> > status URL AND commiting to deliver via email.
>
> Fine. Now you are starting to make your solution more complex so that it
> starts to resemble mine in scope and features. How does your client
> cancel the request if it realizes that the computation is wasted?

My initial spec didn't require the tracking
that you seem to want.  You kept expanding the
scope of my spec to justify your features.

If we want computation cancelation, then perhaps
we return a location header with the 202.  But, if
we want to support users with web browsers
(CICS!), we should really return the location of a
form in the body that will allow the user to
inquire.  The location of the target is irrelevant
in such a case.

> >...
> > Your point about disco clients is just insane.
> > Have you heard of SMTP relay?
>
> Can you read?

I can.  Can you?  Here is what RFC2821 says:

   As discussed above, when the SMTP server receives
   mail from a particular host address, it could
   activate its own SMTP queuing mechanisms to
   retry any mail pending for that host address.

In other words.  When a disco client reconnects,
it can just (mail) ping the server to get
messages.  It doesn't ping unless it has been
disco for a while so this is a very different type
of polling.

> > > Disconnected clients have the option of polling which they do
> > > not with SMTP (unless there is a mailbox intermediary).
>
> SMTP relay *is* the mailbox intermediary. Sometimes polling is a better
> solution. That's why POP uses it. My solution allows polling *and*
> direct notification *and* intermediated queued notification. And as a
> new RESTer pointed out it would be easy to add server-queued
> notification.

No.  Your solution requires the client to poll
even when it has been connected.   With SMTP the
client may choose either to get direct
notification or to poll (in which case
it supplies the polling server!).

Your solution requires the application server to
bear the cost of operating a polling server and
the client to poll repeatedly.

> > I am not objecting to supporting both!  My
> > contention is simply that using HTTP only
> > precludes callbacks.
>
> I have no idea what you're saying. How can using HTTP preclude
> callbacks?

Because the server has no way to back contact the
client. It has to wait for the client to
reconnect.

You can of course propose a new protocol by which
the client supplies a URL to which the server
should POST the result, but that is a new
protocol and you have yet to show why that
mechanism is a better protocol (for example it
has no reliability!).

> > ...
> > > If I use XHTML or RSS am I using XML? It is real life HTTP up until the
> > > point that where I start doing things against the HTTP model such as
> > > inventing private namespaces or telling the server what to do through
> > > method names or using POST for logical queries.
> >
> > Terrorist_or_not.com uses POST for logical
> > queries?  Is that a problem?  How would you solve
> > it?
>
> If you want asynch then you are involving server state, so you need to
> use POST.

You are evading the issue.  Simple
terrorist_or_not.com does not require asynch, but
still must use POST for logical queries.

> > My general point is that you are defining a new
> > protocol on which endpoints have to have made
> > "a priori agreement" (to use MBs words).
>
> Call it a new protocol. What does it matter? Terrorist.com is going to
> require a new "protocol" in some sense regardless. Especially if you set
> up a status URI then you are setting up a protocol that spans *two
> other* protocols.

Your missing the point.  Terrorist.com is just an
application.  A new user doesn't have to set up
anything new to use it.  She simply opens up a web
browser, adds 2 image files to the form and a
reply-to email address.

The server either gives her an immediate answer or
tells her that it is too busy and that it
will send her the the answer when it gets to it.
In the meantime, she can update/check status at
*this* location.

In contrast, your solution would require her to
set up a special HTTP server to recieve the
callback using a new callback HTTP protocol.

> We're going to take the "common problem" of asynch notifications and
> develop standard conventions. If you want to call that a new protocol
> then that's okay too. As longas we don't abuse HTTP as POSTing
> getStateName does, then what does it matter what we call it?

Look.  If you want to develop a protocol
called HTTP-MTP, thats fine.  Just realize that
you are competing head-on with SMTP without
offering any majorly visible advantages.

Any any advantages you do get, might be better
achieved through evolutionary improvement in SMTP.

> The point is that everything that is already in HTTP is basically
> *right* and we are building on it, rather than working around the flaws
> in it.

If HTTP is so right, talk to me about the lack of
logical queries with large bodies?

> > Your argument is like saying that HTTP is not a
> > new protocol because it already uses TCP/IP.
>
> Are cookies a new protocol? Or an extension to HTTP?

I believe they are defined by a different RFC.  In
particular, supporting HTTP does not enail
supporting cookies.

> > To be clear both to you and to Mike.  I am
> > objecting to polling and to the work involved in
> > reinventing the wheel on asynch.
>
> Polling is just an option. Not a requirement. HTTP asych does not
> require polling.

Polling is necessary unless you invent a new HTTP
asynch delivery protocol.

> Reinventing the wheel is necessary if we want to bring asnch to the web.

I don't see you as bringing asynch to the web. The
issues are all orthogonal.

> SMTP has no concept of URI. Therefore it is not web aware.

Show me something you want to do that requires a
change in SMTP?  There is no reason you can't have
SMTP servers also expose an HTTP server in which
you inquire about message-ids it has delivered,
but that is irrelevant to the actual delivery of
messages.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:310
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 21:29:26
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:


"S. Alexander Jacobson" wrote:

> Terrorist_or_not.com passes two arguments to a
> procedure on the server and that procedure returns a
> value.
>
> You cannot intepret the interaction as anything
> like either reading, writing, or appending to a
> file.

You *absolutely* can.  Consider Plan 9:  its networking mechanism presents a
set of services which look like files:  they can be opened, read, written to
etc. to communicate with the services in question.  For e.g. name resolution,
the client opens a file (something like) /net/cs (i.e., "connection server" is
reified as a "file") writes a string like "www.foo.com", then reads the file
contents back to receive something like "209.224.18.5".  That is *just like*
what you're describing above, with the exception that you're only passing a
single parameter.  (Other Plan 9 services accept multiple "parameters" in this
fashion.)

> As I said before, sometimes you want something
> other than HTTP.  Sometimes you want something
> other than REST.

This is really getting old, Alex.  Sigh.  Mark, let me say now how very sorry
I am for having put you through this, now that I see how it looks from the
other side of the fence.  ;-)

jb







-----------------------------------------------------------------------------------
Post ID:311
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 21:29:17
Subject:REST Terrorist-Or-Not, and Alex's Objections / Issues
Message:


"S. Alexander Jacobson" wrote in various places:

> Using MIME-RPC over HTTP, you would POST either
> a list (multipart/mixed), or a struct
> (multipart/form-data) to some URL (e.g.
> terroristornot.com/verify).

> In other words, [in the REST version, the app] is making an idempotent
> request.  Accoding to REST, the client should use
> GET for such a a request, but I don't know how you
> send two pictures using GET.  So I'm not sure you
> can use REST.

> You cannot sanely do this with GET, therefore I
> think you cannot sanely do this with REST.

IMO, the issue of idempotence --- what it means in what contexts, which methods are
guaranteed to be truly idempotent vs. which ones *may* be idempotent ---- is one of
the less well-understood aspects of the Web.  The Web (its protocols and
technologies) is a work-in-progress, one that's evolving from a rather informal
origin to more a more formal definition.  The claim that *no* idempotent operation
should be performed by a method other than GET is a bit suspect, as you point out.
And idempotent operations which carry content might be deserving of another method.

I do agree that you cannot use GET alone to do Terrorist-Or-Not in a practical
fashion.  Whether or not this means that you can't build it in a RESTful fashion
depends on how literally you want to interpret certain utterings of e.g. TBL. ;-)

I don't, however, think this means that you have to ditch resource modeling (rather
than procedural API exposure) or the HTTP protocol.  It just means you have to
think about how to do it within the framework provided.

Went back and looked at Mike's suggestion;  it's generally fine with the caveat
that yes, it results in two separate request / response cycles.  I didn't see what
your particular objection to it was, other than perhaps that.  If there's an issue
with that, you can always collapse that into a single request-response cycle.  In
other words, the more concise version of Mike's solution would (with some minor
name changing just to make me happy ;-) simply be:

(request) ==>
POST http://www.terrorist_or_not.com/terrorists/checker HTTP/1.1
Content-Type: mulitpart/related

--- image 1 ---

--- image 2 ---

<== (response)
200 OK

<suspect>
 <status>verified</status>
 <category>terrorist</category>
 <details>http://www.terrorist_or_not.com/terrorists/123456</details>
</suspect>

There's no reason why the thing that checks terrorists can't be reified as a
resource with a generic interface that obeys the semantics of HTTP methods.
Indeed, the above kind of thing is exactly what POST is for.  The Response could be
XML, or HTML, or some MIME encoding, or whatever;  that's up to the app, and REST /
HTTP has no particular preference.  It might be possible to leverage other HTTP
response codes to expose *more* of the application's semantics to HTTP, but the
above is entirely valid.  (E.g. it might return a 202 Accepted and indicate a
Location: to retrieve the current status of the query from, segueway to...)

Now your next objection will be that in some cases the verification process may
take too long for a single HTTP request-response cycle.  In that case, the service
would simply create a resource for the pending query and return that as the
Location: in a 202 Accepted response.  The client would then poll that resource to
get the status of the query.

Your *next* objection will be that polling is undesirable.  Well, that's certainly
true.  Asynchrony of requests and responses from the perspective of a particular
application is often desirable.  That's what we've been talking about:  different
mechanisms to build asynchronous communication patterns atop HTTP without breaking
the semantics of HTTP.  The problem isn't that it's impossible, it's that there are
many different ways to go about this.  What's needed isn't a new protocol or new
standard, its a set of generic conventions and guidelines.

Your next objection will be that HTTP is unreliable (as in guaranteed delivery.)
That's true.  But them's the hard facts, main.  If you really believe that our SMTP
fabric is reliable in that sense, I want some of what you're smoking. ;-)  In any
case, there's no reason to believe either is or can be absolutely more reliable
than the other.  The main objection to duplicating SMTP's messaging functionality
in HTTP is that it's redundant;  the best argument for it is that it unifies the
space of addressable things and their interfaces, and that has positive
implications for integration and Metcalfe-value.

Per reliable ordered delivery, that's a Hard Problem in a distributed setting ---
as you're clearly aware.  Neither HTTP nor SMTP does or *can* solve the problem
without extensive work.  Solutions to the general problem such as ISIS (Ken
Birman's reliable ordered multicast / group communication toolkit from over a
decade ago) provide solutions but are generally too expensive for most apps.
Happily, most distributed apps can easily sacrifice globally consistent message
delivery order, etc. in favor of weaker consistency / better performance.

Bottom line, you've been offered a variety of solutions, etc. to your
"terrorist-or-not" problem and related issues;  whether you accept them is up to
you.  I still haven't seen any single point you've raised that addresses Mark
Baker's fundamental challenge, which is

   "Show me an application that I can't do with HTTP."

He posed that challenge to me a while back, and I haven't been able to come up with
a single good answer.  There are things that can be done more effectively if HTTP
is extended, but in general there are very few of these.  (As mentioned, a system
which uses the resource space as a kind of generative communication space ala Linda
would benefit greatly from an atomic GET+DELETE operation;  most of the extensions
that really do make sense are those that guarantee atomicity for various
combinations of existing methods.)

jb












-----------------------------------------------------------------------------------
Post ID:312
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-25 22:44:36
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:


"S. Alexander Jacobson" wrote:

> On Fri, 25 Jan 2002, Paul Prescod wrote:
> > There is nothing wrong with inventing a new protocol to solve new
> > problems or to solve old problems better.
>
> Remember worse is better.

I absolutely buy "worse is better."  (BTW, Dick Gabriel was on my technical
advisory board at my last play, Activerse.)  What you're failing to understand is
that "worse is better" favors HTTP. :-)

> You are talking about user-agents, not MTAs or
> relays.

He's talking about the overall functionality --- the "what," not the "how."  His
point is that the particular underlying machinery is in some sense non-essential
to the problem domain --- it's the "how," not the "what."

Ugh.  We have gone way beyond the point of diminishing returns on this one.

jb








-----------------------------------------------------------------------------------
Post ID:313
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 22:40:08
Subject:Re: [rest-discuss] Reliable HTTP
Message:

Ok, so you want the client to accumulate a queue
of RPOSTs and only RPOST follow-on messages after
prior ones have been sent sucessfully.

Fine.  I thought you would let clients spin out a
thread for each RPOST.

Then my only other major comment is that you
should let clients generate message-ids and avoid
the extra round-trips.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:314
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-25 23:22:05
Subject:Re: [rest-discuss] REST Terrorist-Or-Not, and Alex's Objections / Issues
Message:

>
> The claim that *no* idempotent operation
> should be performed by a method other than GET is a bit suspect, as you
point out.
> And idempotent operations which carry content might be deserving of
another method.

>
> I do agree that you cannot use GET alone to do Terrorist-Or-Not in a
practical
> fashion.  Whether or not this means that you can't build it in a RESTful
fashion
> depends on how literally you want to interpret certain utterings of e.g.
TBL. ;-)

I think TBL revised his wording on this in light of HEAD and PUT being
idempotent:
http://lists.w3.org/Archives/Public/www-tag/2002Jan/0076.html








-----------------------------------------------------------------------------------
Post ID:315
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-25 23:23:07
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

>
> Ugh.  We have gone way beyond the point of diminishing returns on this
one.
>
It's time to retire to our respective corners and come back out with working
code.







-----------------------------------------------------------------------------------
Post ID:316
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 21:16:38
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

Ok.  Capacity argument on the presence server
conceded.

Not conceding the capacity argument on asynch
messaging.  You don't want thousands of clients
polling asking "is it ready yet?".  And you don't
want an email system in which every party has
to hold open a connection to every other party.

-Alex-

On Fri, 25 Jan 2002, Mark Nottingham wrote:

>
> On Fri, Jan 25, 2002 at 08:41:52AM -0500, S. Alexander Jacobson wrote:
> >
> > Yeah. Me too.  How many chat clients can your web
> > server support?  According to (1), a typical test
> > Apache server can handle ~250 requests per second.
> > Assuming your clients poll once per second, you
> > max out at 250 simulatenous clients.  That sucks!
> [..]
> > (1) http://www.acme.com/software/thttpd/benchmarks.html
>
> Err, that's hits per second, not concurrent connections. You're using
> a benchmark of Apache by an Apache competitor as an indication of how
> all Web servers perform in general? Tsk. It's widely acknowledged
> that Apache is performance-limited, in a trade-off for stability,
> developability, etc.
>
> Let me be more explicit: I know of at least two vendors who have HTTP
> implementations that can handle 50,000+ concurrent persistent
> connections on commodity hardware.
>
> It's much more instructive to look at intermediary implementations
> when you're talking about the performance overhead of HTTP; they're
> more optimised for performance, and they're not doing anything with
> the payload; it's all just overhead. It's relatively easy to achieve
> 1000+ reqs/sec [1]. Most modern HTTP intermediaries can approach or
> exceed wire speed.
>
> I'd note that these numbers don't include any of the larger
> commercial vendors (with more developed implementations) who
> participated in past years, but now don't want their numbers made
> public, as it starts a performance war...
>
>
> [1] http://www.measurement-factory.com/results/public/cacheoff/N04/raw.html
>
>
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:317
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-25 23:34:21
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

Ok, how about a new approach.

Let's say you and I each have an SMTP, FTP, and HTTP server on our
machines.  Without any further agreement between us, which one can be
used to do the most things?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:318
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 23:42:32
Subject:Re: REST Terrorist-Or-Not, and Alex's Objections / Issues
Message:

On Fri, 25 Jan 2002, Jeff Bone wrote:
> I do agree that you cannot use GET alone to do Terrorist-Or-Not in a practical
> fashion.  Whether or not this means that you can't build it in a RESTful fashion
> depends on how literally you want to interpret certain utterings of e.g. TBL. ;-)

Ok.  So idempotence is a red herring.  My general
judgement of this is that I think you shouldn't
rely on idempotence.  Every things should be
interpreted as a once-off (otherwise known as
linear types -- see
http://linux.rice.edu/~rahul/hbaker/Use1Var.html)

> I don't, however, think this means that you have to ditch resource modeling (rather
> than procedural API exposure) or the HTTP protocol.  It just means you have to
> think about how to do it within the framework provided.

Ok.  I guess I'm just not getting how posting two
images to a URL is resource modeling.

> There's no reason why the thing that checks terrorists can't be reified as a
> resource with a generic interface that obeys the semantics of HTTP methods.

Ok.  But that is true of every RPC server as well.
You send arguments to the server and it sends back
a result.

Suppose there was another argument, that had one
of two values: isTerrorist | isFed

Would that make it non-Restful?

> Your *next* objection will be that polling is undesirable.  Well, that's certainly
> true.  Asynchrony of requests and responses from the perspective of a particular
> application is often desirable.  That's what we've been talking about:  different
> mechanisms to build asynchronous communication patterns atop HTTP without breaking
> the semantics of HTTP.

I don't understand why SMTP doesn't do what you
want.  In particular SMTP doesn't look all that
different than HTTP with some new methods (MAIL,
RCPT, VRFY, etc.).  What do you get from replacing
SMTP?

If the point is simply that you want HTTP clients
to me able to talk to mail servers, why not simply
do the direct mapping described above?

> Your next objection will be that HTTP is unreliable (as in guaranteed delivery.)
> That's true.  But them's the hard facts, main.  If you really believe that our SMTP
> fabric is reliable in that sense, I want some of what you're smoking. ;-)

HTTP is inherently unreliable.  SMTP is only in
practice unreliable because the implementations
suck.  Talk to the folks at ironport about this.
If you want to know more.

> In any
> case, there's no reason to believe either is or can be absolutely more reliable
> than the other.  The main objection to duplicating SMTP's messaging functionality
> in HTTP is that it's redundant;  the best argument for it is that it unifies the
> space of addressable things and their interfaces, and that has positive
> implications for integration and Metcalfe-value.

Ok.  So the big bonus here is that my email
address is http://i2x.com/~alex rather than
alex@....  GETting this URL would retrieve my
homepage or some form of status information and
POSTing to it would send me an email.

Interesting, but I guess I just don't see so much
value there.

> Per reliable ordered delivery, that's a Hard Problem in a distributed setting ---

separate issue.

> Bottom line, you've been offered a variety of solutions, etc. to your
> "terrorist-or-not" problem and related issues;  whether you accept them is up to
> you.

They are all fine.  What I fail to get is what
exactly you don't like about RPC.

>  I still haven't seen any single point you've raised that addresses Mark
> Baker's fundamental challenge, which is
>
>    "Show me an application that I can't do with HTTP."

I answered this before.  My answer was show me
an application that you can't do with SMTP.
You should use what makes you feel comfortable and
model applications as messages sent between agents
:-).

And, you're right, transactional stuff is another
answer.  You don't really want to use HTTP to
interact with Oracle.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:319
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 23:40:20
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

Mark Baker wrote:
> 
> Ok, how about a new approach.
> 
> Let's say you and I each have an SMTP, FTP, and HTTP server on our
> machines.  Without any further agreement between us, which one can be
> used to do the most things?

Well it depends how they are configured. I'd guess it would have to be
wide open to do anything useful. Can you make a strong case that a wide
open HTTP server is more "powerful" than a wide open FTP server? Either
can PUT, GET, DELETE. And FTP servers have directories that you can
append to....

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:320
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 23:44:45
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, Jeff Bone wrote:
> > Uhm.  So, SOAP and XML-RPC aren't using HTTP?
>
> It may be possible to use SOAP with HTTP --- Mark's got a better read on the current
> state of that effort (keeping SOAP from becoming unavoidably RPC-based) than I do.
> It's almost certainly *not* possible to use XML-RPC with HTTP without breaking HTTP.
> I.e., if you use e.g. XML-RPC, you aren't using HTTP, you're tunneling RPCs through
> HTTP.

I don't see what the difference is between XML-RPC
and Mike's solution to the terrorist-or-not.com
problem.  One encodes with MIME, the other with
XML-RPC.

> > blah blah blah.  I think most web apps (of
> > which terrorist_or_not.coom is an example) are
> > RPC.  The issue here is whether they are or
> > aren't.
>
> I don't have any issue here.  I think you're probably right --- most probably are.
> But that doesn't really say anything except that most developers don't really
> understand HTTP, and it's easier for them to superimpose their own procedural or OO
> view of the world on top of HTTP.

You were making an argument about existence
proofs.  My point is that existence goes both
ways.

> > I just fail to see why that is REST.
>
> It's REST because it's HTTP.  That's what POST *is for,* per the HTTP spec.

XML-RPC uses POST too.  But you deny that it is
REST!

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:321
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 21:56:42
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, Paul Prescod wrote:
> > !!!!What is most of the recent discussion about!?
> > In contrast, here is a short version of "reliable
> > delivery" using SMTP:
> >
> >    Send the message to the address using SMTP.
>
> I don't claim to be an SMTP expert but I find that very hard to believe.

I am not an expert either, but I believe that
with SMTP, the sender keeps trying to SEND until
it gets an OK from the Reciever.  The reciever
should use the message-id to recognize repeat
sends and deliver once to the user.

I think that is the behavior you want.

> > Here is a short version of asynchronous callbacks
> > using SMTP:
> >
> >    Send the message to the reply-to address using SMTP
>
> You can do the same in HTTP. Just return a reply-to address. *BUT*.
> *BUT*. *BUT*. The part you're missing is that we are trying to identify
> what makes the web such a great, scalable, interoperable, popular system
> and extend that into the domain of asynch, events, etc. reply-to is
> trivial. But what if you want to say that you DON'T want the reply any
> more? What if you want to have a centralized list of the things you are
> expecting replies about? If you haven't given the reply-request a URI
> then you can't do these things.

Build that.  Those things are orthogonal from
asynchronous message delivery (or polling).

> > Terrorist_or_not.com uses RPC to deliver the
> > queries.  The target of the POST is a function not
> > a resource.
>
> That is not the definition of RPC. What's wrong with a function being a
> resource? It becomes RPC when the function starts dispatching on method
> names and setting up private namespaces.

You can't GET a function and URLs are opaque.
Does something magical happen when some content
moves from the body to the url?

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax









-----------------------------------------------------------------------------------
Post ID:322
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-26 00:09:15
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, Paul Prescod wrote:
> I would say that if you standardize how this is done so that any client
> could send any purchase order to any server and reliably parse the
> return result then you have a new protocol. If you are just building a
> one-off app then by all means, use whatever software you've got laying
> around. Do asynch FTP if it is convenient.

Sure.  Post the PO to a URL.  Or... email the PO
to an email address.  This is a file format issue,
not a protocol issue.

> > Asynchronous delivery may be one of your  problems
> > and SMTP does a decent  job.
>
> You claim it does. But who do you know using SMTP for these kinds of
> jobs? I know about thousands of complicated ecommerce apps using HTTP
> and none using SMTP. Even inside of organizations, most companies do not
> use SMTP for asynch delivery of business-critical information. They use
> MQseries etc.

Thats because SMTP implementations typicall suck.
Check out http://ironport.com.


> > ... The hard problems of security and
> > accountability are orthogonal issues.
>
> This is the crux of our communication problem. You think asynchronous
> delivery is hard and using HTTP makes it harder. I think it is easy and
> using HTTP makes no difference.

No.  I just don't see why you are reinventing the
wheel.

> I think security and accountability are brutally hard and I think that
> reifying objects as addressable entities makes them much more managable.

> Thirty years of Unix and even Windows NT supports my position. How do I
> make it possible for a user to print or not to print? I treat the
> printer (or print queue) as a resource and give them permissions to it.
> How do I cancel jobs? I reify them as objects and then delete them. How
> do I know who did what? I look at the logs for those addressable
> objects.

Ok.  So I think SMTP is like the network transport
layer.  Windows is perfectly happy to use TCP/IP
rather than NetBIOS as its transport.  These
issues are orthogonal to the procedures for
accessing server logs.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:323
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-26 00:07:52
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> I am looking at RFC2821.  It has a whole section
> on "Retry stratgies."  Message-id is covered in
> RFC2822.  The spec does not explicitly cover using
> message-ids in retry context, but SMTP agents may
> obviously use it for exactly this purpose.

No. If the spec does not say that they may ignore two messages sent with
the same Message-ID then they should not. 

Plus:
> In all cases, it is the meaning that the sender
>    of the message wishes to convey (i.e., whether this is the same
>    message or a different message) that determines whether or not the
>    "Message-ID:" field changes, not any particular syntactic difference
>    that appears (or does not appear) in the message.


> > "Go to http://www.google.com/ Type in Paul Constock. Hit Enter."
> 
> That is a user interface convention.  

If you think that the web's fundamental addressing mechanism is user
interface then the gap between us is too large to be bridged in a
predictable amount of time.

> ... By that
> argument, is I urlencoded XML-RPC and passed it in
> the qu\ery string, it would no longer be RPC.

You would also need to use the appropriate HTTP methods for each task.
(GET for queries, PUT for updates, etc.) But other then that, I can't
think of anything theoretically wrong with double-encoding query strings
as XML-RPC and then as URL encoding. It's just ugly as sin.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:324
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-26 00:22:23
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> Thats because SMTP implementations typicall suck.
> Check out http://ironport.com.

Demonstrates nothing. If we set about building real applications with
SMTP we would soon have a thread "why is SMTP hard to design with?"

>...
> 
> No.  I just don't see why you are reinventing the
> wheel.

The wheel is square.

> > I think security and accountability are brutally hard and I think that
> > reifying objects as addressable entities makes them much more managable.
> 
> > Thirty years of Unix and even Windows NT supports my position. How do I
> > make it possible for a user to print or not to print? I treat the
> > printer (or print queue) as a resource and give them permissions to it.
> > How do I cancel jobs? I reify them as objects and then delete them. How
> > do I know who did what? I look at the logs for those addressable
> > objects.
> 
> Ok.  So I think SMTP is like the network transport
> layer.  Windows is perfectly happy to use TCP/IP
> rather than NetBIOS as its transport.  These
> issues are orthogonal to the procedures for
> accessing server logs.

If 

 a) my fundamental concepts are addresses and addressable objects (my
point above)

 b) I already have about five or six layers of "transport" (a simple
fact)

 c) I can easily glue together an address-centric system that does
asynch notifications and routing (you admitted that doing this isn't
hard)

then what benefit am I getting out of SMTP? It seems like there are a
lot of people out there who have an emotional attachment to it just
because it is out there. A few hundred lines of code gets me HTTP
callbacks. A few hundred more get me HTTP event relaying. A few hundred
more get me guaranteed message delivery. Once I've built these I can use
them for every HTTP service in the world...even HTML apps.

What does SMTP bring to the table other than a warm fuzzy feeling?
Backwards compatibility? I can have that through a simple gateway.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:325
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-25 22:53:36
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> Only if you think any use of an HTTP endpoint is a
> protocol.  If I send POs over SMTP and they get
> sent back approved or rejected, I am defining
> something that endpoints are doing.  I am not
> inventing a new transport protocol.

I would say that if you standardize how this is done so that any client
could send any purchase order to any server and reliably parse the
return result then you have a new protocol. If you are just building a
one-off app then by all means, use whatever software you've got laying
around. Do asynch FTP if it is convenient.

>...
> Asynchronous delivery may be one of your  problems
> and SMTP does a decent  job.  

You claim it does. But who do you know using SMTP for these kinds of
jobs? I know about thousands of complicated ecommerce apps using HTTP
and none using SMTP. Even inside of organizations, most companies do not
use SMTP for asynch delivery of business-critical information. They use
MQseries etc.

> ... And if your project
> is that big, I think you would rather reuse SMTP
> than invent a new asynch protocol just for your
> project.  

Right. That's why you would like for rest-discuss to have defined a set
of conventions for you to use. Now will you let us get back to work
doing that?

> ... The hard problems of security and
> accountability are orthogonal issues.

This is the crux of our communication problem. You think asynchronous
delivery is hard and using HTTP makes it harder. I think it is easy and
using HTTP makes no difference.

I thin security and accountability are brutally hard and I think that
reifying objects as addressable entities makes them much more managable.
Thirty years of Unix and even Windows NT supports my position. How do I
make it possible for a user to print or not to print? I treat the
printer (or print queue) as a resource and give them permissions to it.
How do I cancel jobs? I reify them as objects and then delete them. How
do I know who did what? I look at the logs for those addressable
objects.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:326
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-26 00:41:14
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, Paul Prescod wrote:
> No. If the spec does not say that they may ignore two messages sent with
> the same Message-ID then they should not.

No.  The spec leaves it up to the recieving
application.  If you want to claim this is a new
protocol then it is a one line protocol:

	only process any given message-id once.

Also, in good implementations duplicate messages
should be very rare.  See RFC1047.

> > > "Go to http://www.google.com/ Type in Paul Constock. Hit Enter."
> >
> > That is a user interface convention.
>
> If you think that the web's fundamental addressing mechanism is user
> interface then the gap between us is too large to be bridged in a
> predictable amount of time.

No.  My point is that you can "link" to a post
using hidden fields.  So I don't see why this is
so important.

> > ... By that
> > argument, is I urlencoded XML-RPC and passed it in
> > the qu\ery string, it would no longer be RPC.
>
> You would also need to use the appropriate HTTP methods for each task.
> (GET for queries, PUT for updates, etc.) But other then that, I can't
> think of anything theoretically wrong with double-encoding query strings
> as XML-RPC and then as URL encoding. It's just ugly as sin.

So how do you put the terrorist images in the
query string?  Remember you can't pass content
type.

I think the only implementation of
terrorist_or_not.com consistent with REST is:

1. GET URL for terrorist1 image
2. GET URL for terrorist2 image
3. PUT terrorist1.gif
4. PUT terrorist2.jpg
5. GET /terrorist/check?1=url1&2=url2

In contrast, the RPC version represents only a
single request and does not force the server into
deciding when it is ok to garbage collect the
images.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:327
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 23:02:56
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

I'm not sure what Plan9 has to do with anything,
but I am curious how resource synchornization
works.  What happens when two apps try to
write/read the /net/cs file?  Is it locked?

-Alex-


 On Fri, 25 Jan 2002, Jeff Bone wrote:
> "S. Alexander Jacobson" wrote:
>
> > Terrorist_or_not.com passes two arguments to a
> > procedure on the server and that procedure returns a
> > value.
> >
> > You cannot intepret the interaction as anything
> > like either reading, writing, or appending to a
> > file.
>
> You *absolutely* can.  Consider Plan 9:  its networking mechanism presents a
> set of services which look like files:  they can be opened, read, written to
> etc. to communicate with the services in question.  For e.g. name resolution,
> the client opens a file (something like) /net/cs (i.e., "connection server" is
> reified as a "file") writes a string like "www.foo.com", then reads the file
> contents back to receive something like "209.224.18.5".  That is *just like*
> what you're describing above, with the exception that you're only passing a
> single parameter.  (Other Plan 9 services accept multiple "parameters" in this
> fashion.)
>
> > As I said before, sometimes you want something
> > other than HTTP.  Sometimes you want something
> > other than REST.
>
> This is really getting old, Alex.  Sigh.  Mark, let me say now how very sorry
> I am for having put you through this, now that I see how it looks from the
> other side of the fence.  ;-)
>
> jb
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:328
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-26 00:53:23
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

I've learned a lot in this discussion,
but I think I am done.

Here are my conclusions:
1. The distinction between RPC and REST is
incoherent.  We are really talking only about
side-effects.  Since there are many
interesting queries that involve message bodies,
and HTTP defines only GET as having no
side-effect, REST doesn't help you much.  Thinking
of applications as simple messages between
entities gets you just as far (if not farther).

2. You certainly CAN implement the actual delivery
of email using HTTP rather than SMTP.  I just
don't think it provides you with a lot of value.
I think it makes more sense to focus on tracking
and controlling email messages which I think is
orthogonal and doesn't crash you into an installed
base.  To put it another way, adding monitoring
tools for mail servers that expose an HTTP
interface seems like a good idea.  Bothering to
replace SMTP itself with HTTP seems much less
useful (and irrelevant to the better activity!).

Feel free to agree/disagree.  I am done with this
argument either way.

-Alex-

PS I am really impressed with how powerful HTTP
persistent connections can be.  Thank you for the
insight.

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:329
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-26 00:57:17
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> No.  The spec leaves it up to the recieving
> application.  

You're telling me that the SMTP spec gives SMTP implementations
permission to discard messages according to their own discretion?

> ... If you want to claim this is a new
> protocol then it is a one line protocol:
> 
>         only process any given message-id once.
> 
> Also, in good implementations duplicate messages
> should be very rare.  See RFC1047.

If SMTP was reliable RFC1047 wouldn't need to exist. Can we quit arguing
about it? SMTP is not reliable! It has some error reporting capabilities
for use in relaying circumstances. That has nothing to do with my
"reliable HTTP" paper.

>...
> No.  My point is that you can "link" to a post
> using hidden fields.  So I don't see why this is
> so important.

Can I make an RDF assertion about it?
Can I make an XLink to it?
Can I bookmark it in a browser?
Can I download it in an XSLT file?
Can I dictate it to my mom over the phone?
Can I put it on the side of a bus?
Can I make a Windows "Internet Shortcut" to it?
Can I use it as input to wget?
Can I link to it from inside a PDF or Powerpoint?
Can I report it in an HTTP header?
Can I apply an ACL to it?

>...
> So how do you put the terrorist images in the
> query string?  Remember you can't pass content
> type.

You would use POST.

> ...
> In contrast, the RPC version represents only a
> single request and does not force the server into
> deciding when it is ok to garbage collect the
> images.

As I've said a dozen times, you could use POST. It would not be RPC
because you aren't setting up a private addressing scheme, you aren't
telling the target what to do with a method name. Using POST for
non-idempotent things is not a big deal. It is *usually* bad style
because it is *usually* a way around giving resources addresses. It is
also not cachable. But given the option of doing it in a straightforward
way using POST and embedding it in a silly RPC with a method name, it
seems obvious that the method name is useless.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:330
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-26 01:01:33
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

I don't want to start the argument again, but:

 * Side effects are not the issue.

 * Addressability is the issue.

Using POST for things that have no side effects is USUALLY a waste
because USUALLY such things should be addressable and using POST is a
way of getting around making them addressable. If there are good reasons
not to make them addressable (e.g. it is a huge binary which is not
realistically usable as an address) then by all means use POST. Even use
FTP. Or UDP. REST is about making things addressable. In most real-world
applications this matters.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:331
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-26 01:10:56
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

> This is really getting old, Alex.  Sigh.  Mark, let me say now how very sorry
> I am for having put you through this, now that I see how it looks from the
> other side of the fence.  ;-)

Heh.  Well at least you listened. 8-)

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:332
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-26 01:13:52
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

>
> XML-RPC uses POST too.  But you deny that it is REST!

If you do a POST to do a DELETE, firewalling/caching don't work so good.
If a POST is the only way to GET, you can't hyperlink or bookmark or email
to friends, etc.
If a GET does a DELETE, spiders will walk your site and wreak havoc.

Say what you mean and mean what you say.
We need to all hang together or we will surely all hang separately.







-----------------------------------------------------------------------------------
Post ID:333
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-26 01:31:37
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, Paul Prescod wrote:
> I don't want to start the argument again, but:
>  * Side effects are not the issue.
>  * Addressability is the issue.

Ah.  Ok.  I get it.  You want every email message
to be available via HTTP --until it is
acknowledged or times out-- so you can POST
replies to message URLs.  You want to check
presence via HTTP.  all cool.

So the issue with RPC is that you are concerned
that people will use it to hide query values.
This makes sense when the value of the query may
change or when the size of the value is larger
than the size of the URL!

So MIME-RPC conventions are useful either way.  I
just need to add the following to the spec:

  When using MIME-RPC over HTTP, implementations
  SHOULD interpret the query string of GET
  requests as a MIME body with content type
  <code>application/x-www-form-urlencoded</code>
  if it contains an "=" and as a body without
  content-type otherwise.  Implementations should
  not expose state-changing methods via GET.
  However, methods exposed via GET should also
  work via POST.

Would that work for everyone?

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:334
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-26 01:19:51
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

> PS I am really impressed with how powerful HTTP
> persistent connections can be.  Thank you for the
> insight.
 
Don't thank me, thank John Tigue.






-----------------------------------------------------------------------------------
Post ID:335
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-26 01:47:07
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> Ah.  Ok.  I get it.  You want every email message
> to be available via HTTP --until it is
> acknowledged or times out-- so you can POST
> replies to message URLs.  You want to check
> presence via HTTP.  all cool.

Right!

> So the issue with RPC is that you are concerned
> that people will use it to hide query values.

Right.

> This makes sense when the value of the query may
> change or when the size of the value is larger
> than the size of the URL!

Don't know what you mean by that.

> So MIME-RPC conventions are useful either way.  

Of course. It all comes down to: "MIME-RPC is the most important thing."
;)

> ... I
> just need to add the following to the spec:
> 
>...
> 
> Would that work for everyone?

Well I would deprecate the RPC conventions and change the name but other
than that...I guess its fine.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:336
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-26 01:50:17
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

> Mark Baker wrote:
> > 
> > Ok, how about a new approach.
> > 
> > Let's say you and I each have an SMTP, FTP, and HTTP server on our
> > machines.  Without any further agreement between us, which one can be
> > used to do the most things?
> 
> Well it depends how they are configured. I'd guess it would have to be
> wide open to do anything useful. Can you make a strong case that a wide
> open HTTP server is more "powerful" than a wide open FTP server? Either
> can PUT, GET, DELETE. And FTP servers have directories that you can
> append to....

But only in a PUT way, not POST.

Anyhow, I was going to get into feature negotiation (Accept-*),
response codes, headers like Content-Location and Location, etc..

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:337
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-25 23:59:59
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, Paul Prescod wrote:
> > I am not an expert either, but I believe that
> > with SMTP, the sender keeps trying to SEND until
> > it gets an OK from the Reciever.  The reciever
> > should use the message-id to recognize repeat
> > sends and deliver once to the user.
> >
>
> Scanning the SMTP spec, I don't see anything about message ids. The word
> "message-id" is never mentioned once. The word "retry" is never
> mentioned.

I am looking at RFC2821.  It has a whole section
on "Retry stratgies."  Message-id is covered in
RFC2822.  The spec does not explicitly cover using
message-ids in retry context, but SMTP agents may
obviously use it for exactly this purpose.

> > Does something magical happen when some content
> > moves from the body to the url?
>
> That should be obvious. When you move content to the URL, the compound
> URL becomes addressable:
>
>  * http://www.google.com/search?hl=en&q="Paul+Comstock"
>
> versus
>
> "Go to http://www.google.com/ Type in Paul Constock. Hit Enter."

That is a user interface convention.  By that
argument, is I urlencoded XML-RPC and passed it in
the qu\ery string, it would no longer be RPC.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:338
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-26 00:16:16
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, Mark Baker wrote:
> Let's say you and I each have an SMTP, FTP, and HTTP server on our
> machines.  Without any further agreement between us, which one can be
> used to do the most things?

I think we send/recieve far more email than we
use the web.  The volume on this list completely
crowds out any time we might spend web surfing
:-).

(If you are reading your email through the web,
you are still relying on SMTP to get it there!)

More seriously.  If I had to choose whether to be
without email or the web, I would choose to be
without the web.  HTTP as it stands has no way to
do relying and I like the option to read my email
offline :-).

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:339
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-26 00:28:05
Subject:ironport.com
Message:

"AsyncOS is optimized for
asynchronous tasks like Internet
Messaging. AsyncOS includes a unique
new file system, an I/O-driven scheduler,
and a revolutionary new threading model."

What's an "asynchronous task?" One where the server doesn't send back an
answer until later? How would you optimize an operating system for such
a task?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:340
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-26 18:49:36
Subject:Plan 9 explanation for Alex
Message:


"S. Alexander Jacobson" wrote:

> I'm not sure what Plan9 has to do with anything,

The point of the Plan 9 anecdote is that it stands as an existance proof
invalidating your claim that parameter passing to a procedure cannot be modeled as
file IO.  Certainly almost anything --- and maybe *anything* --- that can be modeled
as parameter passing to a procedure can be modeled as generic stream IO on a file /
resource.

Plan 9 an example of making various things --- including active "data producing
processes" --- look like files.  The original idea of UNIX, broken by the
introduction of sockets, was to make everything look like a file.  Plan 9 was an
attempt by most of the original authors of UNIX to go back and push that concept to
the limit, unifying everything as resources (files) in a single namespace sharing a
single generic stream IO interface.

I bring it up because it's a great example of how to do the *kind* of thing we're
talking about here, albeit in a different namespace with a different generic
interface.  It's a *great* case study, though;  I didn't really "get" REST until I
started thinking about how things are modeled in Plan 9 as an analogy.  (Side note:
in a private e-mail with Roy Fielding around the time I had my REST gestalt, I
pointed out the Plan9 analogy;  he claimed that he'd wished he'd been more familiar
with / had some citations for it a while back --- he apparently agreed with me and
thought the analogy useful and appropriate.)

> but I am curious how resource synchornization
> works.  What happens when two apps try to
> write/read the /net/cs file?  Is it locked?

In Plan 9, every process has a private view of the namespace.  For example:  8 1/2,
the Plan 9 window system, represents the mouse as /dev/mouse, IIRC.  8 1/2 itself
handles synchronization and acts as the multiplexer / demultiplexer for events
generated by this device;  each process sees its own private version of /dev/mouse;
a process which opens and reads this file will read a stream of only those events
generated in the window in which the process is running.  In other words, mux and
sync are generally handled in Plan 9 by whatever "server" presents a given service
as a resource, in whatever manner is appropriate for that service.

$0.02,

jb








-----------------------------------------------------------------------------------
Post ID:341
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-26 18:58:14
Subject:Re: REST Terrorist-Or-Not, and Alex's Objections / Issues
Message:

"S. Alexander Jacobson" wrote:

> Ok.  I guess I'm just not getting how posting two
> images to a URL is resource modeling.

The question isn't what you're posting, it's what you're posting *to.*

> Suppose there was another argument, that had one
> of two values: isTerrorist | isFed
>
> Would that make it non-Restful?

What makes something RESTful isn't what you're posting, its how you present the service
in HTTP / URI-space.

> I don't understand why SMTP doesn't do what you
> want.

This is a *very simple* point.  Listen closely.  It doesn't do what we want it to so
because it doesn't present as resources that can be interacted with via the generic HTTP
interface.

> HTTP is inherently unreliable.  SMTP is only in
> practice unreliable because the implementations
> suck.

This is a red herring at best, wrong at worst.  There's no reason to believe SMTP is any
more or less reliable than HTTP --- indeed, given the DNS-driven and routed nature of
SMTP it's architecturally *more* susceptible to reliability problems than HTTP.

> Ok.  So the big bonus here is that my email
> address is http://i2x.com/~alex rather than
> alex@....  GETting this URL would retrieve my
> homepage or some form of status information and
> POSTing to it would send me an email.
>
> Interesting, but I guess I just don't see so much
> value there.

Can't help you there.  Keep thinking about it.

> They are all fine.  What I fail to get is what
> exactly you don't like about RPC.

It creates new namespaces, and "hides" things that are more usefully exposed.  It also
compounds complexity and creates tighter coupling between the producer and consumer of
some information, service, etc.  It's also historically been a bad approach for building
vast-scale distributed systems:  system built atop CORBA, DCOM, ONC, DCE, etc. have never
had the kind of deployment / adoption that the Web has had.  Why?  The REST hypothesis on
this is that it's inherently related to the nature of RPC vs. HTTP.

> >  I still haven't seen any single point you've raised that addresses Mark
> > Baker's fundamental challenge, which is
> >
> >    "Show me an application that I can't do with HTTP."
>
> I answered this before.

Nope.

> My answer was show me
> an application that you can't do with SMTP.

And we did this:  the Web.

$0.02,

jb








-----------------------------------------------------------------------------------
Post ID:342
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-26 19:00:04
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

"S. Alexander Jacobson" wrote:

> > It may be possible to use SOAP with HTTP --- Mark's got a better read on the current
> > state of that effort (keeping SOAP from becoming unavoidably RPC-based) than I do.
> > It's almost certainly *not* possible to use XML-RPC with HTTP without breaking HTTP.
> > I.e., if you use e.g. XML-RPC, you aren't using HTTP, you're tunneling RPCs through
> > HTTP.
>
> I don't see what the difference is between XML-RPC
> and Mike's solution to the terrorist-or-not.com
> problem.

I know.  Keep thinking about it.  If you really work at it, you'll get it.  I did and I
was *almost* as stubborn about these *same arguments* as you.

> XML-RPC uses POST too.  But you deny that it is
> REST!

It's not what method is used, it's HOW its used.

jb








-----------------------------------------------------------------------------------
Post ID:343
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-26 19:01:57
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:


"S. Alexander Jacobson" wrote:

> I've learned a lot in this discussion,
> but I think I am done.

Hallelujah!

:-)

jb








-----------------------------------------------------------------------------------
Post ID:344
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-26 21:55:28
Subject:Computer Science behind REST
Message:

I've heard REST and Linda compared often. I've never learned Linda (or
JavaSpaces etc.) so I don't see how the references are relevant.

What is the relationship to Linda?
How is a "resource" isomporphic to a "tuple space"?
How are the HTTP methods isomorphic to Linda out(), in(), rd(), eval()?
Historically speaking, was HTTP designed to be "like" Linda?

I note the following claim for IBM's TSpaces:

 * Data is de-coupled from programs. Data can outlive its producer
(because once it's produced, it lives in tuple space) and can be
produced before the receiver exists. 

 * Communication is anonymous. The sender needn't know about the
receiver, and vice-versa. Sender and receiver only need to know about
tuple space, which mediates all communication. 

 * Communication is asynchronous. The sender and receiver don't have to
rendezvous to communicate; the producer produces when it's ready, and
the consumer consumes when it's ready. 

None of these seem to apply to HTTP to me. I have no doubt that you
could build a Linda layer on top of HTTP but I have trouble seeing how
it is "already there."

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:345
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-26 22:23:43
Subject:Fw: Delivery Status Notification (Delay)
Message:

How ironic...

----- Original Message ----- 
From: +ADw-postmaster+AEA-mail.hotmail.com+AD4-
To: +ADw-mdierken+AEA-hotmail.com+AD4-
Sent: Saturday, January 26, 2002 12:32 AM
Subject: Delivery Status Notification (Delay)


+AD4- This is an automatically generated Delivery Status Notification.
+AD4- 
+AD4- THIS IS A WARNING MESSAGE ONLY.
+AD4- 
+AD4- YOU DO NOT NEED TO RESEND YOUR MESSAGE.
+AD4- 
+AD4- Delivery to the following recipients has been delayed.
+AD4- 
+AD4-        rest-discuss+AEA-yahoogroups.com
+AD4- 
+AD4- 
+AD4- 
+AD4- 






-----------------------------------------------------------------------------------
Post ID:346
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-26 23:38:37
Subject:Re: [rest-discuss] Computer Science behind REST
Message:

Paul Prescod wrote:

> What is the relationship to Linda?

It's loose, at best.  Some of us have made the claim --- admittedly rather
poorly substantiated --- that HTTP forms a kind of "coordination language"
similar to Linda in its potential application.  We haven't done a
particularly good job of explaining what that means and, indeed, the very
notion of a "coordination language" is rather underdefined.

> How is a "resource" isomporphic to a "tuple space"?

Wrong abstractions.  If the analogy holds, the resource space is analogous to
a tuple space, and a single resource is analogous to a tuple.  This is an
inexact analogy;  most Linda implementations allow associative matching via
any permutation of tuple fields;  if you imagine resources to be tuples of
the form (URI, ...) then the Web only allows matching of tuples via the URI
field.

> How are the HTTP methods isomorphic to Linda out(), in(), rd(), eval()?

NB:  the eval() construct appeared in lots of early papers but its semantics
proved fairly fuzzy and its implementation difficult.  It's usually been
dropped or ignored by almost all later Linda and Linda-like systems.

For the others, the mapping is pretty straightforward if a bit inexact.
out() is like PUT, rd() is like GET, and in() is like an atomic GET+DELETE.
It's important to understand that most distributed algorithms using Linda as
a coordination paradigm strongly require the latter in() semantics, which are
obviously missing in HTTP.

> Historically speaking, was HTTP designed to be "like" Linda?

AFAIK, it wasn't.

>  * Communication is asynchronous. The sender and receiver don't have to
> rendezvous to communicate; the producer produces when it's ready, and
> the consumer consumes when it's ready.

This is true.  Linda proceeds from a fundamentally asynchronous bias, and
builds synchronous protocols atop as-needed.  A generative HTTP system would
take the reverse approach.

> None of these seem to apply to HTTP to me.

Data decoupled from process:  data artifacts can easily be generated and
placed at URI where the persist after the producer is finished.

Communication is anonymous, in the sense of producer and consumer don't have
to "know" each other, and communication is mediated by the TS:  same thing
for the Web, all producer and consumer have to "know" about each other is how
to address the resource artifacts each produce in the URI space, and HTTP's
generic methods and architecture mediates the connection.  (Consider that a
consumer is actually connecting to a generic server and communicating via a
generic protocol with the information space the server maintains ---
analogous to most implementations of TS.)  The big difference is the
asymmetry:  producer and consumer use the same interface in Linda systems,
while primarily the consumer case is standardized in HTTP.  The Web is
"read-mostly."

> I have no doubt that you
> could build a Linda layer on top of HTTP but I have trouble seeing how
> it is "already there."

It's not.  The claim isn't that the Web *is* Linda, it's that the GET, PUT,
POST, etc. methods on URI space form a coordination language in the same
sense Linda does --- but with different coordination primitives.

I like the idea, but it's not clear that the claim is useful.  ;-)

jb








-----------------------------------------------------------------------------------
Post ID:347
Sender:Jim Ancona <jim@...>
Post Date/Time:2002-01-27 00:46:14
Subject:Re: [rest-discuss] Computer Science behind REST
Message:

--- Paul Prescod <paul@...> wrote:
> I've heard REST and Linda compared often. I've never learned Linda (or
> JavaSpaces etc.) so I don't see how the references are relevant.
<snip>
> I have no doubt that you
> could build a Linda layer on top of HTTP but I have trouble seeing how
> it is "already there."

RogueWave has "Ruple", a tuple space based on XML and HTTP. Unfortunately the
HTTP interface seens to be based on SOAP RPC's. From a cursory glance at their
white paper, it doesn't look like anything within the space is given a URI. See
http://www.roguewave.com/developer/tac/ruple/.

Jim

=====
Jim Ancona
jim@...                     jancona@...

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com






-----------------------------------------------------------------------------------
Post ID:348
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-27 01:21:22
Subject:Privacy and intermediaries
Message:

One of the major advantages of REST is that it is designed so that
intermediaries understand what is going on and can thus do the right
thing. But what if users decide that they do NOT want intermediaries to
understand what is going on? What if I don't want AOL to know I'm
surfing porn?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:349
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-27 01:23:03
Subject:Re: [rest-discuss] Computer Science behind REST
Message:

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> > What is the relationship to Linda?
> 
> It's loose, at best.  Some of us have made the claim --- admittedly rather
> poorly substantiated --- that HTTP forms a kind of "coordination language"
> similar to Linda in its potential application.  We haven't done a
> particularly good job of explaining what that means and, indeed, the very
> notion of a "coordination language" is rather underdefined.

Ahh. Too bad. I was hoping that Linda was to HTTP as the Lambda Calculus
is to Scheme. 

> > How is a "resource" isomporphic to a "tuple space"?
> 
> Wrong abstractions. 

Sorry. I meant resource to tuple.

>...
> For the others, the mapping is pretty straightforward if a bit inexact.
> out() is like PUT, rd() is like GET, and in() is like an atomic GET+DELETE.

Interesting that there is no POST. POST is the Web's achilles heel in
many ways. It isn't obvious that it is necessary but it is also the
"most popular" method in that people tend to fall back on it when they
are too lazy to figure out the others.

> It's important to understand that most distributed algorithms using Linda as
> a coordination paradigm strongly require the latter in() semantics, which are
> obviously missing in HTTP.

Grumble...why couldn't this all map nicely. 

>...
> Data decoupled from process:  data artifacts can easily be generated and
> placed at URI where the persist after the producer is finished.

Sort of. But if the Google guys turn off Google it goes away. There is
no big tuplespace in the sky keeping track of every URI ever generated.
Thank god!

> Communication is anonymous, in the sense of producer and consumer don't have
> to "know" each other, and communication is mediated by the TS:  same thing
> for the Web, all producer and consumer have to "know" about each other is how
> to address the resource artifacts each produce in the URI space, and HTTP's
> generic methods and architecture mediates the connection.  

>...
> 
> It's not.  The claim isn't that the Web *is* Linda, it's that the GET, PUT,
> POST, etc. methods on URI space form a coordination language in the same
> sense Linda does --- but with different coordination primitives.

Too bad they are different. I guess most CS analysis of Linda will not
apply to the Web. 

> I like the idea, but it's not clear that the claim is useful.  ;-)

Yep.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:350
Sender:Jim Ancona <jim@...>
Post Date/Time:2002-01-27 01:26:18
Subject:Re: [rest-discuss] Privacy and intermediaries
Message:

--- Paul Prescod <paul@...> wrote:
> One of the major advantages of REST is that it is designed so that
> intermediaries understand what is going on and can thus do the right
> thing. But what if users decide that they do NOT want intermediaries to
> understand what is going on? What if I don't want AOL to know I'm
> surfing porn?

Use a secure proxy, like http://www.privasec.com. Of course you still have to
trust the proxy, but AOL only sees you connection to the proxy site, not the
ultimate destination.

Jim

=====
Jim Ancona
jim@...                     jancona@...

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com






-----------------------------------------------------------------------------------
Post ID:351
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-27 02:06:42
Subject:Re: [rest-discuss] Privacy and intermediaries
Message:

Jim Ancona wrote:
> 
>...
> 
> Use a secure proxy, like http://www.privasec.com. Of course you still have to
> trust the proxy, but AOL only sees you connection to the proxy site, not the
> ultimate destination.

Okay, but if I do this, am I not disabling AOL's proxy? That's my point,
if privacy becomes "popular" won't it destroy intermediaries?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:352
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-27 02:36:43
Subject:Re: [rest-discuss] Computer Science behind REST
Message:

This is a very good thread, btw.  :-)

Paul Prescod wrote:

> Interesting that there is no POST. POST is the Web's achilles heel in
> many ways. It isn't obvious that it is necessary but it is also the
> "most popular" method in that people tend to fall back on it when they
> are too lazy to figure out the others.

I suppose that in some vague way POST is analogous to eval().  Eval() always proved
problematic in any formalization of Linda semantics, just as POST is rather
problematic --- and in both cases .  In both, data is put into the information
space, evaluated, and results in new information.  Interesting to note that in POST
--- due to the synchronous nature of HTTP - a single write/read is required, but
with eval()/in() a dual write/read is required.  Another difference is that eval is
a one-shot thing that turns into a single data tuple, while a POSTable resource is
a persistent thing that produces successive information without necessarily
creating new tuples / resources.

More later,

jb








-----------------------------------------------------------------------------------
Post ID:353
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-27 02:37:28
Subject:Re: [rest-discuss] Computer Science behind REST
Message:


Jeff Bone wrote:

> This is a very good thread, btw.  :-)
>
> Paul Prescod wrote:
>
> > Interesting that there is no POST. POST is the Web's achilles heel in
> > many ways. It isn't obvious that it is necessary but it is also the
> > "most popular" method in that people tend to fall back on it when they
> > are too lazy to figure out the others.
>
> I suppose that in some vague way POST is analogous to eval().  Eval() always proved
> problematic in any formalization of Linda semantics, just as POST is rather
> problematic --- and in both cases .

Woops.  In both cases much of the power of the paradigm is in these underdefined
operations.

:-)

jb








-----------------------------------------------------------------------------------
Post ID:354
Sender:Jim Ancona <jim@...>
Post Date/Time:2002-01-27 03:13:14
Subject:Re: [rest-discuss] Privacy and intermediaries
Message:

--- Paul Prescod <paul@...> wrote:
> Jim Ancona wrote:
> > Use a secure proxy, like http://www.privasec.com. Of course you still have
> to
> > trust the proxy, but AOL only sees you connection to the proxy site, not
> the
> > ultimate destination.
> 
> Okay, but if I do this, am I not disabling AOL's proxy? That's my point,
> if privacy becomes "popular" won't it destroy intermediaries?

Certainly, but if you don't trust AOL, then disabling their proxy is a feature!
Privasec is still proxying your traffic, but you trust them (or you shouldn't
be using them). So privacy concerns should cause traffic to migrate from
untrusted to trusted intermediaries. Proxying by a trusted intermediary may
improve privacy, since connections can't be traced directly to your IP, and
your traffic is aggregated with that of other users of the proxy.

Whom you should trust is an interesting question. For example, Privasec, nee'
Safeweb had the CIA as an investor at one point.

Jim

=====
Jim Ancona
jim@...                     jancona@...

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com






-----------------------------------------------------------------------------------
Post ID:355
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-27 03:12:13
Subject:Re: [rest-discuss] security of callbacks
Message:

Lucas Gonze wrote:
> 
>...
> 
> An HTTP request is asymetric with regard to state.  Client state is opaque,
> except that it must have enough state to interpret a response.  Server state is
> exposed using HTTP methods.  Clients have always been less prone to security
> problems than servers, because they expose so much less state.  The only client
> resource exposed is the state machine that performs the request.  For a callback
> sink to be no less secure than a client request, the only resource the sink can
> expose is a similar state machine.

Why do you call this a state machine?

Note that as soon as you do a callback you are exposing the fact that
you are running software that accepts HTTP connections. I could see that
as having security implications if that software is poorly written but
there isn't much we can do about that.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:356
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-27 16:34:25
Subject:RE: [rest-discuss] security of callbacks
Message:

paul said:
> Why do you call this a state machine?

An HTTP requester has these state transitions:
1) connecting to the server
2) writing the request
3) reading the response

#2 assumes #1, #3 assumes #1 and #2.  In any callback message, #1 and #2 can't
be assumed.  Responses happen in the context of specific prior requests and
specific prior connections.  Designers of a callback scheme have a burden of
proof to show that messages can be strongly correlated with earlier requests and
connections.  For example, Jeff's authentication scheme is intended to meet the
requirement for correlation.

> Note that as soon as you do a callback you are exposing the fact that
> you are running software that accepts HTTP connections. I could see that
> as having security implications if that software is poorly written but
> there isn't much we can do about that.

Yeah, this is why I said that server socket implementations were already
necessarily paranoid and that would have to be good enough.  But after a few
days of mulling over my message about security, your proposal about
protocol-level support for callbacks, and my earlier message about
application-level support for callbacks, I have changed my mind.  I now believe
that callback schemes must avoid a requirement that sinks act as HTTP/1.1
servers.

Requiring clients to act as HTTP/1.1 servers is a fatal security problem.  No
competent security admin would let it happen.  Saying there isn't much we can do
about it is hand waving.  If we don't address it, we won't succeed at making a
general purpose notification facility available.

(I don't mean by "we" that there is something analogous to a WG.  I mean "we" in
the sense of "the cat herd nibbling away at the problem of HTTP notifications.")

- Lucas












-----------------------------------------------------------------------------------
Post ID:357
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-27 18:51:10
Subject:Re: [rest-discuss] security of callbacks
Message:

>  I now believe
> that callback schemes must avoid a requirement that sinks act as HTTP/1.1
> servers.

There are only a few options that avoid this:  (1) held connections ala KN, (2)
polling, or a new, as-yet unspecified gender-changing intermediary coupled with (1)
or (2).  I don't particularly like any of these, do you?

> Requiring clients to act as HTTP/1.1 servers is a fatal security problem.

Why?  Running such on a "client" is no worse than running one on a "server" in the
first place.

> No
> competent security admin would let it happen.

Let's design for the application, okay, rather than the admin.  Administration is a
significant but separate series of concerns.

What about server-server callbacks, meaning callbacks from server-class machine to
server-class machine, both in actively administered environments, both already
running HTTP server software?  In this case, you're not really compromising the
security of either system, are you?

I would suggest that the scope of this effort is to determine how to allow one
resource-modeled entity to register an interest in state changes of a second
resource and subsequently receive notifications from that second resource.  Such a
scope presumes that both systems hosting these resources can symmetrically initiate
connections and that both systems are secured at an appropriate level by their
respective administrators.  Asymmetry of connectivity is a separate issue.

$0.02...?

jb








-----------------------------------------------------------------------------------
Post ID:358
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-27 19:04:58
Subject:RE: [rest-discuss] security of callbacks
Message:

>
> >  I now believe
> > that callback schemes must avoid a requirement that sinks act as HTTP/1.1
> > servers.
>
> There are only a few options that avoid this:  (1) held connections
> ala KN, (2)
> polling, or a new, as-yet unspecified gender-changing intermediary
> coupled with (1)
> or (2).  I don't particularly like any of these, do you?

..see following message for detailed comments.

> > Requiring clients to act as HTTP/1.1 servers is a fatal security problem.
>
> Why?  Running such on a "client" is no worse than running one on a
> "server" in the
> first place.

Many many reasons.  The risks of running public servers are well known.  They
are administered by skilled specialists and even so are generally outside (or
right on) the firewall.  The skill and commitment of users is lower.  The
machine setup is less secure.


>
> > No
> > competent security admin would let it happen.
>
> Let's design for the application, okay, rather than the admin.
> Administration is a
> significant but separate series of concerns.

For once I am describing admins as competent bots rather than incompetent ones.
This doesn't happen often.
s/competent security admin/competent userbot/


>
> What about server-server callbacks, meaning callbacks from
> server-class machine to
> server-class machine, both in actively administered environments, both already
> running HTTP server software?  In this case, you're not really
> compromising the
> security of either system, are you?
>
> I would suggest that the scope of this effort is to determine how to allow one
> resource-modeled entity to register an interest in state changes of a second
> resource and subsequently receive notifications from that second
> resource.  Such a
> scope presumes that both systems hosting these resources can
> symmetrically initiate
> connections and that both systems are secured at an appropriate level by their
> respective administrators.  Asymmetry of connectivity is a separate issue.

I think that it's a good idea to separate the requirements for callbacks between
server-class pairs and between server/client pairs.  I think that notifications
between server pairs are great functionality.  I don't think that the problem
will be solved until clients can receive notifications.

(More to follow).

- Lucas









-----------------------------------------------------------------------------------
Post ID:359
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-27 19:28:52
Subject:Re: [rest-discuss] security of callbacks
Message:

Lucas Gonze wrote:

> Many many reasons.  The risks of running public servers are well known.  They
> are administered by skilled specialists and even so are generally outside (or
> right on) the firewall.  The skill and commitment of users is lower.  The
> machine setup is less secure.

None of this is unique to HTTP.  Essentially you are arguing against any sort of
decentralized system where nodes have symmetric connectivity and no fixed client /
server roles.  You've just given the administrative argument against p2p in any
sense.

IMO, it's important to recognize that, while security should be considered and dealt
with, the *way* it's dealt with today (i.e., network admins who build walls around
their castles) imposes severe obstacles to creation and proliferation of new,
innovative technologies.  It also *dramatically* lowers the value of the network as
a whole;  since the value rises with the number of possible interconnections between
nodes, the fact that most of the nodes in the Web today are clients and cannot be
connected *to* is a serious value constraint.

Without discounting the need for *security,* it's important to recognize that
*network admins* and their administrative practices which cause asymmetric
connectivity are in fact damage and must be routed around if we're to get maximum
value out of this network-thingie we've built. ;-)

jb








-----------------------------------------------------------------------------------
Post ID:360
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-27 19:32:16
Subject:a proposal for secure notifications
Message:

In the following proposal I suggest a secure mechanism for event notifications.
The purpose of this design is to maximize security.  As with all my recent work,
e.g. the aREST design for application-level notification support, it is an
experiment to explore a particular aspect of the problem space.

Many solutions for implementing HTTP notifications use callbacks to a sink-side
HTTP server.  However running a full featured HTTP server creates very serious
security problems.  From a security perspective an ideal solution would be only
a little less secure than running an HTTP client, and running a full server
makes that impossible.

The sink must operate a protocol designed for extreme paranoia.  I will call
this protocol "Paranoid Sink Protocol", or PSP.  The goal of PSP is to make HTTP
event notifications secure.  The name "PSP" is a placeholder -- it may or may
not be HTTP.  PSP exists exclusively to notify HTTP clients that they should
initiate an HTTP request.  All risky activities are performed via requests, thus
preserving the existing security levels of web clients.

DESIGN
=======

Here is a sample of a PSP transaction:
1) A client uses HTTP 1.0 or later to request notifications on a resource.  The
client provides a PSP URI.  The client and server construct a secure ticket to
identify valid PSP notifications.  The ticket might, for example, be a public
key or a secret token.  The server provides a URI for picking up events once
notification has been received.
2) Time passes.
3) The source node emits a PSP notification.  The notification contains only
enough information to validate the ticket.  It does not contain the callback
address.  It is a fixed length to prevent buffer overflow attacks.
4) The sink validates the ticket and disconnects without a response of any kind.
5) The sink requests the event from the event pickup URI.

To prevent port scanning, PSP does not return either a TCP ACK or an HTTP
response.  However there does exist an ACK in the form of the sink poll in #5
above.  A source MUST assume that a #3 notification not followed by a #5 poll
has not been received.

To prevent buffer overflows and to make TCP unnecessary, PSP uses fixed length
messages.  512 bytes should be enough.

To protect the sink from malicious parties, notifications MUST be idempotent.
The sink need not store any information about the message after transmission.
All notifications and polls related to a specific ticket are identical.  A
single poll picks up all stored messages.

IMPLEMENTATION
==============

For an implementation of PSP, HTTP 0.9 fits perfectly.  It can legally ride over
UDP or IP, does not require any response at all, and only supports idempotent
operations.  Its brutally trivial nature makes implementations orders of
magnitude easier to secure than HTTP 1.1 implementations.

The security of PSP is dependent on security of the (#1) event subscription and
ticket negotiation.  Adequate security of #1 is a big what-if.  Design of the
ticket negotiation is a challenge to be taken seriously.

To prevent packet sniffers from spoofing notifications, the ticket should be
renegotiated at each (#5) request.  Since the request will not be observable
before the first notification is sent, and subsequent notifications (spoofs or
not) have no effect, sucessful spoofing will have no worse an effect than
sending random packets.

It is apparent that, due to the requirement that notifications must be followed
up with a request, PSP is not designed for performance.  The only problem it
addresses is security.

See http://www.w3.org/Protocols/HTTP/AsImplemented.html for the HTTP 0.9
specification.

- Lucas








-----------------------------------------------------------------------------------
Post ID:361
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-27 19:53:25
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:

Lucas Gonze wrote:
> 
>...
> 
> Many solutions for implementing HTTP notifications use callbacks to a sink-side
> HTTP server.  However running a full featured HTTP server creates very serious
> security problems.  From a security perspective an ideal solution would be only
> a little less secure than running an HTTP client, and running a full server
> makes that impossible.

Who says you need to run a "full server"? We can explicitly define a
minimal profile of HTTP that a callback target must support.

The security dudes are going to be unhappy with any system that allows
people outside to open connections to people inside. But that's the very
nature of a callback. We can "route around" them using persistent
connection hacks etc. But first we should design as if we didn't need to
do that.

> 1) A client uses HTTP 1.0 or later to request notifications on a resource.  The
> client provides a PSP URI.  The client and server construct a secure ticket to
> identify valid PSP notifications.  The ticket might, for example, be a public
> key or a secret token.  The server provides a URI for picking up events once
> notification has been received.

Can't the ticket be embedded in the PSP URI?

> 3) The source node emits a PSP notification.  The notification contains only
> enough information to validate the ticket.  It does not contain the callback
> address.  It is a fixed length to prevent buffer overflow attacks.

What is the danger in containing the callback address? We could set up a
maximum length on these things of 2048 bytes or something.

> 4) The sink validates the ticket and disconnects without a response of any kind.

Okay, so this is clearly NOT HTTP. HTTP requires a response. What's
dangerous about a formulaic 200 OK response?

> 5) The sink requests the event from the event pickup URI.

Okay.

> To prevent port scanning, PSP does not return either a TCP ACK or an HTTP
> response.  However there does exist an ACK in the form of the sink poll in #5
> above.  A source MUST assume that a #3 notification not followed by a #5 poll
> has not been received.

What does "followed by" mean? How long does the client have?

> To prevent buffer overflows and to make TCP unnecessary, PSP uses fixed length
> messages.  512 bytes should be enough.
>
> To protect the sink from malicious parties, notifications MUST be idempotent.
> The sink need not store any information about the message after transmission.
> All notifications and polls related to a specific ticket are identical.  A
> single poll picks up all stored messages.

Don't think that single-poll thing is very REST-y. The client and the
server should not need to share an understanding about who has what
messages. The client should control when it deletes a message on the
server. The server can also impose timeout or space usage policies.

>...
> 
> For an implementation of PSP, HTTP 0.9 fits perfectly.  It can legally ride over
> UDP or IP, does not require any response at all, and only supports idempotent
> operations. 

Yes it does! http://www.w3.org/Protocols/HTTP/AsImplemented.html

HTTP has always had a response.

>...
> To prevent packet sniffers from spoofing notifications, the ticket should be
> renegotiated at each (#5) request. 

Why not address packet sniffing (and perhaps all server-authentication)
using SSL?

"The response to a simple GET request is a message in hypertext mark-up
language ( HTML ). This is a byte stream of ASCII characters."

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:362
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-27 19:54:30
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:

Sorry, I just can't get behind any solution to this problem that requires asymmetric
protocols.  This is damaging to the overall value proposition of the Web.  While I
have complete respect and sympathy for the folks that have to deal with network
administration and security --- indeed, they are my customers in my commercial
endeavors --- from a pure innovator's perspective this just doesn't cut it.  It
artificially inhibits the proliferation of new technology.

We dealt with this problem ad nauseam at Activerse, where we built the first and
AFAIK to date only truly decentralized presence and instant messaging
infrastructure.  We tried to acquiesce to the needs of the network admin, and
ultimately that was our undoing --- we couldn't sell our technology into enterprises
because it required an active decision on the part of the network admin, whose job
longevity is proportional to their success in preserving the status quo.  By
requiring the active support and involvement of the network admin, we limited our
ability to deploy into the very environment we were attempting to target and build
for.  We would've been much more successful had we simply (ab)used HTTP, using it in
a decentralized way and tunneling HTTP through HTTP itself.

"Extending" (i.e., figuring out how to use) HTTP for symmetric and asynchronous
application communication patterns is a good idea.  Introducing new protocols and
new asymmetries is not.

Other problems with this suggestion:  it doesn't make a whole lot of sense to use
HTTP 0.9 as the PSP.  The only method supported by HTTP 0.9 IIRC is GET, which
doesn't make any sense for a notification.  It's not clear what meaningful responses
could be returned, either.

jb









-----------------------------------------------------------------------------------
Post ID:363
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-27 19:57:08
Subject:RE: [rest-discuss] security of callbacks
Message:

> None of this is unique to HTTP.

This is false in a way that helps illuminate solutions: simplicity leads to
security, because fewer lines of code have fewer bugs to exploit.  Something
simpler than HTTP 1.1 would be more secure.








-----------------------------------------------------------------------------------
Post ID:364
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-27 20:00:40
Subject:Re: [rest-discuss] security of callbacks
Message:


Lucas Gonze wrote:

> > None of this is unique to HTTP.
>
> This is false in a way that helps illuminate solutions: simplicity leads to
> security, because fewer lines of code have fewer bugs to exploit.  Something
> simpler than HTTP 1.1 would be more secure.

You're confusing abstraction with implementation.  You're correct in that
supporting a full HTTP 1.1 inevitably results in more code than just HTTP 0.9,
and the probability of security-compromising bugs is proportional to the amount
of code.  But nobody said a callback service needs to support the full HTTP 1.1
--- and the MUST part of the spec is a *lot* smaller than the SHOULD and MAY
parts.  (Though admittedly it is still bigger than 0.9.)

The point I was trying to make is that the problems you're talking about have
everything to do with problems network admins have with inbound connectivity in
general, regardless of the protocol used.  They're suspicious of *any*
requestable service running on the client machine.  If we're going to build any
form of callback that we really believe will get deployed, we're going to have
to ignore this concern --- simply supporting a smaller protocol with a smaller,
verifiable implementation won't suffice to overcome those fears.

jb









-----------------------------------------------------------------------------------
Post ID:365
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-27 20:04:08
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:

One way to address security is to differentiate between "ordinary"
callbacks and "secure" callbacks. Ordinary callbacks are like SMTP. No
more or less secure. No paranoia.

"Secure" callbacks are created ONLY on a persistent connection created
from the client to the server, potentially using SSL.

Let's face it, that's corporate America's definition of secure
behind-the-firewall software. Outgoing is secure. Incoming is insecure.
So secure callbacks would work just like MSN messenger or ICQ or
Napster, you turn the thing on, it "calls home" and opens a connection.

Insofar as the client knows what server it has contacted, the security
requirements are much lower. After all, Web browsers have historically
been terribly insecure but the practical damage caused by them is low
because the end-user controls what sites he/she contacts. So
accountability is pretty good ("here's the URL of the site that deleted
my hard drive") and it is really hard to get a million users to come to
your site and download your virus.

The care and thought put into your PSP won't mean squat to a corporate
sysadmin. And on reflection I do think that practically speaking,
unidirectional connections provide more safety than paranoid protocol
implementations. And anyhow, it is pretty easy to set up a single
unidirectional connection to your "event server" on the Web and let it
handle the security crap for you.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:366
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-27 20:05:26
Subject:RE: [rest-discuss] security of callbacks
Message:

Jeff said:
> You're confusing abstraction with implementation.  You're correct in that
> supporting a full HTTP 1.1 inevitably results in more code than just HTTP 0.9,
> and the probability of security-compromising bugs is proportional to
> the amount
> of code.  But nobody said a callback service needs to support the
> full HTTP 1.1
> --- and the MUST part of the spec is a *lot* smaller than the SHOULD and MAY
> parts.  (Though admittedly it is still bigger than 0.9.)

It a _lot_ bigger!

> The point I was trying to make is that the problems you're talking about have
> everything to do with problems network admins have with inbound
> connectivity in
> general, regardless of the protocol used.  They're suspicious of *any*
> requestable service running on the client machine.

Right, and it is correct to blow off incompetent adminbots.  We should be
designing for competent adminbots.  They do exist.







-----------------------------------------------------------------------------------
Post ID:367
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-27 20:07:05
Subject:Re: [rest-discuss] security of callbacks
Message:


Lucas Gonze wrote:

> Right, and it is correct to blow off incompetent adminbots.  We should be
> designing for competent adminbots.  They do exist.

Go ahead and design for them, Lucas.  Give them nobs to twiddle.  I've been down
that road, and from a technology adoption perspective IMO it's uninteresting.

jb








-----------------------------------------------------------------------------------
Post ID:368
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-27 20:10:15
Subject:Re: [rest-discuss] security of callbacks
Message:

Lucas Gonze wrote:
> 
> > None of this is unique to HTTP.
> 
> This is false in a way that helps illuminate solutions: simplicity leads to
> security, because fewer lines of code have fewer bugs to exploit.  Something
> simpler than HTTP 1.1 would be more secure.

I would be open to defining an explicit HTTP 1.1 profile. But by talking
about returning nothing, (in violation of the HTTP spec) you're going
beyond that. I agree with Jeff that we should design first, as if there
were no firewall and then figure out tunnelling later. 

The tunnelling isn't rocket science and it has the virtue of putting the
end-user into ultimate control. it can kill the pipe whenever it wants
and the server no longer has a way to get in contact with it. That feels
safer to me. When the little "tunnel" icon is gone from my system tray I
can know that there is *no way* anybody could be talking to my box
because it is invisible to the Web.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:369
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-27 20:26:30
Subject:Re: [rest-discuss] security of callbacks
Message:

I agree that we should presume regular HTTP and then tunnel for the
paranoid sysadmin. They'll prefer tunelling to security-paranoid design
anyhow! There could actually be a business model in setting up secure
event handlers that do the equivalent of spam and virus filtering. The
client would open up a single connection to that service and thus have a
trusted client and a trusted filtering intermediary. Rather than
ignoring security it could be a virtue of the new model. Through bridges
to napster, kazaa, etc., you could get generic peer-to-peer connectivity
intermediated by someone who cares about and thinks about security.

As I said in another note, if I'm going to bed for the night I feel
safer knowing that I'm "disconnected" from the incoming Web than knowing
that I am using a protocol that is ostensibly designed to be easy to
secure. No matter how easy it is to secure someone may screw up so I'd
rather just tunnel to the "event Web" and withdraw when I'm done with
it.

On an unrelated note, I am curious whether you know who coined the term
"resource modelling."

I think it is great. REST is the overall web architectural style but
resource modelling is what individual application creators do in order
to take advantage of the architecture. It is a discipline like object
oriented modelling. It will eventually have its own terminology and
textual/graphical notations.

Perhaps it was coined by Mike D?

 * http://www.xent.com/pipermail/fork/2001-August/003204.html

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:370
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-27 20:33:56
Subject:RE: [rest-discuss] a proposal for secure notifications
Message:

Paul said:
> Who says you need to run a "full server"? We can explicitly define a
> minimal profile of HTTP that a callback target must support.

You bet!  That what PSP is!  Now, it may take a little while to craft PSP fully,
but that's exactly what it'll end up being.

> ecurity dudes are going to be unhappy with any system that allows
> people outside to open connections to people inside. But that's the very
> nature of a callback. We can "route around" them using persistent
> connection hacks etc. But first we should design as if we didn't need to
> do that.

Sorry, no good.  Security happens in the design.

> Can't the ticket be embedded in the PSP URI?

Don't know.  Need to design the ticket with extreme care, so I wouldn't even try
to answer this yet.

>
> > 3) The source node emits a PSP notification.  The notification contains only
> > enough information to validate the ticket.  It does not contain the callback
> > address.  It is a fixed length to prevent buffer overflow attacks.
>
> What is the danger in containing the callback address? We could set up a
> maximum length on these things of 2048 bytes or something.

Danger in containing the callback address is that a malicious spoofer could
redirect the sink so that it doesn't pickup from the right location.


> > 4) The sink validates the ticket and disconnects without a response
> of any kind.
>
> Okay, so this is clearly NOT HTTP. HTTP requires a response. What's
> dangerous about a formulaic 200 OK response?

Nope.  0.9 does not require a response.  It only requires that any response that
does happen be HTML.

> > To prevent port scanning, PSP does not return either a TCP ACK or an HTTP
> > response.  However there does exist an ACK in the form of the sink
> poll in #5
> > above.  A source MUST assume that a #3 notification not followed by
> a #5 poll
> > has not been received.
>
> What does "followed by" mean? How long does the client have?

Don't know!  Good question.  This is probably an application dependent variable.


> > To prevent buffer overflows and to make TCP unnecessary, PSP uses
> fixed length
> > messages.  512 bytes should be enough.
> >
> > To protect the sink from malicious parties, notifications MUST be
> idempotent.
> > The sink need not store any information about the message after
> transmission.
> > All notifications and polls related to a specific ticket are identical.  A
> > single poll picks up all stored messages.
>
> Don't think that single-poll thing is very REST-y. The client and the
> server should not need to share an understanding about who has what
> messages. The client should control when it deletes a message on the
> server. The server can also impose timeout or space usage policies.

Maybe a communication problem here: a notification doesn't say which event
arrived, it only says that an event arrived.    The purpose is to guarantee that
callback servers don't have to expose non-idempotent resources, which eliminates
a large family of attacks.

I didn't mean to say anything at all about whether a callback deletes messages,
deletes em in a bunch, does it one by one, etc!  I'd leave that definition to a
conversation down the road -- this is just algorithms for now.

> > For an implementation of PSP, HTTP 0.9 fits perfectly.  It can
> legally ride over
> > UDP or IP, does not require any response at all, and only supports
> idempotent
> > operations.
>
> Yes it does! http://www.w3.org/Protocols/HTTP/AsImplemented.html
>
> HTTP has always had a response.


0.9 does not require a response.  It only requires that any response that does
happen be HTML.


> > To prevent packet sniffers from spoofing notifications, the ticket should be
> > renegotiated at each (#5) request.
>
> Why not address packet sniffing (and perhaps all server-authentication)
> using SSL?
>
> "The response to a simple GET request is a message in hypertext mark-up
> language ( HTML ). This is a byte stream of ASCII characters."

SSL might be a good idea, but I'd leave that also for discussion down the road,
once algorithms are in place.







-----------------------------------------------------------------------------------
Post ID:371
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-27 20:36:03
Subject:RE: [rest-discuss] security of callbacks
Message:

I don't understand your point.  There _do_ exist real security concerns, though
they're not the same as incompetent admins think.

> Lucas Gonze wrote:
>
> > Right, and it is correct to blow off incompetent adminbots.  We should be
> > designing for competent adminbots.  They do exist.
>
> Go ahead and design for them, Lucas.  Give them nobs to twiddle.
> I've been down
> that road, and from a technology adoption perspective IMO it's uninteresting.
>
> jb







-----------------------------------------------------------------------------------
Post ID:372
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-27 20:37:01
Subject:RE: [rest-discuss] a proposal for secure notifications
Message:

I note that PSP is, in practice, unidirectional.  :)

> The care and thought put into your PSP won't mean squat to a corporate
> sysadmin. And on reflection I do think that practically speaking,
> unidirectional connections provide more safety than paranoid protocol
> implementations. And anyhow, it is pretty easy to set up a single
> unidirectional connection to your "event server" on the Web and let it
> handle the security crap for you.
> 
>  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:373
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-27 20:37:06
Subject:Sub-resources
Message:

How, in general, does one get from a resource to its subordinate
resources? Must the resource use an entity body in a structured format
with HREFs? Is there no "standard" way? If not, why not?

What is the relationship (if any) behind the hierarchy expressed through
"/", "." and ".." and the subordinate resource hierarchy? I think that
there is no explicit relationship. Why do we need two hierarchies?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:374
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-27 20:41:56
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:

Lucas Gonze wrote:
> 
> I note that PSP is, in practice, unidirectional.  :)

PSP is unidirectional in the wrong way. I presume that's the source of
your smiley face.

As strongly as you feel about this principle of the client not revealing
anything to the server, I feel that a real end-user client should not be
running software that accepts TCP connections from unknown parties. So I
feel that tunnelling is not only inevitable but a Good Thing. And I
think that Joe Firewall is more in line with my view than yours.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:375
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-27 21:21:00
Subject:Re: [rest-discuss] security of callbacks
Message:

Paul Prescod wrote:

> On an unrelated note, I am curious whether you know who coined the term
> "resource modelling."

I beat him to it by almost two weeks:

    http://www.xent.com/pipermail/fork/2001-August/002923.html

It's a curse.  I'm a jargon machine. ;-)

jb








-----------------------------------------------------------------------------------
Post ID:376
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-27 21:50:09
Subject:Semi-Proxies, Transparent Tunnels, and The Switchboard Pattern
Message:

First draft for comment, hope the HTML doesn't screw anyone up.
If it does, let me know, I'll resend text-only.

ABSTRACT

The Web is a global information namespace and generic resource
interface superimposed on a degree-one network of nodes which can
connect to each other.  Directionality of requests and responses
is today unfortunately intimately entangled with directionality
of connectivity, and due to firewalls connectivity is
asymmetric.  This is unfortunate because interesting addressible
resources potentially exist on *all* nodes.  The value of the Web
as a whole is therefore seriously and unnecessarily constrained
by the asymmetry of connectivity.

This document ("speclet") is a high-level description of two
architectural additions to the Web which, taken together, provide
a principled solution to the problem of asymmetric connectivity
and therefore allow all nodes in the network to present resources
to all other nodes.  The two components are a new intermediary
type called a "semi-proxy"  and a new connector type called a
"transparent tunnel."  These two components may be used together
in a "switchboard pattern" to provide securable, apparent
universal symmetry of connectivity within the context of the
principled Web architecture.

TERMINOLOGY

Rather than referring to client and server roles, let's describe
the Web as consisting of open and closed nodes.  Open nodes are
those that can receive inbound connections from some other nodes
of interest;  i.e., they are typically "outside" a firewalled
environment.  Closed nodes are those nodes that cannot receive
inbound connections from some other nodes of interest, but can
initiate connections to other nodes of interest;  they are
typlically "behind" a firewall.  A node's open or closed state is
referred to as its connectivity.  It is desirable to consider
connectivity as orthogonal to the role a node may play in
generating or servicing HTTP requests.  Any node may therefore
serve as a requestor or respondor.  A requestor is a node which
initiates an HTTP 1.1 request.  A respondor accepts HTTP requests
and generates HTTP responses.

A note about synchrony:  HTTP is a synchronous protocol;  each
HTTP request results in a synchronous / immediate response.  Many
application communication patterns benefit from asynchrony;  this
is usually referred to as "event notification."  Overcoming
asymmetry of connectivity is an orthogonal problem to finding
useful ways to do asynchronous communication over the Web.  This
document does not address asynchrony beyond simply noting that
the switchboard pattern described here provides a mechanism for
delivery of asynchronous notifications of any kind to any and all
nodes, regardless of their connectivity.  It should also be noted
that the switchboard pattern described here does not assume or
anticipate any sort of request queuing mechanism, though neither
does it prevent one from being implemented.  The implications of
asynchrony, queuing, and request fan-out are out of scope.

THE SEMI-PROXY

The semi-proxy component is an HTTP 1.1 responder and
intermediary which hosts a hierarchical resource namespace.  It
presents a resource model which allows other nodes to "adopt" a
subtree in its resource namespace.  This process is called
registration.  Once a node has registered a particular subtree,
requests received by the switchboard for resources in that
subtree are "forwarded" to the registered node.  The precise
mechanism by which this happens is undefined, however, in the
simplest case a new request is constructed by reformulating the
request URI relative to the registered node and generating a new
HTTP request to the registered node.  The reverse path is taken
by the response, from registered node through the semi-proxy to
the original requestor.  The only function the semi-proxy
provides that differentiates it from a standard proxy is a
standard transformation between the registered node's address
space and the semi-proxy's address space.

With the exception of transformations on these URI, this
resembles the action of a standard HTTP proxy.  The semi-proxy
MAY perform all the same operations as any proxy with respect to
caching, handling idempotent operations, etc.  The net effect of
the semi-proxy is to allow some other node to present resources
as if they were in fact resources within the switchboard's own
portion of the global resource namespace.

Note that the relationship between registered nodes and
registered subtrees of the semi-proxy's address space is assumed
for simplicity's sake to be 1-1.  Fan-out to multiple registered
nodes is an interesting concept with interesting implications for
various applications, but is beyond the scope of this document.
Addressing such a fan-out begins to verge on event notification,
and is an interesting topic that needs further discussion and
consideration.

A semi-proxy SHOULD have a standard semantics for longevity of a
given registration.  The ability of the semi-proxy to route
requests and responses to and from the registered node depends on
its ability to communicate with the registered node.  Without
addressing asynchronous communication, this implies that each
registration should be bounded in some fashion, either by the
maintenance of a transparent tunnel connection as discussed below
or by some other heuristic.

TRANSPARENT TUNNELS

A transparent tunnel is new architectural connector type
consisting of a persistent HTTP connection established from a
closed node to some open node.  It takes the form of a long-lived
GET request performed on some resource on the open node.  This
connection is used to bidirectionally pass HTTP requests and
their responses between closed and open node, irregardless of
directionality of connectivity.  Appropriate conventions for
framing and mux / demux of HTTP requests and their responses is
assumed.  The closed node end of the tunnel is referred to as the
tail end;  the open node end is referred to as the head end.
Requests arriving at the head end of the tunnel are transported
to the tail end of the tunnel, where they may be unpacked and
serviced by any appropriate mechanism.  This mechanism could be
embedded in an HTTP responder directly, or could be an adaptor
which turns these requests into standard HTTP requests /
connections to a local or remote HTTP responder.

The tunnel is "transparent" in that what it transports are simply
HTTP requests and responses.  A transparent tunnel is thus
securable via any standard security intermediary which is made
aware of the framing and mux / demux conventions used by the
tunnel.  With transparent tunneling of HTTP through HTTP, we have
the best of both worlds:  intermediaries which are aware of the
tunneling conventions and standard HTTP semantics may filter and
secure these requests as would any secure proxy.

THE SWITCHBOARD PATTERN

By coupling semi-proxies and transparent tunneling we are able to
instantiate a "switchboard pattern" for principled symmetric HTTP
connectivity.  Every node - whether closed or open - becomes an
equal participant in the resource namespace.  The switchboard
provides the semi-proxy resource model for registering a subtree
of its address space, and a second resource model for
establishing the head-end of the transparent tunnel.  It then
routes HTTP requests it receives across the appropriate tunnel
connection, and reverses the route for HTTP responses to those
requests.

The benefits of the switchboard pattern are many.  Aside from
simply addressing asymmetry of connectivity, switchboards also
provide a mechanism for dealing with ephemeral naming of edge
machines.  A switchboard can provide a persistent (modulo
connectivity) namespace for an edge node's resources, despite the
fact that the edge machine may only temporarily have a particular
DNS name or IP address.

CONCLUSION

The introduction of two new connector types - semi-proxies and
transparent tunnels - to the principled architecture of the Web
enables a much richer resource space and increases the overall
value of the Web.  These two connector types may be paired in a
"switchboard pattern" that mitigates the impact of asymmetrical
connectivity on the overall architecture of the Web, and provides
a means of dealing with the ephemeral nature of host naming at
the edges of the network.







-----------------------------------------------------------------------------------
Post ID:377
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-27 23:05:45
Subject:Re: [rest-discuss] security of callbacks
Message:


Lucas Gonze wrote:

> I don't understand your point.  There _do_ exist real security concerns, though
> they're not the same as incompetent admins think.

My point is this:  there are two general strategies for dealing with security
considerations vis-a-vis new technology that has to cross administrative
boundaries.  The first strategy is to try to anticipate and a priori build for the
security concerns of the admins by giving them all the "knobs" (controllable
security features) they think they want and need.  From bitter experience, this
strategy is a loser;  even if you give them every knob you think or they claim they
want, that still means they have to buy into *actually* twiddling those knobs in
order for your technology to proliferate.  And they just won't buy into installing
and twiddling new knobs, most of the time.  Running a new protocol on a new port is
an example of giving them a trivial knob that they'll refuse to twiddle.

The second strategy is to subvert the existing security infrastructure in such a
way that only onerous administrative security measures can prevent short-term
proliferation of your technology.  (Ab)using HTTP is the preferred way to do this;
they can't shut down all Web access, so they have to block specific hosts.  Often
this is more trouble than its worth.  The more decentralized your system, the
better off you are;  if they can't shut down particular hosts, then their filtering
apparatus has to gain explicit knowledge of your application in order to block it.

The mechanism I'm proposing is really the second, but with some sugar thrown in for
the competent admin.  Tunneling HTTP through HTTP allows security vendors to
*eventually* incrementally modify their intermediary products to filter traffic at
an application semantic level;  the change is incremental because, after all, it's
just HTTP.  However, it's going to take time for them to develop and deploy that on
an application by application basis.  Hence the admin function can't adversely
impact the network effects that drive rapid takeoff and proliferation of any given
new application.

jb








-----------------------------------------------------------------------------------
Post ID:378
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-28 01:10:03
Subject:Re: [rest-discuss] Sub-resources
Message:

> How, in general, does one get from a resource to its subordinate
> resources?

Assertions.  They can take several forms;

- query forms
- via HTTP headers (e.g. Location on a 201 response)
- other assertions - documents that authoritatively declare resource
  relationships, of which "subordinate" is one type of relationship,
  such as through a GET

> Must the resource use an entity body in a structured format
> with HREFs?

No.

> Is there no "standard" way? If not, why not?

Different types of assertions happen in different contexts with
different syntaxes.

> What is the relationship (if any) behind the hierarchy expressed through
> "/", "." and ".." and the subordinate resource hierarchy?

"." and ".." only has special meaning when used in a relative URI.

"/" can be used for exposing subordinates, but that decision can only
be made by the publisher.  A third party seeing a /foo/bar URI can't
assume that bar is a subordinate of foo.  But it's good practice for
a publisher to use this structure as a canonical URI when it might be
important for the container to be used as a base URI.  (that was a
sneak peek from my opacity study)

> I think that
> there is no explicit relationship. Why do we need two hierarchies?

What two?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:379
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 03:50:19
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

On Fri, 25 Jan 2002, S. Mike Dierken wrote:
> If you do a POST to do a DELETE, firewalling/caching don't work so good.

Can you explain this one?  Once you're changing
state, you're changing state....

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:380
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 04:03:04
Subject:Re: [rest-discuss] ironport.com
Message:

On Fri, 25 Jan 2002, Paul Prescod wrote:
> "AsyncOS is optimized for
> asynchronous tasks like Internet
> Messaging. AsyncOS includes a unique
> new file system, an I/O-driven scheduler,
> and a revolutionary new threading model."
>
> What's an "asynchronous task?" One where the server doesn't send back an
> answer until later? How would you optimize an operating system for such
> a task?

Get rid of preemptive threads.  Do explicit
yields.  See:
http://www.nightmare.com/~rushing/copython/index.html
and
http://www.nightmare.com/medusa/medusa.html

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:381
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 04:19:06
Subject:Re: [rest-discuss] ironport.com
Message:



"S. Alexander Jacobson" wrote:

> Get rid of preemptive threads.  Do explicit
> yields.  See:
> http://www.nightmare.com/~rushing/copython/index.html
> and
> http://www.nightmare.com/medusa/medusa.html

Python 2.2 adds explicit support for generators with the introduction of the
yield statement.  [1]  A generator looks like and is similar to a function,
with some important differences;  it is similar in many ways to the concept of
a monad from functional languages.  They are sort of anti-idempotent:  a
generator reifies a potentially infinite stream as a function upon which
sucessive calls which yield sucessive values from the stream.  This is a great
language-level feature that makes modeling and using infinite streams much,
much easier.  The same kind of thing can be achieved with explicit
continuations / coroutines, but IMO generators are much simpler and more
intuitive.  They're also a good step towards unifying a number of related
concepts, namely functions, streams, and objects.

$0.02,

jb

[1] http://python.sourceforge.net/peps/pep-0255.html








-----------------------------------------------------------------------------------
Post ID:382
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-28 04:24:34
Subject:RE: [rest-discuss] a proposal for secure notifications
Message:

> As strongly as you feel about this principle of the client not revealing
> anything to the server,

It's not how I "feel", it's the bedrock of security design.  Information leaks
are the source of exploits, period.

> I feel that a real end-user client should not be
> running software that accepts TCP connections from unknown parties. So I
> feel that tunnelling is not only inevitable but a Good Thing. And I
> think that Joe Firewall is more in line with my view than yours.

Uh, we might have a disagreement if you had a point to disagree with.  Let's
hear it, shorty.









-----------------------------------------------------------------------------------
Post ID:383
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-28 04:24:40
Subject:RE: [rest-discuss] a proposal for secure notifications
Message:

> One way to address security is to differentiate between "ordinary"
> callbacks and "secure" callbacks. Ordinary callbacks are like SMTP. No
> more or less secure. No paranoia.
>
> "Secure" callbacks are created ONLY on a persistent connection created
> from the client to the server, potentially using SSL.
>
> Let's face it, that's corporate America's definition of secure
> behind-the-firewall software. Outgoing is secure. Incoming is insecure.
> So secure callbacks would work just like MSN messenger or ICQ or
> Napster, you turn the thing on, it "calls home" and opens a connection.

Non-secure callbacks via a full HTTP server would quickly lead to a parade of
serious vulnerabilities.  If you feel that it wouldn't have to be a full HTTP
server, then you are agreeing with my main point.

SSL callbacks would add complexity, expose the server, increase ability to DoS,
increase the number of possible holes.  It completely fails to solve the
problem.

> Insofar as the client knows what server it has contacted, the security
> requirements are much lower.
> After all, Web browsers have historically
> been terribly insecure but the practical damage caused by them is low
> because the end-user controls what sites he/she contacts. So
> accountability is pretty good ("here's the URL of the site that deleted
> my hard drive") and it is really hard to get a million users to come to
> your site and download your virus.

I can see that you didn't put time into understanding what I wrote, because that
is 90% of my point.  The PSP algorithms piggybacks notification security on the
existing security of HTTP client requests.

> The care and thought put into your PSP won't mean squat to a corporate
> sysadmin. And on reflection I do think that practically speaking,
> unidirectional connections provide more safety than paranoid protocol
> implementations. And anyhow, it is pretty easy to set up a single
> unidirectional connection to your "event server" on the Web and let it
> handle the security crap for you.

Sorry, you need to explain what you mean by unidirectional.  You mean that a
client which wishes to receive events must connect to a presence server a la
KnowNow?  That is a non-starter.  No chance.  The resources are right there on
the client.  You mean that if the accounting web server wants to send an event
to Joe the Accountant in the next cube they have to rendezvous at the KN router
in California?










-----------------------------------------------------------------------------------
Post ID:384
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 04:37:16
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:


Lucas Gonze wrote:

> Sorry, you need to explain what you mean by unidirectional.  You mean that a
> client which wishes to receive events must connect to a presence server a la
> KnowNow?  That is a non-starter.  No chance.  The resources are right there on
> the client.  You mean that if the accounting web server wants to send an event
> to Joe the Accountant in the next cube they have to rendezvous at the KN router
> in California?

I cannot stress to you strongly enough that any *other* approach --- such as getting
administrators to explicitly configure a firewall to allow your new PSP callback
protocol through --- is an absolute non-starter.  This isn't speculation, this is
hard-won experience.  We tried it.  It did not work.  We beat our heads against this
at Activerse for a *long* time.  Unfortunately, protocol evolution effectively ended
with HTTP, and indeed the whole notion of the TCP service <--> port address space is
effectively on the way out.  Today we have to deal with a single protocol on a
single port and we have to deal with asymmetrical connectivity as a result of
firewalls.  Fortunately, that's okay, because we can (a) build any application we
want using HTTP, and (b) address asymmetry though principled and compatible
extensions of the REST architecture that simply build on what we've already got.

If you want to pursue some other course, feel free to.  You may get some uptake in
situations where you don't have to deal with firewalls, but in the enterprise you
will gain no traction whatsoever if you require the network admins to touch their
existing firewall configurations.  Ultimately, you're going to have to burrow out
through port 80 to something that is effectively a rendezvous server.  Having been
down the losing path once before, I'm in favor of just skipping that frustrating and
fruitless exploration this time around and just figuring out how to tunnel while
preserving the end-to-end semantics of HTTP 1.1.

jb








-----------------------------------------------------------------------------------
Post ID:385
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 04:47:00
Subject:Re: [rest-discuss] Sub-resources
Message:


Mark Baker wrote:

> But it's good practice for
> a publisher to use this structure as a canonical URI when it might be
> important for the container to be used as a base URI.  (that was a
> sneak peek from my opacity study)

Mark, does your study provide a normative set of conventions that inform the
problem of resource modeling?  IME, it seems that half the job is naming
things, and I've sort of been picking at a kind of grammatical approach to
building URI that in turn seems to lead to good resource models.  My own work
on this isn't very mature at this point, but it would be great if such a set
of guidelines existed. :-)

When can we see your opus?

jb








-----------------------------------------------------------------------------------
Post ID:386
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-28 04:58:39
Subject:RE: [rest-discuss] a proposal for secure notifications
Message:

> I cannot stress to you strongly enough that any *other* approach ---
> such as getting
> administrators to explicitly configure a firewall to allow your new
> PSP callback
> protocol through --- is an absolute non-starter.

I am not suggesting that approach.  Far from it.  I have said *nothing* of the
kind.  And I wish you would work through the implications correctly before
attacking implications I have not made.

All existing ideas on how to do callbacks have centered on a callback URI.
There's a source that has an event to post, to make that happen it sends some
bytes to the sink callback URI; the sink is running a server on the callback
IP:port.  This is exactly the same in PSP as in full scale HTTP 1.1.   In fact,
neither can pass through the firewall.

Firewalls are a completely separate conversation.  PSP is merely and only a
means of implementing callbacks without introducing new security problems.

(Uh, actually there's one tiny difference between UDP and TCP servers for the
purposes of breaking into the firewall -- UDP can sometimes pass through NATs.
That's a trivial difference that isn't consistently enough available to care
about, which is why I didn't mention it.)







-----------------------------------------------------------------------------------
Post ID:387
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-28 05:06:49
Subject:RE: [rest-discuss] a proposal for secure notifications
Message:

And as a general point, I'd appreciate a more collegial atmosphere.  It's not a
shooting gallery.  I'm not selling insurance.  I spent a couple days analyzing a
big problem created by the standard model (the problem being that using
callbacks to post event notifications opens large security holes) and proposed a
simple solution.  It does no good to say that large security problems don't
matter -- they do -- or to snipe at implications like reverse firewall traversal
which (1) are based on incorrect understanding and (2) I didn't make.
















-----------------------------------------------------------------------------------
Post ID:388
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 05:49:49
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:


Lucas Gonze wrote:

> I am not suggesting that approach.  Far from it.  I have said *nothing* of the
> kind.  And I wish you would work through the implications correctly before
> attacking implications I have not made.

I have --- I'm not sure you've thought through the implications. ;-)

What port is PSP going to run on?  How is an event source going to communicate with
the callback sink?  What happens if the sink is on the other side of the firewall?

> All existing ideas on how to do callbacks have centered on a callback URI.
> There's a source that has an event to post, to make that happen it sends some
> bytes to the sink callback URI; the sink is running a server on the callback
> IP:port.  This is exactly the same in PSP as in full scale HTTP 1.1.   In fact,
> neither can pass through the firewall.

This is absolutely true.

> Firewalls are a completely separate conversation.  PSP is merely and only a
> means of implementing callbacks without introducing new security problems.

I think it solves a non-problem.  The only justification for PSP as a separate
protocol from HTTP is to put it on another port where it can be separated from and
processed independently of HTTP for the purpose of securing administrative
boundaries.  If not that purpose, there's no point in introducing a separate
protocol.

> (Uh, actually there's one tiny difference between UDP and TCP servers for the
> purposes of breaking into the firewall -- UDP can sometimes pass through NATs.
> That's a trivial difference that isn't consistently enough available to care
> about, which is why I didn't mention it.)

Activerse's event protocol was UDP-based.  This was problematic.

jb









-----------------------------------------------------------------------------------
Post ID:389
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 05:57:26
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:


Lucas Gonze wrote:

> And as a general point, I'd appreciate a more collegial atmosphere.  It's not a
> shooting gallery.  I'm not selling insurance.

I'm not sure.  Think about it. ;-)

> I spent a couple days analyzing a
> big problem created by the standard model (the problem being that using
> callbacks to post event notifications opens large security holes) and proposed a
> simple solution.  It does no good to say that large security problems don't
> matter -- they do -- or to snipe at implications like reverse firewall traversal
> which (1) are based on incorrect understanding and (2) I didn't make.

Hey, man, we're on the same side.  I'm just trying to let you know that the logical
conclusion of the path you're currently exploring is a dead-end --- seriously, I'm
just trying to save you some frustration.  You've thought about these issues for
what, a few days?  I spent about three years struggling through *specifically* all
of this, several years ago, and it seriously cost me some hair.

I'm not sniping at implications like reverse firewall traversal --- I'm pointing out
a *fundamental problem* with the introduction of any new protocol on any new port
that is intended to touch edge machines.  It doesn't make sense to run HTTP 0.9 /
PSP on port 80, of course, therefore the implication in your PSP suggestion is that
you are introducing a new protocol on a new port.  That ain't gonna work, bro.  :-)
Trust me on this one.

Regardless of which port it runs on, you've expressed an interest in allowing
clients to receive notifications.  This *implies* that whatever solution you have
needs to cross firewalls.  Since PSP doesn't run on port 80, this means you assume
you're going to go out and convince all the network admins of the world to open up
your PSP port to allow for inbound traffic on your innocuous protocol.  Even if it
did run on port 80, you've still got to convince them to allow inbound to all your
edge machines.  Well, that just isn't going to happen.  You're designing a solution
that cannot be deployed in the environment into which it needs to be deployed.

I'm on your side, but I don't think *you've* thought through the practical
implications of what you're proposing.  It may be a nice, elegant solution to a
problem, but an elegant solution that can't be deployed isn't very useful.  And it
may not be the only or most elegant solution.

$0.02, and peace,

jb










-----------------------------------------------------------------------------------
Post ID:390
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 06:19:16
Subject:What is a notification?
Message:

Lucas' analysis of the security problems with callbacks rests on
a fundamental assumption that I think might be flawed.  In order
to illustrate this, we have to ask:  what is a notification?

Lucas assumes that a notification is a delayed, asynchronous
response to a particular HTTP request.  Hence, a sink must expose
only as much state to the source as a client would ordinarily
expose to a server.  That's fine, *iff* you accept that
notifications are the continuation of the original request.  When
we consider notifications this way, what we're doing is
fundamentally introducing asynchrony *into* the HTTP
request-response cycle.  This certainly doesn't seem to be very
RESTful, IMHO.  (Neither does introducing asymmetric protocols
for generating a request and receiving a later response.)

That's not the only way to think about asynchrony, though.  A
more HTTP-friendly way to think about asynchrony is to consider
the initial subscription request / response cycle to be related
to the establishment of a subscription.  That is, it is a request
in itself, an entirely valid one which talks about the
subscription being established.  The response is related to the
subscription abstraction as well.  Later notifications ---
requests to the sink --- are not conceptually the continuation of
the original request, but rather subsequent data-providing
requests.  They are related to but semantically (mostly)
independent of the request-response cycle that established the
subscription.  They do pose a greater security risk than a
single, simple client-server request-response cycle.  But that's
a necessary risk that we have to accept and manage if we are to
allow edge machines to publish resources.  Any solution,
including an asymmetric response protocol, introduces new risks
that must be managed.

IMO, the latter is the appropriate approach --- asynchrony and
the notification abstraction live at the level of abstraction of
resources;  it's about resources communicating with each other.
Resources can communicate asynchronously, without changing the
synchronous semantics of HTTP.  We can leave that alone, and
still build asynchronous communication patterns between resources
on top of it.

Just a bit more musing on the topic, ciao...

jb












-----------------------------------------------------------------------------------
Post ID:391
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 06:34:32
Subject:Re: [rest-discuss] ironport.com
Message:

Yup.  That's why they are using python where they
can (and tuning the OS to support).

-Alex-

On Sun, 27 Jan 2002, Jeff Bone wrote:

>
>
>
> "S. Alexander Jacobson" wrote:
>
> > Get rid of preemptive threads.  Do explicit
> > yields.  See:
> > http://www.nightmare.com/~rushing/copython/index.html
> > and
> > http://www.nightmare.com/medusa/medusa.html
>
> Python 2.2 adds explicit support for generators with the introduction of the
> yield statement.  [1]  A generator looks like and is similar to a function,
> with some important differences;  it is similar in many ways to the concept of
> a monad from functional languages.  They are sort of anti-idempotent:  a
> generator reifies a potentially infinite stream as a function upon which
> sucessive calls which yield sucessive values from the stream.  This is a great
> language-level feature that makes modeling and using infinite streams much,
> much easier.  The same kind of thing can be achieved with explicit
> continuations / coroutines, but IMO generators are much simpler and more
> intuitive.  They're also a good step towards unifying a number of related
> concepts, namely functions, streams, and objects.
>
> $0.02,
>
> jb
>
> [1] http://python.sourceforge.net/peps/pep-0255.html
>
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:392
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-28 06:38:03
Subject:Re: [rest-discuss] ironport.com
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> > What's an "asynchronous task?" One where the server doesn't send back an
> > answer until later? How would you optimize an operating system for such
> > a task?
> 
> Get rid of preemptive threads.  Do explicit
> yields.  See:
> http://www.nightmare.com/~rushing/copython/index.html
> and
> http://www.nightmare.com/medusa/medusa.html

So how is this optimization specific to "asynchronous messaging" and not
equally applicable to standard web serving (for example).

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:393
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 06:47:47
Subject:Re: [rest-discuss] ironport.com
Message:

On Sun, 27 Jan 2002, Paul Prescod wrote:
> So how is this optimization specific to "asynchronous messaging" and not
> equally applicable to standard web serving (for example).

It may be... e.g the Medusa httpd.
However, they are developing mail servers.

-Alex-


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:394
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-28 08:15:12
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:

Lucas Gonze wrote:
> 
> ...
> 
> Non-secure callbacks via a full HTTP server would quickly lead to a parade of
> serious vulnerabilities.  

I dispute this for two reasons. First, there is no requirement for a
full HTTP server. So even if your statement is literally true, I don't
think it is applicable. An event handerl only has to accept POSTs to
pre-ordained URIs in a pre-ordained format with simple, pre-ordained
semantics. They won't generally be running CGIs which is where most HTTP
server exploits come from.

Second, any piece of software that contains an HTTP client without
security flaws can easily contain a mini-HTTP server component with the
same characteristic. Most of the code is the same....parsing MIME
headers, parsing MIME bodies etc. Most of the vulnerabilities are the
same. I don't see how moving the body retrieval to the GET makes much
difference. Yes a little, the code for GET may already exist and be
tested. But most of it is the same.

What vulnerabilities do I see?

 * Callback scanning is worth considering The "port space" is relatively
small. But to find an HTTP server hiding out on a particular URI you
need the IP address, the port number, *and* the correct URI, which could
have a long secret code in it. So I would say that we could change the
spec to allow the HTTP server to ignore requests to non-existent URIs to
make hiding out easier. This will make it practically impossible to use
a brute-force scanning technique to find a callback. You'll have to
search every possible URI on every port on each IP address.

 * Spoofing and man-in-the-middle is another thing worth consideing. I
think that only crypto can prevent this. But there is a price for crypto
so it should be optional. This can be done either in the application
layer (signing payloads) or the socket layer (SSL).

Unless we can agree on the security problem we're trying to solve, I
don't think we'll see eye to eye on the solution. So I'll leave it there
before getting back into the details of your proposed solution. If you
see the vulnerabilities above differently than I do, or want to list
others, please do.

One more issue:

>...
> Sorry, you need to explain what you mean by unidirectional.  You mean that a
> client which wishes to receive events must connect to a presence server a la
> KnowNow?  That is a non-starter.  No chance.  The resources are right there on
> the client.  You mean that if the accounting web server wants to send an event
> to Joe the Accountant in the next cube they have to rendezvous at the KN router
> in California?

Well if they are within a zone of trust, then they might accept
connections from each other directly.

And if they were on opposite side of one or more firewalls then yes,
they would probably each contact a rendezvous machine.

That's how IRC works. And how MSN, POP, and netnews. All of these
require an intermediary. But unlike IRC or MSN or POP, we will preserve
the ability for end-user nodes to connect directly if the hosts trust
each other.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:395
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 08:33:24
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:

If we are talking about a protocol with no reply
defined except OK, isn't that email/SMTP?

In which case the obvious solution is just
to define a notification mime-type and add a
notification handler to your mailcap file.
The protocol would be SMTP to some mail server and
perhaps POP to the client.

The HTTP version looks like this:
1. notifier POSTs email/notification to "mail server"
2. "mail server" replies with 202 Accepted
3. client picks up mail from mail server using GET
4. client processes mail and may initiate new HTTP
	connections

I don't know how you replace the functionality of
MX records....

-Alex-


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:396
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 08:48:57
Subject:Re: Plan 9 explanation for Alex
Message:

Ok.  You claim Plan9 modelled everything as files.
Since namespaces are private.  One could equally
claim that Plan9 modelled everything as messages
to and from file/device owners.

It doesn't sound like a file system.  It sounds
more like a message system in which the primitives
were:

* send (aka write)
* recieve/check for messages (aka read)

The big thing that I don't like about most file
APIs is that they are synchronous stopping your
process while hardware catches up.  It is
semantically more elegant to represent all
IO using asynch interfaces.

It sounds like Plan9 effectively achieved
asynchrony because device owners accepted
messages from client processes and then handled
those messages in a separate process/thread.  The
clients could then asynchronously check for
messages by reading the file.

Very nice.  But I don't see why this is not the
same as sending email to some address and then
checking for email from that address.

-Alex-


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax




On Sat, 26 Jan 2002, Jeff Bone wrote:
> The point of the Plan 9 anecdote is that it stands as an existance proof
> invalidating your claim that parameter passing to a procedure cannot be modeled as
> file IO.  Certainly almost anything --- and maybe *anything* --- that can be modeled
> as parameter passing to a procedure can be modeled as generic stream IO on a file /
> resource.
>
> Plan 9 an example of making various things --- including active "data producing
> processes" --- look like files.  The original idea of UNIX, broken by the
> introduction of sockets, was to make everything look like a file.  Plan 9 was an
> attempt by most of the original authors of UNIX to go back and push that concept to
> the limit, unifying everything as resources (files) in a single namespace sharing a
> single generic stream IO interface.
>
> I bring it up because it's a great example of how to do the *kind* of thing we're
> talking about here, albeit in a different namespace with a different generic
> interface.  It's a *great* case study, though;  I didn't really "get" REST until I
> started thinking about how things are modeled in Plan 9 as an analogy.  (Side note:
> in a private e-mail with Roy Fielding around the time I had my REST gestalt, I
> pointed out the Plan9 analogy;  he claimed that he'd wished he'd been more familiar
> with / had some citations for it a while back --- he apparently agreed with me and
> thought the analogy useful and appropriate.)
>
> > but I am curious how resource synchornization
> > works.  What happens when two apps try to
> > write/read the /net/cs file?  Is it locked?
>
> In Plan 9, every process has a private view of the namespace.  For example:  8 1/2,
> the Plan 9 window system, represents the mouse as /dev/mouse, IIRC.  8 1/2 itself
> handles synchronization and acts as the multiplexer / demultiplexer for events
> generated by this device;  each process sees its own private version of /dev/mouse;
> a process which opens and reads this file will read a stream of only those events
> generated in the window in which the process is running.  In other words, mux and
> sync are generally handled in Plan 9 by whatever "server" presents a given service
> as a resource, in whatever manner is appropriate for that service.
>
> $0.02,
>
> jb
>
>








-----------------------------------------------------------------------------------
Post ID:397
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 09:03:12
Subject:Re: REST Terrorist-Or-Not, and Alex's Objections / Issues
Message:

On Sat, 26 Jan 2002, Jeff Bone wrote:
> > I don't understand why SMTP doesn't do what you
> > want.
>
> This is a *very simple* point.  Listen closely.  It doesn't do what we want it to so
> because it doesn't present as resources that can be interacted with via the generic HTTP
> interface.

What are your thoughts on 202 Accepted?  Was it a
mistake?

> > My answer was show me
> > an application that you can't do with SMTP.
>
> And we did this:  the Web.

You can implement the web with email autoreplies.
e.g.
href="mailto:pageserver@...?subject=/my/page"


-Alex-


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:398
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 09:14:49
Subject:Re: Plan 9 explanation for Alex
Message:


"S. Alexander Jacobson" wrote:

> Ok.  You claim Plan9 modelled everything as files.

It did.  Check it out. :-)

> The big thing that I don't like about most file
> APIs is that they are synchronous stopping your
> process while hardware catches up.  It is
> semantically more elegant to represent all
> IO using asynch interfaces.

Hey, you aren't arguing with me, you're arguing with Dennis Ritchie, Dave Presotta, Rob
Pike, Ken Trickey, etc.  If you feel up to that, that's your call.

> Very nice.  But I don't see why this is not the
> same as sending email to some address and then
> checking for email from that address.

I know, I know.  Mark and the rest of us have a universal hammer called HTTP, and
everything is a nail.  You've got a universal hammer called SMTP, and everything is an
e-mail.

jb








-----------------------------------------------------------------------------------
Post ID:399
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 09:25:12
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections / Issues
Message:


"S. Alexander Jacobson" wrote:

> You can implement the web with email autoreplies.
> e.g.
> href="mailto:pageserver@...?subject=/my/page"

I'm actually willing to concede this point;  in fact I should've before.  The only thing we're
proving here is that synchronous communication can be built on top of an asynch substrate and
vice versa.  This isn't news;  check out the raging debates about the generality of the
message-passing paradigm circa 1987-1988.  Message passing, procedure calling, and dataflow
techniques are all Turing complete.

Your argument fundamentally rests on the assumption --- your own words --- that it is
"semantically more elegant to represent all IO using asynch interfaces."  I can't argue with
that, it's an aesthetic argument.  What I *can* point out is that the Web hosts a greater
variety of applications (though less users and probably less messages) than SMTP.

jb








-----------------------------------------------------------------------------------
Post ID:400
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 09:57:50
Subject:Re: [rest-discuss] Re: Plan 9 explanation for Alex
Message:


"S. Alexander Jacobson" wrote:

> It doesn't sound like a file system.

...trust me, it's more like a file system than any file system you've ever seen.

> It sounds like Plan9

BTW, instead of just guessing at what it did, and how, and why that might be important,
why not go check it out?  Various papers can be had at [1].  IMHO, anybody in the business
of building distributed systems --- and maybe software in general --- that hasn't read
these papers is doing themselves a disservice.  Lots of lessons, there.  It's *absolutely
incredible* how much functionality is packed into such few and simple abstractions and
such little code:  the entire operating system with all bells and whistles is an order of
magnitude smaller than the current X distribution.

Special attention is warranted for [2], [3], [4], [5], and [6].  Anybody doing distributed
filesystem work specifically or protocol design in general should take a detailed look at
the man pages for 9P, the Plan 9 network "file" protocol. [7]

Ciao, and happy hunting.

jb

[1] http://www.cs.bell-labs.com/sys/doc/
[2] http://www.cs.bell-labs.com/sys/doc/9.html
[3] http://www.cs.bell-labs.com/sys/doc/names.html
[4] http://www.cs.bell-labs.com/sys/doc/net/net.html
[5] http://www.cs.bell-labs.com/sys/doc/8%bd/8%bd.html
[6] http://www.cs.bell-labs.com/sys/doc/plumb.html
[7] http://www.cs.bell-labs.com/sys/man/5/INDEX.html








-----------------------------------------------------------------------------------
Post ID:401
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 16:27:04
Subject:Re: Plan 9 explanation for Alex
Message:

On Mon, 28 Jan 2002, Jeff Bone wrote:
> > Ok.  You claim Plan9 modelled everything as files.
>
> It did.  Check it out. :-)

I know.  I did.  I just think calling it a "file"
interface is a misnomer.  One could also argue
that it is closer to Linda...

> > The big thing that I don't like about most file
> > APIs is that they are synchronous stopping your
> > process while hardware catches up.  It is
> > semantically more elegant to represent all
> > IO using asynch interfaces.
>
> Hey, you aren't arguing with me, you're arguing with Dennis Ritchie, Dave Presotta, Rob
> Pike, Ken Trickey, etc.  If you feel up to that, that's your call.

I'm not actually arguing with what they did at the
time.  I asked Reiser about this issue and he
largely agreed, but said it was too late to
change.

Callbacks allow the OS better to optimize writes
and do interesting caching.

Think about all the annoying issues with
applications that expect a local filesystem and
run into issues because NFS is much less reliable.

See Gosling on network transparency.
Also see the design of O'Haskell
  http://www.google.com/search?hl=en&q=ohaskell

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:402
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 16:31:25
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections / Issues
Message:

On Mon, 28 Jan 2002, Jeff Bone wrote:
> Your argument fundamentally rests on the assumption --- your own words --- that it is
> "semantically more elegant to represent all IO using asynch interfaces."  I can't argue with
> that, it's an aesthetic argument.  What I *can* point out is that the Web hosts a greater
> variety of applications (though less users and probably less messages) than SMTP.

Gosling's homepage points to good reasons why
asynch interfaces are better:
   http://java.sun.com/people/jag/Fallacies.html

What happens with HTTP when you can't reach the
server?

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:403
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-28 17:04:43
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:

"S. Alexander Jacobson" wrote:
> 
> If we are talking about a protocol with no reply
> defined except OK, isn't that email/SMTP?

Lucas wants no reply. Period.

> In which case the obvious solution is just
> to define a notification mime-type and add a
> notification handler to your mailcap file.
> The protocol would be SMTP to some mail server and
> perhaps POP to the client.

POP is pull. We're trying to do asynch notifications.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:404
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 17:07:14
Subject:Re: Plan 9 explanation for Alex
Message:


"S. Alexander Jacobson" wrote:

> Think about all the annoying issues with
> applications that expect a local filesystem and
> run into issues because NFS is much less reliable.

That's an issue with NFS.

> See Gosling on network transparency.
> Also see the design of O'Haskell
>   http://www.google.com/search?hl=en&q=ohaskell

Cf. Waldo:

http://research.sun.com/techrep/1994/abstract-29.html

jb








-----------------------------------------------------------------------------------
Post ID:405
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 17:08:29
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections/ Issues
Message:


"S. Alexander Jacobson" wrote:

> What happens with HTTP when you can't reach the
> server?

What happens when SMTP can't deliver the message?

Alex, I'm done with this conversation.  We're arguing over whether chocolate is better than
vanilla, over whether Mighty Mouse can beat up Superman.  There's no margin in it.

jb








-----------------------------------------------------------------------------------
Post ID:406
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 17:20:27
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections/ Issues
Message:

On Mon, 28 Jan 2002, Jeff Bone wrote:
> "S. Alexander Jacobson" wrote:
> > What happens with HTTP when you can't reach the
> > server?
> What happens when SMTP can't deliver the message?

It keeps trying.  There is a whole section in the
RFC on Retry.  HTTP does not define a retry
policy.

> Alex, I'm done with this conversation.  We're arguing over whether chocolate is better than
> vanilla, over whether Mighty Mouse can beat up Superman.  There's no margin in it.

I'm not so sure.  I bought into the zen of loose
coupling in REST.  I am hoping you will see the
bonus in asynch.  I think the two are very
complimentary.

But whatever, I'll drop it if you want.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:407
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-28 17:21:51
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections / Issues
Message:

Jeff Bone wrote:
> 
> "S. Alexander Jacobson" wrote:
> 
> > You can implement the web with email autoreplies.
> > e.g.
> > href="mailto:pageserver@...?subject=/my/page"
> 
> I'm actually willing to concede this point;  in fact I should've before.  The only thing we're
> proving here is that synchronous communication can be built on top of an asynch substrate and
> vice versa.  

In theory you could build the Web on SMTP. But you would have to
implement and deploy SMTP in a radically different way. You would need a
way to give messages priority so that results could seem interactive.
You would also need to extend SMTP to the desktop to eliminate
unncessary remote intermediaries. And of course you would need to layer
all of HTTP's semantics on top of SMTP.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:408
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 17:25:08
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:

On Mon, 28 Jan 2002, Paul Prescod wrote:
> "S. Alexander Jacobson" wrote:
> >
> > If we are talking about a protocol with no reply
> > defined except OK, isn't that email/SMTP?
>
> Lucas wants no reply. Period.
>
> > In which case the obvious solution is just
> > to define a notification mime-type and add a
> > notification handler to your mailcap file.
> > The protocol would be SMTP to some mail server and
> > perhaps POP to the client.
>
> POP is pull. We're trying to do asynch notifications.

Understood.  Jeff's generbending spec and the
solution I prosposed at the bottom of my prior
email try to reach a compromise.

The gist of the compromise is to use HTTP to
deliver asynch to a message server.  This message
server can be secured as much as lucas wants.
(Or we can reuse the existing mail server).

If the app lives on the mailserver then the
notification is handled immediately.


If the app lives on a client behind the firewall,
then it maintains either a persistent GET or a POP
connection to the mailserver and recieves messages
when they arrive.

(Yes, I know POP is polling, but that is
irrelevant in this discussion -- actually it is
an argument if favor of persistent GET -- thanks
Jeff!).

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:409
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-28 17:26:07
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections/ Issues
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> Gosling's homepage points to good reasons why
> asynch interfaces are better:
>    http://java.sun.com/people/jag/Fallacies.html

He says nothing about asynch.

> What happens with HTTP when you can't reach the
> server?

SMTP is fundamentally synchronous. The client connects to the server.
They do some TCP negotiations and then some SMTP negotiations. When they
are both happy they quit. I would be more impressed if you compared HTTP
to UDP.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:410
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 17:29:22
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections / Issues
Message:

On Mon, 28 Jan 2002, Paul Prescod wrote:
> In theory you could build the Web on SMTP. But you would have to
> implement and deploy SMTP in a radically different way. You would need a
> way to give messages priority so that results could seem interactive.

Not a problem mailserver to mailserver.

> You would also need to extend SMTP to the desktop to eliminate
> unncessary remote intermediaries.

That is why I like the idea of using persistent
GET on the last hop instead of POP....  However,
you could also just use a more pipelined smtp
relay implementation to get the
appropriate speed.

> And of course you would need to layer
> all of HTTP's semantics on top of SMTP.

Not clear, but I don't need to argue this.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:411
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-28 17:29:27
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> >
> > POP is pull. We're trying to do asynch notifications.
> 
>...
> The gist of the compromise is to use HTTP to
> deliver asynch to a message server.  This message
> server can be secured as much as lucas wants.
> (Or we can reuse the existing mail server).

As usual, I don't see what SMTP brings to the table. It doesn't satisfy
Lucas' extreme requirements and it doesn't simplify anything.

> ...
> If the app lives on a client behind the firewall,
> then it maintains either a persistent GET or a POP
> connection to the mailserver and recieves messages
> when they arrive.

What does POP supply that HTTP wouldn't? Just a gateway to legacy
clients?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:412
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 17:34:02
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections/ Issues
Message:

On Mon, 28 Jan 2002, Paul Prescod wrote:
> > Gosling's homepage points to good reasons why
> > asynch interfaces are better:
> >    http://java.sun.com/people/jag/Fallacies.html
>
> He says nothing about asynch.

It was waldo, not Gosling.  (thanks Jeff again)
Also see the Peter Deutch page at the URL above.

The point is that synchronous implementations need
to block for indeterminate amounts of time to
handle network problems.  This leads to bad
application behavior (think about how the old
browsers used to lock up while doing DNS lookup)

> > What happens with HTTP when you can't reach the
> > server?
>
> SMTP is fundamentally synchronous. The client connects to the server.
> They do some TCP negotiations and then some SMTP negotiations. When they
> are both happy they quit. I would be more impressed if you compared HTTP
> to UDP.

No SMTP is fundametally asynchronous.
Applications hand of messages to an SMTP MTA
(message transfer agent).  The MTA then deals with
delivery on its own time and delivers messages
back to applications when they arrive.

The TCP/UDP issue is orthogonal (about delivery
errors -- even on fast connections).

-Alex-



___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:413
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 17:36:11
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:

> > The gist of the compromise is to use HTTP to
> > deliver asynch to a message server.  This message
> > server can be secured as much as lucas wants.
> > (Or we can reuse the existing mail server).
>
> As usual, I don't see what SMTP brings to the table. It doesn't satisfy
> Lucas' extreme requirements and it doesn't simplify anything.

People already maintain secured mail servers.
Mail gets past the firewall.
Mail looks a lot like Lucas' protocol.

> > ...
> > If the app lives on a client behind the firewall,
> > then it maintains either a persistent GET or a POP
> > connection to the mailserver and recieves messages
> > when they arrive.
>
> What does POP supply that HTTP wouldn't? Just a gateway to legacy
> clients?

As I said, I like the persistent GET better than
POP (lower latency and no-polling).  I am just
making an architectural observation.


-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:414
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-28 17:43:33
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections/Issues
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> The point is that synchronous implementations need

There is a big difference of synchronous implementations and
implementations of synchronous protocols. 

 http://www.nightmare.com/medusa/

>...
> No SMTP is fundametally asynchronous.
> Applications hand of messages to an SMTP MTA
> (message transfer agent).  

That is application architecture. The protocol itself is synchronous.
The client can't hang up until the server says OK. As we've discussed at
length, you can build a similar application architecture for HTTP
easily.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:415
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-28 17:45:52
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> People already maintain secured mail servers.

One of my points to Lucas was that people also already maintain secured
HTTP servers.

> Mail gets past the firewall.

HTTP traffic gets past the firewall (or at least to it).

> Mail looks a lot like Lucas' protocol.

Not really. ;) And anyhow, his protocol was meant to be used to
end-nodes, not to the intermediaries.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:416
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 17:57:47
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections/Issues
Message:


"S. Alexander Jacobson" wrote:

> > What happens when SMTP can't deliver the message?
>
> It keeps trying.

Forever?  I think not.

> There is a whole section in the
> RFC on Retry.  HTTP does not define a retry
> policy.

It *doesn't have to.*  And btw, RFC821 *does not contain the word "retry" **AT ALL.***  RFC1869,
the service extensions, doesn't either.  Get your facts straight.

> I'm not so sure.  I bought into the zen of loose
> coupling in REST.  I am hoping you will see the
> bonus in asynch.  I think the two are very
> complimentary.

Dude!  You don't have to sell me on asynch, I'm totally sold --- over five years ago I was trying
to explain to everybody that would listen that global-scale event notifications were indeed the
next big thing.  That was the WHOLE PREMISE behind my last company, Activerse!  (Lesson learned:
sell applications, not infrastructure.)  What you're failing to sell me on is the idea that HTTP
applications don't need to communicate asynchronously (in-the-large, i.e. in a macro sense) over
HTTP.

jb








-----------------------------------------------------------------------------------
Post ID:417
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 18:00:52
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections / Issues
Message:


Paul Prescod wrote:

> In theory you could build the Web on SMTP.

It can be done.  In fact, it *has* been done --- Pierre Omidyar, who went on to found EBay, had a
sort of midnight project called "WebMail" that delivered requested Web pages to General Magic
handhelds via e-mail.  This was contemporary and somewhat competitive with Active Paper's true SMTP
/ POP e-mail and browser clients that ran on those devices, and it took some convincing to get him
to shut it down. ;-)

As you point out, the fact that it *can* be done doesn't mean that it's desirable. :-)

jb








-----------------------------------------------------------------------------------
Post ID:418
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 18:06:35
Subject:Disconnection-as-latency, SMTP's not really asynchronous
Message:


"S. Alexander Jacobson" wrote:

> Gosling's homepage points to good reasons why
> asynch interfaces are better:
>    http://java.sun.com/people/jag/Fallacies.html

BTW, while this is Gosling's page, these are Peter Deutsch's utterings.  These have been around
for a *long* time.  I don't know if it was precisely these 8 fallacies, but he's (Peter's) been
talking about this stuff at least since the time when I was at Sun, over a decade ago.

Let me add a big lesson that most people fail to take away from those fallacies:

* Disconnection is the edge case of latency

At some fundamental level, almost all distributed applications assume that two parties in an
interaction are going to be online at the same time;  this is a safe assumption only for
applications where it's acceptable for the interaction to not occur at all if this doesn't
happen.  We pretend that most applications are like that, but indeed many applications would be
more useful if this wasn't the case, if I could *eventually* get the results I want regardless of
the connected status of the participants at any given time.

As our world becomes more mobile, people and devices become disconnected more frequently.  Despite
the drive to ubiquitous connectivity, it's safe to assume that the extreme edges of the network
will *always* be much lower bandwidth and much higher latency than the central parts, with the
extreme case approaching 0 and infinity respectively.  It's a shame that more people don't build
distributed systems that recognize this fact, degrade gracefully as bandwidth drops and latency
increases, and allow participants to continue when disconnected with a guarantee of eventual
consistency upon reconnection.  (This is particularly a beef of mine with most distributed
filesystems.)  This distinction from typical distributed systems is so important that back in the
early 90s I started calling such systems "dispersed systems" or "dispersed computing."  That's one
piece of bonejargon that never really took;  hey, even Babe Ruth never batted 1000. ;-)  There are
some Google hits, but they're rather semantically unrelated.

----

This need for looser coupling in time and with respect to instantaneous connectivity would seem to
argue for asynchrony in a very strong sense --- and it does.  Alex will interpret this to mean
that SMTP is better or more powerful in some sense than HTTP --- but he's wrong. ;-)

SMTP is a *synchronous* protocol, just like HTTP.  The asynchronous, store-and-forward behavior of
SMTP arises at the architectural and application level.  Each transmission of a message between
one party and another results from a TCP connection between the parties over which a synchronous
protocol is run to pass the message in question (request) and get back a response.  It's even more
synchronous than HTTP in many ways;  a single message requires a stateful series of synchronous
command-response interactions.  Certainly more chatty, more stateful, more difficult to implement,
more bletcherous on many levels.

SMTP's asynchrony --- and that's not even really the right word, at an application level it's
unidirectional in the success case --- arises as application-level semantics from a series of
synchronous interactions between entities that are tightly coupled in time.  There's no reason
whatsoever why SMTP as a protocol is better than HTTP as a protocol for this purpose;  the primary
advantage is that SMTP servers already understand routing and store-and-forward and have
infrastructure in place to support this.

----

More musings...

jb








-----------------------------------------------------------------------------------
Post ID:419
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-28 20:10:24
Subject:Re: [rest-discuss] Sub-resources
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>


> How, in general, does one get from a resource to its subordinate
> resources? Must the resource use an entity body in a structured format
> with HREFs? Is there no "standard" way? If not, why not?

I believe that is the Way of ReST.  The relationship is declarative rather
than algorithmic. Highly flexible but requires constant interpretation (of
entity bodies).
This is similar to the earlier notification approach of using the response
header of Subscription: to identify the URI of the subscription resource
rather than algorithmically/assume to know where it is.

>
> What is the relationship (if any) behind the hierarchy expressed through
> "/", "." and ".." and the subordinate resource hierarchy? I think that
> there is no explicit relationship. Why do we need two hierarchies?
>
(Do you mean 'no implicit relationship'?) Applications can coordinate on a
shared understanding of what '..' and '/' mean, but it isn't transferable in
general. It is very powerful, but also very easy to unconciously attempt to
bypass - we are used to knowing how to communicate with our own servers.

I find it difficult to avoid using .. and / to programmatically navigate my
application model. Using a response entity with explicit locations is a
somewhat new tool for me - using response headers is even 'more newer'.







-----------------------------------------------------------------------------------
Post ID:420
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 20:19:13
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections/Issues
Message:

On Mon, 28 Jan 2002, Paul Prescod wrote:
> > No SMTP is fundametally asynchronous.
> > Applications hand of messages to an SMTP MTA
> > (message transfer agent).
>
> That is application architecture. The protocol itself is synchronous.
> The client can't hang up until the server says OK. As we've discussed at
> length, you can build a similar application architecture for HTTP
> easily.

You need a retry protocol.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:421
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 20:24:47
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:

Paul,

I think we are having a miscommunication.  I am
not advocating SMTP/POP here.  I am suggesting
HTTP replacements for the SMTP/POP architecture
with which people are already comfortable.
In particular HTTP notification to the secured
"mail server" (the mail server is actually an HTTP
server handling notifation relay), and then
persistent GET between the clients behind the
firewall and the relay server.

-Alex-

On Mon, 28 Jan 2002, Paul Prescod wrote:

> "S. Alexander Jacobson" wrote:
> >
> >...
> >
> > People already maintain secured mail servers.
>
> One of my points to Lucas was that people also already maintain secured
> HTTP servers.
>
> > Mail gets past the firewall.
>
> HTTP traffic gets past the firewall (or at least to it).
>
> > Mail looks a lot like Lucas' protocol.
>
> Not really. ;) And anyhow, his protocol was meant to be used to
> end-nodes, not to the intermediaries.
>
>  Paul Prescod
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:422
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 20:30:31
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections/Issues
Message:

On Mon, 28 Jan 2002, Jeff Bone wrote:
> > > What happens when SMTP can't deliver the message?
> >
> > It keeps trying.
>
> Forever?  I think not.

It would help if you read the section in the RFC
on retries.  Obviously delivery CAN fail in either
protocol.  The difference is tolerance for
transient network outages.

> > There is a whole section in the
> > RFC on Retry.  HTTP does not define a retry
> > policy.
>
> It *doesn't have to.*  And btw, RFC821 *does not contain the word "retry" **AT ALL.***  RFC1869,
> the service extensions, doesn't either.  Get your facts straight.

Uhm.  The current RFC is 2821.

> > I'm not so sure.  I bought into the zen of loose
> > coupling in REST.  I am hoping you will see the
> > bonus in asynch.  I think the two are very
> > complimentary.
>
> Dude!  You don't have to sell me on asynch, I'm totally sold --- over five years ago I was trying
> to explain to everybody that would listen that global-scale event notifications were indeed the
> next big thing.  That was the WHOLE PREMISE behind my last company, Activerse!  (Lesson learned:
> sell applications, not infrastructure.)  What you're failing to sell me on is the idea that HTTP
> applications don't need to communicate asynchronously (in-the-large, i.e. in a macro sense) over
> HTTP.

Oh.  Ok.  Then we are largely on the same page.
I only arguing that HTTP asynch should provide all
the services I now get from SMTP.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:423
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 20:53:27
Subject:Re: Disconnection-as-latency, SMTP's not really asynchronous
Message:

On Mon, 28 Jan 2002, Jeff Bone wrote:
> SMTP's asynchrony --- and that's not even really the right word, at an application level it's
> unidirectional in the success case --- arises as application-level semantics from a series of
> synchronous interactions between entities that are tightly coupled in time.  There's no reason
> whatsoever why SMTP as a protocol is better than HTTP as a protocol for this purpose;  the primary
> advantage is that SMTP servers already understand routing and store-and-forward and have
> infrastructure in place to support this.

It comes down to the fact that SMTP also specifies
retry and relay behavior.  That each handoff is
synchronous is irrelevant.

The upshot is that SMTP allows endpoints to
communicate that are NEVER online at the same time

If you want to use HTTP for handoffs instead of
SMTP.  You need to specify retry and relay
behavior and define a notion of desination address
distinct from the relay agent URL.  In other words
you need to define a protocol that rides on top of
HTTP in the same way that HTTP rides on top of
TCP/IP.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:424
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-28 20:53:02
Subject:Re: [rest-discuss] a proposal for secure notifications
Message:

"S. Alexander Jacobson" wrote:
> 
> Paul,
> 
> I think we are having a miscommunication.  I am
> not advocating SMTP/POP here.  I am suggesting
> HTTP replacements for the SMTP/POP architecture
> with which people are already comfortable.

Okay, I think that's what I'm suggesting too. End of miscommunication!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:425
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-28 21:00:53
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections/Issues
Message:


"S. Alexander Jacobson" wrote:

> Uhm.  The current RFC is 2821.

Yup, sorry.  But two things to note:  2821 is from 2001;  821 is from 1982.  SMTP went 19 years without
formalizing its retry strategy.  Does this suggest anything to you?  Like perhaps particular retry
strategies are out-of-scope for the protocol specification?  Like perhaps they are *higher level
semantics* in some sense?  Also note that 4.5.4 of 2821 is about retry *STRATEGIES* and consists of a
set of conventions and constraints.  It's not possible to construct a canonical state machine for the
overall behavior of SMTP with *a* single, canonical retry semantics.

> Oh.  Ok.  Then we are largely on the same page.
> I only arguing that HTTP asynch should provide all
> the services I now get from SMTP.

Ok, I'm cool with that --- assuming by HTTP asynch you mean a store-and-forward message delivery
application built atop HTTP.

jb









-----------------------------------------------------------------------------------
Post ID:426
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-28 21:06:35
Subject:Re: [rest-discuss] Re: REST Terrorist-Or-Not, and Alex's Objections/Issues
Message:

On Mon, 28 Jan 2002, Jeff Bone wrote:
> > Oh.  Ok.  Then we are largely on the same page.
> > I only arguing that HTTP asynch should provide all
> > the services I now get from SMTP.
>
> Ok, I'm cool with that --- assuming by HTTP asynch you mean a store-and-forward message delivery
> application built atop HTTP.

Yes.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:427
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-28 23:11:00
Subject:Re: [rest-discuss] What is a notification?
Message:

----- Original Message -----
From: "Jeff Bone" <jbone@...>


>
> Lucas' analysis of the security problems with callbacks rests on
> a fundamental assumption that I think might be flawed.  In order
> to illustrate this, we have to ask:  what is a notification?
>
Ahh, lovely question, that.

In my idyllic world, notifications are messages 'about' resources -
typically about changes to resources. They are also not intended by the
sender to perform some action on the receiver - there is no response other
than delivery acknowledgement, the status would be '200 Ok, yeah, whatever'.








-----------------------------------------------------------------------------------
Post ID:428
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-29 00:25:56
Subject:Re: moinmoin publish & subscribe
Message:

David Ascher wrote:
> 
> it feels like an ideal testbed for your async HTTP thang.  Send me email
> (or an HTTP call, or a .NET Alert?) when any page in such and such a
> wiki changes.

That's a good idea. Our radical idea is that for applications that do
not already have a client UI, you could just use HTTP itself for the
events. But a bridge to SMTP and .NET alert makes sense for legacy
reasons.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:429
Sender:David Ascher <davida@...>
Post Date/Time:2002-01-29 00:44:50
Subject:Re: moinmoin publish & subscribe
Message:

Paul Prescod wrote:
> 
> David Ascher wrote:
> >
> > it feels like an ideal testbed for your async HTTP thang.  Send me email
> > (or an HTTP call, or a .NET Alert?) when any page in such and such a
> > wiki changes.
> 
> That's a good idea. Our radical idea is that for applications that do
> not already have a client UI, you could just use HTTP itself for the
> events. But a bridge to SMTP and .NET alert makes sense for legacy
> reasons.

I understand that.  But I believe that radical ideas don't amount to a
hill of beans in this world of ours without prototypes, rough drafts and
working code =).

One of the software efforts I was involved with involved radical ideas
clashing against legacy systems.  While working for Brown University's
IT department, we had a 'grand vision' of a campus wide PKI focused
around Kerberos (not sure why -- I think it mostly had to do with legal
liability concerns).  What it boiled down to on a daily basis was adding
Kerberos support to NNTP, SMTP, Gopher and other clients. We were
supposed to add this support to all the widely used "open source" (this
is before the term =) clients on campus.

T'was hell, and it was a failure.  Kerberos logins ended up being used
only for manipulating contact info in the central database through
special-purpose clients, but we never could get enough clients
converted, and the world wasn't standing still.

Moral of that story?  Not sure yet -- I'm still ramping up on REST and
HTTP events =).

--david

PS: Possibly silly question -- HTTP is allowed through firewalls over
port 80 in many organizations, which is why it's a good idea for things
like WebDAV.  However, many of the applications for HTTP Events that I
can think of are _personal_, and in the radical vision I'd expect my
personal computer to have several apps listening to and sending HTTP
events.  How do you envision port allocations to work?  Would I run a
"main event dispatcher" on my port 80, and the apps would register with
it?  Put concisely, how do you deal with the "Port 80 already in use"
problem?






-----------------------------------------------------------------------------------
Post ID:430
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-29 01:19:10
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

David Ascher wrote:
> 
>...
> 
> I understand that.  But I believe that radical ideas don't amount to a
> hill of beans in this world of ours without prototypes, rough drafts and
> working code =).

Yeah, yeah, yeah. We're getting there. First we have to figure out what
we're prototyping.

>...
> T'was hell, and it was a failure.  Kerberos logins ended up being used
> only for manipulating contact info in the central database through
> special-purpose clients, but we never could get enough clients
> converted, and the world wasn't standing still.

The focus has to be on problems that aren't solved yet. e.g. B2B or web
content syndication.

>...
> PS: Possibly silly question -- HTTP is allowed through firewalls over
> port 80 in many organizations, which is why it's a good idea for things
> like WebDAV.  However, many of the applications for HTTP Events that I
> can think of are _personal_, and in the radical vision I'd expect my
> personal computer to have several apps listening to and sending HTTP
> events.  

We're talking utopian here. "Personal HTTP Events" is not high on my
priority list. I'm thinking more about web services stuff. But here's my
Utopian view of personal HTTP events.

Your identity will be something like

ascher.com/~david

There is no need to have different identities for different protocols
(email, ftp, http, .NET). You'll have one HTTP-addressable identity.
However, portions of the address space can be used for different
applications (email versus IM versus web serving). On the other hand, we
may find that these different applications are not 

Your desktop is likely to be either behind a firewall or mobile or
distributed between home and work. So like IMAP, I would say that events
TO YOU go to this reliable, trusted address, maintained by professionals
(or yourself, if you are up to it). Transiant machines you happen to be
using can sync parts of that space when you connect to them -- just like
IMAP. You can have policies for when things are deleted on either the
client or the server.

To punch through a firewall you make a single persistent HTTP request to
that machine. This request is a fake. It serves the role of a VPN from
the server to you. Now you and the server can use plain HTTP events to
have it route messages to you in realtime over this pipe. The different
apps on your desktop will register themselves with the different
portions of the namespace. Probably each of them will set up their own
fake HTTP request tunnel. If it gets timed out they can easily
re-establish it.

The VPN-work-alike hack is necessary because many firewalls will not
allow connectivity IN, only OUT. So just like VPN or MSN, you will type
in your identity (a URI) and your password and it will contact the
intermediary. Unlike MSN (or .NET in general) the outside intermediary
is not a big central machine in the sky. It's something run by your ISP
or your BSD box at home. The nice thing is that if you turn off an app,
you can be confident that your local device isn't still getting barraged
by events (e.g. hack attacks) from the outside. Nobody even knows the
device exists except your intermediary box. The intermediary box could
do spam and virus filtering.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:431
Sender:David Ascher <davida@...>
Post Date/Time:2002-01-29 05:17:46
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

Paul Prescod wrote:

> Yeah, yeah, yeah. We're getting there. First we have to figure out what
> we're prototyping.

Hence my suggestion of the moinmoin publish & subscribe. =)

> The focus has to be on problems that aren't solved yet. e.g. B2B or web
> content syndication.

Hmm.  I'm very much still ramping up on REST, which I see as a minor
meme competing for mindshare among the big honkin meme of "XML Web
Services", SOAP, etc.  Web Services as a whole suffer from (IMO) a lack
of down-to-earth-appeal.  What are Web Services going to do for me?  In
what way is the _programmability_ of the web going to change my life/the
way I do business?  A very small fraction of the world is visionary
about WS and "gets it", and those are the people being heard right now. 
Most of the rest of us are somewhat puzzled and baffled by the acronym
soup, the _complexity_ of the solution.

Now, REST is intriguing to me for a very simple reason -- it's
technologically already there.  The part that's left to do is purely a
matter of coming up with the bright idea, setting up the social
agreement, schemas, partnerships, etc.  So REST, inasmuch as it relates
to Web Services, can leapfrog the SOAP meme by very quickly retrofitting
existing technology and _demonstrating_ _real_ applications.  

My suggestion: a new page on the Wiki called RealWorldApplications,
which provides people pointers to the Meerkats, Magi, KnowKnow, Zope?
and the like, and discussions of how they are RESTful.  Preferably a
compact REST-oriented description of the app would save the readers some
digging on corporate sites =).  Most importantly, describing how the
RESTful nature is an asset.  For something like Zope, I think it's
relatively easy to get the benefit of the addressability-through-URLs of
objects.  For Magi, it's not at all obvious without taking a lot of time
to dig in.  I'd appreciate some pointers.

Side question: how does one put Unicode characters in URLs?

--david ascher






-----------------------------------------------------------------------------------
Post ID:432
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-29 05:55:41
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:


On Mon, Jan 28, 2002 at 09:17:46PM -0800, David Ascher wrote:
> Side question: how does one put Unicode characters in URLs?

here's one idea of how to do it;
  http://search.ietf.org/internet-drafts/draft-masinter-url-i18n-08.txt



-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:433
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-29 06:18:31
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>
> >...
> > PS: Possibly silly question -- HTTP is allowed through firewalls over
> > port 80 in many organizations, which is why it's a good idea for things
> > like WebDAV.  However, many of the applications for HTTP Events that I
> > can think of are _personal_, and in the radical vision I'd expect my
> > personal computer to have several apps listening to and sending HTTP
> > events.
>
> We're talking utopian here. "Personal HTTP Events" is not high on my
> priority list. I'm thinking more about web services stuff. But here's my
> Utopian view of personal HTTP events.

Nifty.
This is what I called 'Appster' - local apps listening to messages on a
client (and dealing with firewalled nodes). But rather than a classical
server that handles the events by returning data, these events drive UI. The
code, framework, APIs etc. can still come from the HTTP server world -
essentially take Apache and some useful mods to deal with security,
dispatching, etc and add inter-process messages to get to those 'registered
apps'. I had hacked up Apache a bit to start this and was working on the COM
interface for registering and receiving events - not too difficult.

If anybody is interested in starting this up with Apache as the base let me
know - I've got a domain we can use to host it... groovier.net

Mike






-----------------------------------------------------------------------------------
Post ID:434
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-29 06:17:59
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

On Mon, 28 Jan 2002, David Ascher wrote:
> Side question: how does one put Unicode characters in URLs?

URLEncoded.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:435
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-25 20:17:36
Subject:Re: [rest-discuss] Why is HTTP hard to design with?
Message:

----- Original Message -----
From: "S. Alexander Jacobson" <alex@...>


> On Fri, 25 Jan 2002, S. Mike Dierken wrote:
> > > I just took a look at the two knownow demos...
> > > If you are talking about the knownow web clients,
> > > they don't open a peristent GET, they just make
> > > repeated requests, (polling the server).
> > They use a persistent response. If the connection is closed, they
re-open
> > it. That might be where the 'repeated requests' are coming from. Those
are
> > very infrequent.
>
> What is a persisent response?  I think they may do
> keep-alive my repeatedly asking the server "any
> messages, any messages,....", but that is still
> polling and it is still ugly (a waste of resources
> and bandwidth).
>
They don't repeatedly ask the server "any messages..."
Heres what happens:
1) The client does a GET.
2) The server responds with content that is a series of messages.
3) The response stays open.
4) As new message arrive at the server, they slide down the connection to
the client.
5) If the connection is dropped, the client re-establishes the connection.

That's what I meant by 'persistent response'. It isn't keep-alive (multiple
request/response with one tcp/ip connection), it is a long-lived response,
it looks like a really big document.
The browser parses this in a streaming fashion and calls back into
javascript as it encounters it in the stream.


> > >
> > > If you are talking about the knownow event
> > > routers, it sounds like they are implementing
> > > listservs.  If they are sending out 10k concurrent
> > > email messages, that is very nice.  If they are
> > > sending out only 100-1000 concurrent messages and
> > > just claim a max of 10k listeners, that is
> > > incredibly unimpressive.
> > Oh. Remember, I don't have real numbers as I do not work there
>
> If you don't have real numbers then lets drop
> knownow.
Ok. If it makes you uncomfortable.

>
> > > Either way, this has little to do with persistent
> > > GET and the merits of HTTP for presence
> > > applications.  The main point is that HTTP is
> > > suboptimal for this application (but you may need
> > > it if the client is a web browser).
> > If the client were another server, would http be sufficient?
>
> Not if you only want to send messages when the
> client is "available."
>
> > > Yeah. Me too.  How many chat clients can your web server support?
> > 10,000. Like I said, the KN server can handle 10k concurrent browser
clients
> > per cluster node.
>
> Ok.  Great.  What is the polling frequency?
There isn't any polling. Just like a TCP/IP connection, you re-open it if
the connection is dropped. Not on an interval basis.

> My point is that whatever the number, a server
> that allows clients to hold open connections for
> long periods of time will perform orders of
> magnitude better.
That is true. That is why that company has a server that allows clients to
hold open connections for long periods of time.

>
> You could implement with HTTP if the server chunk
> encoded delivery of messages and the client held
> the connection open long enough, but as you noted
> this is a serious abuse of HTTP and as I noted,
> most servers and intermediaries aren't happy to
> let an HTTP connection stay silent for too long.
>

> > > Even if your server could handle higher capacity
> > > the bandwidth of handling large numbers of pings
> > > will also eventually overwhelm you.
> > >
> > > Alternatively, you could also document a
> > > more scalable protocol like Jabber, IRC, or Kazaa,
> > > give away the source, get the same hackers to
> > > work on it, and perhaps get bought by AOL!
> > Or examine your assumptions.
> >
> > Nobody here is suggesting polling is the preferred way to go. A server
that
> > transparently handled polling for backward compatibility would help in
many
> > situations, as long as the scalability/traffic problems don't surface.
>
> The issue is that HTTP requires polling to
> establish presence.
I don't understand what you mean.

>
> Let me ask it all another way, do you want to use
> HTTP instead of telnet/ssh (to interact with the
> shell)?
Yes.








-----------------------------------------------------------------------------------
Post ID:436
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-29 20:20:38
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

On Mon, 28 Jan 2002, Paul Prescod wrote:
> Your identity will be something like
>
> ascher.com/~david
>
> There is no need to have different identities for different protocols
> (email, ftp, http, .NET). You'll have one HTTP-addressable identity.

Why not lett that identity continue to be e.g.
david@...?

On most browsers, typing in
http://david@... results in ther header:

   host: david@...

It is up to the server implementation to know that
david@... is distinct from john@....
Since servers MUST pay attention to host headers
anyway, this seems like the way to go....

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:437
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-29 21:03:23
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:


The portion before the '@' in the authority is 'userinfo',
which in HTTP is used for authentication. So,
  http://david@.../
would result in a host header
  Host: ascher.com
and a challenge to the user for the password for 'david'.

Cheers,



On Tue, Jan 29, 2002 at 03:20:38PM -0500, S. Alexander Jacobson wrote:
> On Mon, 28 Jan 2002, Paul Prescod wrote:
> > Your identity will be something like
> >
> > ascher.com/~david
> >
> > There is no need to have different identities for different protocols
> > (email, ftp, http, .NET). You'll have one HTTP-addressable identity.
> 
> Why not lett that identity continue to be e.g.
> david@...?
> 
> On most browsers, typing in
> http://david@... results in ther header:
> 
>    host: david@...
> 
> It is up to the server implementation to know that
> david@... is distinct from john@....
> Since servers MUST pay attention to host headers
> anyway, this seems like the way to go....
> 
> -Alex-
> ___________________________________________________________________
> S. Alexander Jacobson                   i2x Media
> 1-212-787-1914 voice                    1-603-288-1280 fax
> 
> 
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:438
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-29 21:13:56
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

On Tue, 29 Jan 2002, Mark Nottingham wrote:
> The portion before the '@' in the authority is 'userinfo',
> which in HTTP is used for authentication. So,
>   http://david@.../
> would result in a host header
>   Host: ascher.com
> and a challenge to the user for the password for 'david'.

Only if the resource requires authentication.
The spec does not _require_ that a POST to
david@... requires authentication.
Moreover, the issue of authentication is really
handled in a separate header.

Moreover, there is no reason to think that a POST
to david@... is equivalent to a POST to
john@....

So it seems like we can keep using email addresses
even if we switch to HTTP delivery mechanisms.

That being said, I am not sure how to replace the
functionality of MX records and relays in HTTP.

-Alex-


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax


>
> On Tue, Jan 29, 2002 at 03:20:38PM -0500, S. Alexander Jacobson wrote:
> > On Mon, 28 Jan 2002, Paul Prescod wrote:
> > > Your identity will be something like
> > >
> > > ascher.com/~david
> > >
> > > There is no need to have different identities for different protocols
> > > (email, ftp, http, .NET). You'll have one HTTP-addressable identity.
> >
> > Why not lett that identity continue to be e.g.
> > david@...?
> >
> > On most browsers, typing in
> > http://david@... results in ther header:
> >
> >    host: david@...
> >
> > It is up to the server implementation to know that
> > david@... is distinct from john@....
> > Since servers MUST pay attention to host headers
> > anyway, this seems like the way to go....
> >
> > -Alex-
> > ___________________________________________________________________
> > S. Alexander Jacobson                   i2x Media
> > 1-212-787-1914 voice                    1-603-288-1280 fax
> >
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>








-----------------------------------------------------------------------------------
Post ID:439
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-01-29 21:27:17
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

If the server doesn't require authentication, the username will be
lost; the request-line for http://david@.../ will look like
  GET /
  Host: ascher.com



On Tue, Jan 29, 2002 at 04:13:56PM -0500, S. Alexander Jacobson wrote:
> On Tue, 29 Jan 2002, Mark Nottingham wrote:
> > The portion before the '@' in the authority is 'userinfo',
> > which in HTTP is used for authentication. So,
> >   http://david@.../
> > would result in a host header
> >   Host: ascher.com
> > and a challenge to the user for the password for 'david'.
> 
> Only if the resource requires authentication.
> The spec does not _require_ that a POST to
> david@... requires authentication.
> Moreover, the issue of authentication is really
> handled in a separate header.
> 
> Moreover, there is no reason to think that a POST
> to david@... is equivalent to a POST to
> john@....
> 
> So it seems like we can keep using email addresses
> even if we switch to HTTP delivery mechanisms.
> 
> That being said, I am not sure how to replace the
> functionality of MX records and relays in HTTP.
> 
> -Alex-
> 
> 
> ___________________________________________________________________
> S. Alexander Jacobson                   i2x Media
> 1-212-787-1914 voice                    1-603-288-1280 fax
> 
> 
> >
> > On Tue, Jan 29, 2002 at 03:20:38PM -0500, S. Alexander Jacobson wrote:
> > > On Mon, 28 Jan 2002, Paul Prescod wrote:
> > > > Your identity will be something like
> > > >
> > > > ascher.com/~david
> > > >
> > > > There is no need to have different identities for different protocols
> > > > (email, ftp, http, .NET). You'll have one HTTP-addressable identity.
> > >
> > > Why not lett that identity continue to be e.g.
> > > david@...?
> > >
> > > On most browsers, typing in
> > > http://david@... results in ther header:
> > >
> > >    host: david@...
> > >
> > > It is up to the server implementation to know that
> > > david@... is distinct from john@....
> > > Since servers MUST pay attention to host headers
> > > anyway, this seems like the way to go....
> > >
> > > -Alex-
> > > ___________________________________________________________________
> > > S. Alexander Jacobson                   i2x Media
> > > 1-212-787-1914 voice                    1-603-288-1280 fax
> > >
> > >
> > >
> > >
> > > To unsubscribe from this group, send an email to:
> > > rest-discuss-unsubscribe@yahoogroups.com
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> > --
> > Mark Nottingham
> > http://www.mnot.net/
> >
> >
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:440
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-29 21:38:25
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

On Tue, 29 Jan 2002, Mark Nottingham wrote:
> If the server doesn't require authentication, the username will be
> lost; the request-line for http://david@.../ will look like
>   GET /
>   Host: ascher.com

That doesn't make sense.  The client does not know
in advance that the server requires
authentication.  All browsers I've used
(including IE and lynx) send:

  Host: david@...

They may also send an Authorization: or Cookie:
header, but that is a separate issue.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax



>
>
>
> On Tue, Jan 29, 2002 at 04:13:56PM -0500, S. Alexander Jacobson wrote:
> > On Tue, 29 Jan 2002, Mark Nottingham wrote:
> > > The portion before the '@' in the authority is 'userinfo',
> > > which in HTTP is used for authentication. So,
> > >   http://david@.../
> > > would result in a host header
> > >   Host: ascher.com
> > > and a challenge to the user for the password for 'david'.
> >
> > Only if the resource requires authentication.
> > The spec does not _require_ that a POST to
> > david@... requires authentication.
> > Moreover, the issue of authentication is really
> > handled in a separate header.
> >
> > Moreover, there is no reason to think that a POST
> > to david@... is equivalent to a POST to
> > john@....
> >
> > So it seems like we can keep using email addresses
> > even if we switch to HTTP delivery mechanisms.
> >
> > That being said, I am not sure how to replace the
> > functionality of MX records and relays in HTTP.
> >
> > -Alex-
> >
> >
> > ___________________________________________________________________
> > S. Alexander Jacobson                   i2x Media
> > 1-212-787-1914 voice                    1-603-288-1280 fax
> >
> >
> > >
> > > On Tue, Jan 29, 2002 at 03:20:38PM -0500, S. Alexander Jacobson wrote:
> > > > On Mon, 28 Jan 2002, Paul Prescod wrote:
> > > > > Your identity will be something like
> > > > >
> > > > > ascher.com/~david
> > > > >
> > > > > There is no need to have different identities for different protocols
> > > > > (email, ftp, http, .NET). You'll have one HTTP-addressable identity.
> > > >
> > > > Why not lett that identity continue to be e.g.
> > > > david@...?
> > > >
> > > > On most browsers, typing in
> > > > http://david@... results in ther header:
> > > >
> > > >    host: david@...
> > > >
> > > > It is up to the server implementation to know that
> > > > david@... is distinct from john@....
> > > > Since servers MUST pay attention to host headers
> > > > anyway, this seems like the way to go....
> > > >
> > > > -Alex-
> > > > ___________________________________________________________________
> > > > S. Alexander Jacobson                   i2x Media
> > > > 1-212-787-1914 voice                    1-603-288-1280 fax
> > > >
> > > >
> > > >
> > > >
> > > > To unsubscribe from this group, send an email to:
> > > > rest-discuss-unsubscribe@yahoogroups.com
> > > >
> > > >
> > > >
> > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > > --
> > > Mark Nottingham
> > > http://www.mnot.net/
> > >
> > >
> >
> >
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>








-----------------------------------------------------------------------------------
Post ID:441
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-29 21:46:03
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

This is a bizarre discussion.  The "Host" header specifies a *host*.
If we're going to start putting email addresses there, why not use the
Cache-Control or Expires headers (or any other header not named From)?
None of them support email addresses either.

This isn't the "abuse-rest-discuss" list.  Let's first discuss how REST,
HTTP, and URIs can do it *without extension or additional a priori
agreement*.  If that fails, then we can consider extensions, abuse,
or both.

> That doesn't make sense.  The client does not know
> in advance that the server requires
> authentication.  All browsers I've used
> (including IE and lynx) send:
> 
>   Host: david@...
> 
> They may also send an Authorization: or Cookie:
> header, but that is a separate issue.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:442
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-29 22:04:43
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

On Tue, 29 Jan 2002, Mark Baker wrote:
> This is a bizarre discussion.  The "Host" header specifies a *host*.

RFC2616 does not define host except to say that:

  The Host field value MUST represent
  the naming authority of the origin server or
  gateway given by the original URL.

SMTP is more extreme.  Mail to david@...
is handled by the MX record for ascher.com not by
any host named ascher.com.

> If we're going to start putting email addresses there, why not use the
> Cache-Control or Expires headers (or any other header not named From)?
> None of them support email addresses either.

The expires field value is required to be a date.
Cache control has similar, though more complex
restrictions and does not seem to support the
behavior described.

Since this host header behavior seems to be
implemented universally and is consistent with
the meaning of the spec, I don't see a problem.
If it is, why does everything seem to implement
this behavior?

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax


>
> This isn't the "abuse-rest-discuss" list.  Let's first discuss how REST,
> HTTP, and URIs can do it *without extension or additional a priori
> agreement*.  If that fails, then we can consider extensions, abuse,
> or both.
>
> > That doesn't make sense.  The client does not know
> > in advance that the server requires
> > authentication.  All browsers I've used
> > (including IE and lynx) send:
> >
> >   Host: david@...
> >
> > They may also send an Authorization: or Cookie:
> > header, but that is a separate issue.
>
> MB
> --
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@...
> http://www.markbaker.ca   http://www.planetfred.com
>









-----------------------------------------------------------------------------------
Post ID:443
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-29 22:38:07
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:


"S. Alexander Jacobson" wrote:

> On Tue, 29 Jan 2002, Mark Baker wrote:
> > This is a bizarre discussion.  The "Host" header specifies a *host*.
>
> RFC2616 does not define host

That's because, while RFCs strive to be comprehensive, the authors of 2616
(and many other RFCs) never in their wildest dreams ever imagined that anyone
in this day and age and this context could be obtuse enough to interpret
"host" to mean "an abstract pairing of a user name and a domain naming
authority, intended to be named by and messageable via SMTP."

;-)


> SMTP is more extreme.  Mail to david@...
> is handled by the MX record for ascher.com not by
> any host named ascher.com.

Yeah, THAT'S always been a good idea, hasn't it?

:-/


> The expires field value is required to be a date.

And the host field is required to be a...  host?  Who'd'a thunk it?  Oh, we
want to use it for other purposes?  Ok, let's just redefine it --- if we call
"joe@..." a "host" then we can use that wherever "host" is used!


(Sorry, couldn't resist.  But seriously, folks...)

jb








-----------------------------------------------------------------------------------
Post ID:444
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-29 22:44:49
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

On Tue, 29 Jan 2002, Jeff Bone wrote:
> > SMTP is more extreme.  Mail to david@...
> > is handled by the MX record for ascher.com not by
> > any host named ascher.com.
>
> Yeah, THAT'S always been a good idea, hasn't it?

Actually I think it has.  SMTP provides a nice way
of failing over when a machine goes down (or is
too busy).  Do you think the variety of ugly HTTP
load balancing schemes are better?

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:445
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-29 23:12:30
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:


"S. Alexander Jacobson" wrote:

> On Tue, 29 Jan 2002, Jeff Bone wrote:
> > > SMTP is more extreme.  Mail to david@...
> > > is handled by the MX record for ascher.com not by
> > > any host named ascher.com.
> >
> > Yeah, THAT'S always been a good idea, hasn't it?
>
> Actually I think it has.  SMTP provides a nice way
> of failing over when a machine goes down (or is
> too busy).  Do you think the variety of ugly HTTP
> load balancing schemes are better?

Irrelevant.  The issue here is that SMTP routing behavior is defined and
configured by an out-of-band mechanism, DNS --- that's bad enough by
itself, and made worse still by some of the unpleasant specifics of DNS
and its use.  DNS is (still) relatively rigid, non-dynamic,
unidirectional, slow-changing, and brittle.  (Indeed, you can think of
DHCP as a response in part to DNS's unidirectional and slow-changing /
difficult-to-change characteristics.)  SMTP's correct behavior
unfortunately depends on correct DNS configuration, availability, etc;
DNS is a thorn in the side of SMTP, and at the same time SMTP support
has long been a conceptual and architectural tumor growing on / in DNS.
SMTP inherits a lot of its bletcherousness from its intimate and
unseemly relationship with DNS, and IMO that alone is a good enough
reason to begin thinking about its replacement.  The dependency is a Bad
Thing (tm) any way you look at it.

This was all fine in a world of tens to hundreds of hosts and tens to
hundreds of thousands of users, with smart, technical guys running the
show administratively, where "churn" was minimal because most of the
folks involved were academics who didn't "move around a lot."  The
assumptions are no longer valid --- we live in a world with tens of
millions of hosts, hundreds of millions of users, increasing
ephemerality of connection, high rates of user<->host and topological
churn.

Clay Shirky and many others have noted that DNS is collapsing under its
own weight and architectural limitations.  Alex, I agree with you that
the Web needs its own naming and routing mechanisms --- but we
*certainly* shouldn't base our solutions on the very same fallacious
assumptions that created the problems in the first place!

jb

PS - I have in the past floated the idea (the "metaweb") of using
verifiable naming and HTTP's own 3xx response as a routing primitive in
combination to make the Web self-naming and self-routing, independent of
DNS and free from many of its current, unpleasant and unnecessary
administrative constraints.  This is probably do-able with minimal
impact on the existing Web architecture.  There's a large amount of
current work going on along these lines relative to distributed
filesystems, filesharing, p2p and decentralized systems.  It would be
nice to see a principled design for such functionality available for
general use within the Web community.









-----------------------------------------------------------------------------------
Post ID:446
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-30 00:08:31
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

I always thought the www.foo.com ftp.foo.com
convention was a wart on DNS for not providing MX
equivalents for other services.

I don't think that DHCP has anything to do with
DNS!

> PS - I have in the past floated the idea (the "metaweb") of using
> verifiable naming and HTTP's own 3xx response as a routing primitive in
> combination to make the Web self-naming and self-routing, independent of
> DNS and free from many of its current, unpleasant and unnecessary
> administrative constraints.  This is probably do-able with minimal
> impact on the existing Web architecture.

Hmm.  Interesting.  Can you expand on that?  Does
it solve the problem of failover servers/load
balancing?

> There's a large amount of
> current work going on along these lines relative to distributed
> filesystems, filesharing, p2p and decentralized systems.  It would be
> nice to see a principled design for such functionality available for
> general use within the Web community.

Yes thats true, but it seems to focus on
identifying documents not resources.  These are
different.

The most obvious replacement for names is google's
"I feel lucky", but I don't think it is really
what you want in a protocol.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:447
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-30 00:16:56
Subject:Self-routing
Message:

> 
> 
> 
> "S. Alexander Jacobson" wrote:
> 
> > On Tue, 29 Jan 2002, Jeff Bone wrote:
> > > > SMTP is more extreme.  Mail to david@...
> > > > is handled by the MX record for ascher.com not by
> > > > any host named ascher.com.
> > >
> > > Yeah, THAT'S always been a good idea, hasn't it?
> >
> > Actually I think it has.  SMTP provides a nice way
> > of failing over when a machine goes down (or is
> > too busy).  Do you think the variety of ugly HTTP
> > load balancing schemes are better?
> 
> Irrelevant.  The issue here is that SMTP routing behavior is defined and
> configured by an out-of-band mechanism, DNS --- that's bad enough by
> itself, and made worse still by some of the unpleasant specifics of DNS
> and its use.  DNS is (still) relatively rigid, non-dynamic,
> unidirectional, slow-changing, and brittle.  (Indeed, you can think of
> DHCP as a response in part to DNS's unidirectional and slow-changing /
> difficult-to-change characteristics.)  SMTP's correct behavior
> unfortunately depends on correct DNS configuration, availability, etc;
> DNS is a thorn in the side of SMTP, and at the same time SMTP support
> has long been a conceptual and architectural tumor growing on / in DNS.
> SMTP inherits a lot of its bletcherousness from its intimate and
> unseemly relationship with DNS, and IMO that alone is a good enough
> reason to begin thinking about its replacement.  The dependency is a Bad
> Thing (tm) any way you look at it.
> 
> This was all fine in a world of tens to hundreds of hosts and tens to
> hundreds of thousands of users, with smart, technical guys running the
> show administratively, where "churn" was minimal because most of the
> folks involved were academics who didn't "move around a lot."  The
> assumptions are no longer valid --- we live in a world with tens of
> millions of hosts, hundreds of millions of users, increasing
> ephemerality of connection, high rates of user<->host and topological
> churn.
> 
> Clay Shirky and many others have noted that DNS is collapsing under its
> own weight and architectural limitations.  Alex, I agree with you that
> the Web needs its own naming and routing mechanisms --- but we
> *certainly* shouldn't base our solutions on the very same fallacious
> assumptions that created the problems in the first place!
> 
> jb
> 
> PS - I have in the past floated the idea (the "metaweb") of using
> verifiable naming and HTTP's own 3xx response as a routing primitive in
> combination to make the Web self-naming and self-routing, independent of
> DNS and free from many of its current, unpleasant and unnecessary
> administrative constraints.  This is probably do-able with minimal
> impact on the existing Web architecture.  There's a large amount of
> current work going on along these lines relative to distributed
> filesystems, filesharing, p2p and decentralized systems.  It would be
> nice to see a principled design for such functionality available for
> general use within the Web community.
> 
> 
> 
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 


-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:448
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-30 00:29:56
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>
>
> This isn't the "abuse-rest-discuss" list.

You are correct - this is: http://groups.yahoo.com/group/abuse-rest-discuss/








-----------------------------------------------------------------------------------
Post ID:449
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-30 00:47:02
Subject:Self-routing
Message:

Oopsie on that last one.

> PS - I have in the past floated the idea (the "metaweb") of using
> verifiable naming and HTTP's own 3xx response as a routing primitive in
> combination to make the Web self-naming and self-routing, independent of
> DNS and free from many of its current, unpleasant and unnecessary
> administrative constraints.  This is probably do-able with minimal
> impact on the existing Web architecture.  There's a large amount of
> current work going on along these lines relative to distributed
> filesystems, filesharing, p2p and decentralized systems.  It would be
> nice to see a principled design for such functionality available for
> general use within the Web community.

Yup.  You can do this without redirection too.  If you think about
it, any intermediary along a path is a potential new context in
which a URI can be interpreted and which can be forwarded on without
redirecting back to the initiator.

I recall a very old (pre-Bone) FoRK post in which Rohit suggested
that in order for naming to decentralize, we have to move to
relative names such as "Rohit's Adam", which may be URIfied as;

  http://[rohit's pgp key]/adam

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:450
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-30 00:54:19
Subject:Re: [rest-discuss] Re: moinmoin publish & subscribe
Message:

"S. Alexander Jacobson" wrote:

> I always thought the www.foo.com ftp.foo.com
> convention was a wart on DNS for not providing MX
> equivalents for other services.

Ugh.  (BTW, of course www.xxx.yyy and ftp.xxx.yyy don't have any actual
semantic signficance.)  It's hard enough maintaining MX records in DNS, why in
the world do we want equivalents for other services?  Yuck.

> I don't think that DHCP has anything to do with
> DNS!

No, of course it doesn't.  I was trying to draw an architectural distinction,
not claim that they solve the same problem in different ways.  (If you squint
while you read it, you'll see the point I was making rather badly. ;-)

> > PS - I have in the past floated the idea (the "metaweb") of using
> > verifiable naming and HTTP's own 3xx response as a routing primitive in
> > combination to make the Web self-naming and self-routing, independent of
> > DNS and free from many of its current, unpleasant and unnecessary
> > administrative constraints.  This is probably do-able with minimal
> > impact on the existing Web architecture.
>
> Hmm.  Interesting.  Can you expand on that?

Probably beyond the scope of this discussion, but this area has been a
research focus of mine for about 18 months, now.  Still trying to sort out how
much is public vs. how much is entangled with my current company, but at some
point I hope be able to freely discuss this in some detail.  (Focus as the
current play evolved has shifted / narrowed somewhat from our original effort
in this area, so I'm optimistic about being able to open it up.)

> Does
> it solve the problem of failover servers/load
> balancing?

Not by itself, but it provides potential support for such solutions.

> > There's a large amount of
> > current work going on along these lines relative to distributed
> > filesystems, filesharing, p2p and decentralized systems.  It would be
> > nice to see a principled design for such functionality available for
> > general use within the Web community.
>
> Yes thats true, but it seems to focus on
> identifying documents not resources.  These are
> different.

A key thing to understand is that there's a fundamental difference between
semantic names and identifiers.  Semantic name resolution maps a name to a
set, potentially of order 1.  Identifier resolution maps an identifier which
uniquely identifies a single object onto that object.  (Punt on the issue of
whether "identified" objects are required to be immutable.)  There're some
interesting mathematical games you can play with the distinction between these
things. ;-)  The big difference is that while moving, caching, replicating,
etc. static documents is trivial and can be safely assumed, the same cannot be
said for resources in general.

> The most obvious replacement for names is google's
> "I feel lucky", but I don't think it is really
> what you want in a protocol.

We're always going to need three kinds of names:  semantic names that map to
sets of objects of arbitrary size, semantic names that map to a set of objects
guaranteed to be of order 1, and names that map to a specific object i.e. are
"self-verifying."  For the first two kinds of naming, name resolution does
indeed have to be a service.  The idea is to find ways to make this service as
decentralized, as dynamic, and as local in administrative scope as possible.

$0.02,

jb








-----------------------------------------------------------------------------------
Post ID:451
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-30 01:45:36
Subject:Re: Self-routing
Message:

On Tue, 29 Jan 2002, Mark Baker wrote:
> I recall a very old (pre-Bone) FoRK post in which Rohit suggested
> that in order for naming to decentralize, we have to move to
> relative names such as "Rohit's Adam", which may be URIfied as;
>
>   http://[rohit's pgp key]/adam

And you were complaining about MY abuse of HTTP!
Btw, this would suck as rohit's pgp key got
compromised.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:452
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-30 02:14:12
Subject:Is the firewall dead?
Message:

One for the "spatial metaphors don't apply in bitspace" file,
Brandon Gillespie has an article on biological network security
that's perhaps of some interest, particularly given the
discussion over the weekend about security.  (I know, you read
Slashdot, too... just pointing out the article. :-)

    http://www.securityfocus.com/guest/10094

jb








-----------------------------------------------------------------------------------
Post ID:453
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-30 03:07:49
Subject:idempotent notifications
Message:

In my recent post on a quasi-protocol named Paranoid Sink Protocol, I
articulated a design for secure callbacks based on the HTTP 0.9 protocol.  A
part of that design that has stuck in my mind is the idea that callbacks would
be idempotent.  This message articulates related thoughts.

Other recent related conversations in rest-discuss, e.g. my own aREST document
and Paul Prescod's HTTP Notifications document, built event notifications using
the POST method.  POST was necessary because the event notifications contained
the content of the event.  The sink was expected to store the new content, and
if the sink stores incoming data then the sink state has changed.

In my PSP post I articulated a different type of event notification.  This event
notification is nothing but a notification that state had changed; the
notification does not contain any information about the new state.  If the sink
wants a detailed update it has to perform a follow-up request.

This approach has the useful feature that notifications from source to sink are
idempotent, because any N notifications where N > 1 have the same effect on
state at the sink.  Because it is idempotent it may use the GET method.

Constrast a GET notification to a POST notification.  The POST notification
needs to say what about the state changed.  This opens the pandora's box of
version control.   Groove takes this approach -- a steady stream of state change
messages that include information to reconstruct the new state.  And Paul's
proposal also used it, in that it included modifiers to describe a number of
types of state changes, each of which needed to be combined with the
notification payload and the existing copy of the state to create an up to date
copy.  A POST message is not only a notification, it is also an update.

Idempotent notifications leave all such issues to ride over the top, as
application issues.  This has the primary advantage of better separation between
infrastructure and application and the secondary advantages of simpler
implementation and greater security.  If there is no need to handle conflict
resolution at the notification level, notification can be one specialist part of
the web infrastructure and version control another.  If a badly administered
local web server doesn't have to expose non-idempotent APIs, it has better
security.

Everything has it's place, and clearly there are advantages to non-idempotent
notifications.  Idempotent notifications do not allow a sink to know about
states that happen between the time the event is emitted and the time the
follow-up request from the sink is received.  Only non-idempotent notifications
allow a sink the keep track of all changes.  Applications for which every tick
counts, like scientific applications that need extremely fine grained data
points, have to have non-idempotent notifications.  Real time stock data is
invariably transmitted as a stream of states, not a stream of notifications.
(Are there other applications that have to have non-idempotent notifications?
Don't know.)  But I wouldn't call these notifications, I would call them push
updates.  So POST implies updates, while GET implies notifications.

- Lucas







-----------------------------------------------------------------------------------
Post ID:454
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-30 03:35:48
Subject:Re: Self-routing
Message:

> On Tue, 29 Jan 2002, Mark Baker wrote:
> > I recall a very old (pre-Bone) FoRK post in which Rohit suggested
> > that in order for naming to decentralize, we have to move to
> > relative names such as "Rohit's Adam", which may be URIfied as;
> >
> >   http://[rohit's pgp key]/adam
> 
> And you were complaining about MY abuse of HTTP!
> Btw, this would suck as rohit's pgp key got
> compromised.

It may require a new URI scheme to deploy, but hopefully not.  And it's
far from an abuse.  The part after the "//" is an authority, and a
public key is a perfectly valid authority.

When you decentralize, you do sacrifice some advantages of
centralization, granted.  But I'd personally be willing to make the
"rent a DNS address" versus "own a public key" tradeoff if I could.
Also, nothing prevents Verisign from trying to push PKI here and
suggesting that all key holders need them as a CA.  Naming is as
much a trust issue as it is anything else.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:455
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-30 03:45:07
Subject:Re: [rest-discuss] Re: Self-routing
Message:

On Tue, 29 Jan 2002, Mark Baker wrote:

> > On Tue, 29 Jan 2002, Mark Baker wrote:
> > > I recall a very old (pre-Bone) FoRK post in which Rohit suggested
> > > that in order for naming to decentralize, we have to move to
> > > relative names such as "Rohit's Adam", which may be URIfied as;
> > >
> > >   http://[rohit's pgp key]/adam
> >
> > And you were complaining about MY abuse of HTTP!
> > Btw, this would suck as rohit's pgp key got
> > compromised.
>
> It may require a new URI scheme to deploy, but hopefully not.  And it's
> far from an abuse.  The part after the "//" is an authority, and a
> public key is a perfectly valid authority.

How is this less of an abuse than using email
address?  distobj@... is also an authorty...

> When you decentralize, you do sacrifice some advantages of
> centralization, granted.  But I'd personally be willing to make the
> "rent a DNS address" versus "own a public key" tradeoff if I could.
> Also, nothing prevents Verisign from trying to push PKI here and
> suggesting that all key holders need them as a CA.  Naming is as
> much a trust issue as it is anything else.

Ok, but onces you invoke a CA you are talking
about something different:

http://[rohit's CA id]/adam

The CA then certifies a particular public key as
being under the control of the entity represented
by this ID.  To me this all sounds like DNS with
SSL certificates.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:456
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-30 03:56:31
Subject:Re: [rest-discuss] Re: Self-routing
Message:

> > It may require a new URI scheme to deploy, but hopefully not.  And it's
> > far from an abuse.  The part after the "//" is an authority, and a
> > public key is a perfectly valid authority.
> 
> How is this less of an abuse than using email
> address?  distobj@... is also an authorty...

I didn't say it wasn't.  It's just tied to DNS too (MX records or A
records, doesn't matter), so has the same icky dependancy.  You can
only rent those names, not own them.

> Ok, but onces you invoke a CA you are talking
> about something different:
> 
> http://[rohit's CA id]/adam
> 
> The CA then certifies a particular public key as
> being under the control of the entity represented
> by this ID.  To me this all sounds like DNS with
> SSL certificates.

Well, sorta.  I'm not saying that a CA is required, only that Verisign
could play it this way (I wonder if they knew what they were getting
into when they acquired Netsol?).  Plus, though a CA centralizes one
part of the system (trust), you still *own* your key.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:457
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-30 06:47:41
Subject:Re: [rest-discuss] Re: Self-routing
Message:

On Tue, 29 Jan 2002, Mark Baker wrote:
> Well, sorta.  I'm not saying that a CA is required, only that Verisign
> could play it this way (I wonder if they knew what they were getting
> into when they acquired Netsol?).  Plus, though a CA centralizes one
> part of the system (trust), you still *own* your key.

Owning your own key is irrelevant.  What matters
is the mapping from the key to the id and you
necessarily rent that.

As a whole, I would suggest that you own your name
more than you own your cert.

Verisign can mess with cert requirements any time
it wants -- making it difficult to renew.

Your claim to ownership of an id is a bit
stronger.  You just have to pay to retain it.

-Alex-


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:458
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-01-30 15:08:52
Subject:Re: [rest-discuss] Re: Self-routing
Message:

"S. Alexander Jacobson" wrote:

> Your claim to ownership of an id is a bit
> stronger.  You just have to pay to retain it.

Nonononono --- id's don't have to be rented, sold, etc.  What *is* an id,
anyway?  Online, it's just a guarantee of continuity of some kind.  I.e., the
person doing this thing today is the same person who did it yesterday.  In
order to prove that continuity, all that's needed is a persistent secret that
only the principal in question knows, which can be used in a zero-knowledge
fashion.  This can easily be done with 2 parties and relatively mild crypto.

Tying that in any useful way to the "real world" notion of identities is
probably unnecessary for most or all applications, and often undesirable.
And that tying is the only reason for a trust relationship with a third-party
authentication / cert agent.

jb








-----------------------------------------------------------------------------------
Post ID:459
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-30 15:14:22
Subject:Re: [rest-discuss] idempotent notifications
Message:

> This approach has the useful feature that notifications from source to sink are
> idempotent, because any N notifications where N > 1 have the same effect on
> state at the sink.  Because it is idempotent it may use the GET method.

Not true.  By definition, the resource identified by the callback URI
changes state when notified of an event (call it a "mailbox" or
whatever).  That means that there are side-effects, and therefore GET is
not appropriate.

> A POST message is not only a notification, it is also an update.

It need not be.  The body could just be a URI, for example.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:460
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-30 15:24:56
Subject:Re: [rest-discuss] idempotent notifications
Message:

> 
> > This approach has the useful feature that notifications from source to sink are
> > idempotent, because any N notifications where N > 1 have the same effect on
> > state at the sink.  Because it is idempotent it may use the GET method.
> 
> Not true.  By definition, the resource identified by the callback URI
> changes state when notified of an event (call it a "mailbox" or
> whatever).  That means that there are side-effects, and therefore GET is
> not appropriate.
> 
> > A POST message is not only a notification, it is also an update.
> 
> It need not be.  The body could just be a URI, for example.

You might noticed an apparent contradiction there.  I was assuming that
by "update" you meant that the POST body was used in determining how
the state of the callback resource was modified.  This may not be the
case, because it's possible that all that resource needs to know to
make a state change is *that* a POST was invoked, not the contents of
the POST body.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:461
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-30 15:46:34
Subject:Re: [rest-discuss] Re: Self-routing
Message:

The issue with id's is handling key
compromise/revocation etc.

The CA just guarantees continuity accross keys.
This guarantee may or may not involve the real
world.  In particular, verisign server certs don't
actually involve the real world at all.  Instead
they involve the world of corporate documents and
providing bona-fides as a business.

Note: Versign actually guarantees something weaker
than what I describe above.  If company A buys a
domain name from Company B and then obtains a
cert, you are not actually guaranteed that there
is continuity of identity.

Note: The economic function of a CA is to insure
against key compromise.  One could think of CA
costs as insurance premiums rather than rents.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax


On Wed, 30 Jan 2002, Jeff Bone wrote:

>
> "S. Alexander Jacobson" wrote:
>
> > Your claim to ownership of an id is a bit
> > stronger.  You just have to pay to retain it.
>
> Nonononono --- id's don't have to be rented, sold, etc.  What *is* an id,
> anyway?  Online, it's just a guarantee of continuity of some kind.  I.e., the
> person doing this thing today is the same person who did it yesterday.  In
> order to prove that continuity, all that's needed is a persistent secret that
> only the principal in question knows, which can be used in a zero-knowledge
> fashion.  This can easily be done with 2 parties and relatively mild crypto.
>
> Tying that in any useful way to the "real world" notion of identities is
> probably unnecessary for most or all applications, and often undesirable.
> And that tying is the only reason for a trust relationship with a third-party
> authentication / cert agent.
>
> jb
>
>








-----------------------------------------------------------------------------------
Post ID:462
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-31 01:22:18
Subject:RE: [rest-discuss] idempotent notifications
Message:

> > > A POST message is not only a notification, it is also an update.
> >
> > It need not be.  The body could just be a URI, for example.
>
> You might noticed an apparent contradiction there.  I was assuming that
> by "update" you meant that the POST body was used in determining how
> the state of the callback resource was modified.  This may not be the
> case, because it's possible that all that resource needs to know to
> make a state change is *that* a POST was invoked, not the contents of
> the POST body.
>
> MB

I did.  It left me mightly confused.  :)

The case that boolean notifications are idempotent is that they are flags with
identical meaning.  So when a sink receives 2 of them it has the same effect on
state as when it receives one, and therefore it is not true that the resource
identified by the callback URI necessarily changes state.  On a more literal
level I defer to RFC 2616:
   9.1.2 Idempotent Methods

   Methods can also have the property of "idempotence" in that (aside
   from error or expiration issues) the side-effects of N > 0 identical
   requests is the same as for a single request. The methods GET, HEAD,
   PUT and DELETE share this property.

0 boolean notifications are not the same as 1 notification, but any N > 0
notifications have the same effect as 1 notification.

Now, there _is_ an error in my thoughts from this morning, which is that boolean
notifications overwrite whatever the previous state of the flag (as held on the
sink).  So the proper method is PUT, not GET.

- Lucas







-----------------------------------------------------------------------------------
Post ID:463
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-31 01:34:45
Subject:watched resources must be idempotent
Message:

It should be asked what constitutes a change of state sufficient to trigger a
notification.  A solid working definition is that an idempotent query would have
different results.  It is self evident that non-idempotent queries can't be used
for watch expressions, because otherwise the act of performing a watch changes
the result.

Though this is a trivial observation, I am personally happy to have any little
bit of solid ground.














-----------------------------------------------------------------------------------
Post ID:464
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-31 01:45:00
Subject:request in request
Message:

A recurring theme is requests about requests.  For example, a watch request
needs to express the request to watch, a store-and-forward request needs to
enclose the request to store-and-forward within a request to perform the
store-and-forward, an update request needs to state the parameters of the
callback POST request.

This creates a couple problems.  One, enclosed requests are objects rather than
streams, so are inconsistent with persistent connections.  Two, there are
problems with opacity, since intermediaries have practical reasons to need to do
some rewriting, and since the two requests may be mixed in together.  For
example a store-and-forward CGI needs to rewrite the Host: header to a Via:
header, or even rewrite the target URI to change to host.

An example of how tricky this gets is accept headers in a store-and-forward
chain: the originating host may accept a type that an intermediary doesn't.
Streaming audio, for example.

There may always be clever ways to avoid having to solve the RIR problem, I
don't know.  This post is just to recognize that it exists, since that sometimes
helps break through on an issue.









-----------------------------------------------------------------------------------
Post ID:465
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-31 01:54:00
Subject:Re: [rest-discuss] idempotent notifications
Message:

> I did.  It left me mightly confused.  :)

8-)

> notifications overwrite whatever the previous state of the flag (as held on the
> sink).  So the proper method is PUT, not GET.

Agreed, for boolean notifications.  However, not all notifications are
boolean, the same way that not all resources are boolean.  Sometimes a
subscription is created for more than just knowing *when* state changes.
Sometimes it's created to know *how* state changes.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:466
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-31 02:04:55
Subject:Re: [rest-discuss] watched resources must be idempotent
Message:

> It should be asked what constitutes a change of state sufficient to trigger a
> notification.

In general, that should be up to the resource.  Encapsulation, and all
that jazz.

>  A solid working definition is that an idempotent query would have
> different results.  It is self evident that non-idempotent queries can't be used
> for watch expressions, because otherwise the act of performing a watch changes
> the result.

Well, so far we've been talking about invoking the WATCH method on URIs.
Non-idempotent queries, if I understand you correctly, would be done over
POST and therefore not identifiable with a URI.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:467
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-31 02:14:33
Subject:Re: [rest-discuss] request in request
Message:

> There may always be clever ways to avoid having to solve the RIR problem, I
> don't know.  This post is just to recognize that it exists, since that sometimes
> helps break through on an issue.

In all the funky stuff I've done with HTTP, I've *never* had to
encapsulate an HTTP message.  Given that, I think it's probably safe to
say that if you're doing it, either you're doing something wrong, or
you've got some really bizarre situation (like the one Mike described
recently).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:468
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-31 07:03:15
Subject:Re: [rest-discuss] watched resources must be idempotent
Message:

----- Original Message -----
From: "Lucas Gonze" <lucas@...>


> It should be asked what constitutes a change of state sufficient to
trigger a
> notification.  A solid working definition is that an idempotent query
would have
> different results.

> It is self evident that non-idempotent queries can't be used
> for watch expressions, because otherwise the act of performing a watch
changes
> the result.
Do you mean 'non-idempotent HTTP requests can't be used to create a
subscription'?
Or do you mean 'the evaluation of whether a subscription matches a
particular occurrance must not cause a non-idempotent request to be sent to
the resource that is subscribed'?

BTW - I still maintain that http-based subscriptions and notifications
should be described in terms of any and all possible http methods upon a
resource, regardless of status (success, error, etc.). A subscription should
be able to specify all three : resource, method and status. A notification
should identify all three. This is difficult to describe with the existing
http because the method and status never appear outside the first line of
request or response - there is no current situation where a header holds
either of these values (as far as I know).








-----------------------------------------------------------------------------------
Post ID:469
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-31 06:55:40
Subject:Re: [rest-discuss] idempotent notifications
Message:

Mark Baker wrote:
> 
> ...
>
> Agreed, for boolean notifications. However, not all notifications are
> boolean, the same way that not all resources are boolean. Sometimes a
> subscription is created for more than just knowing *when* state changes.
> Sometimes it's created to know *how* state changes.

We *could* model our resources such that all notifications are boolean.
For instance you would get a notification that a thousand page document
has changed. Then the client uses some WebDAV/DeltaV magic to get a diff
from the version it has to the version the server has.

I like the idea of idempotent notifications because it means that the
listener could go off the network for seven hours and get "back in sync"
on the very first notification it gets, or even before it gets a
notification. So for instance if we were in a chat session and I get cut
off then my chat client could miss a bunch change notifications but sync
up whenever it wanted to. Loose coupling.

So I would say that if an "event" is important enough that a client
wants to know WHAT changed, not just WHEN it changed then the event
should be reified in the server as a resource and persist for some
number of hours or days, unless deleted.

As an *optimization*, it may make sense to have message bodies with
"diffs". But if you detected that you had missed one it would be no big
deal because you could just sync up.

Can you describe an application that is better modeled with
non-idempotent notifications?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:470
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-31 07:03:55
Subject:Re: [rest-discuss] watched resources must be idempotent
Message:

"S. Mike Dierken" wrote:
> 
>...
> 
> BTW - I still maintain that http-based subscriptions and notifications
> should be described in terms of any and all possible http methods upon a
> resource, regardless of status (success, error, etc.). A subscription should
> be able to specify all three : resource, method and status. A notification
> should identify all three. This is difficult to describe with the existing
> http because the method and status never appear outside the first line of
> request or response - there is no current situation where a header holds
> either of these values (as far as I know).

I'm starting to buy Lucas' point that any information in the
notification other than "something happened" must be considered
"advisory" and must be available somewhere on the server. Otherwise if
you miss a single message you get out of sync and I think we're all sick
of systems like that. So to model a chat application, there would be a
resource representing the transcript (perhaps segmented as it began to
get big). If you ever missed a notification there should be an easy way
to get back into sync. If you joined the chat mid-stream you could
actually see what went on before you got there. There would never be any
doubt about whether someone got a particular message or not because they
would all be available as part of the resource (or as independent
resources).

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:471
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-31 07:46:03
Subject:Re: [rest-discuss] idempotent notifications
Message:

I'm not sure idempotency applies to notifications.
I thought it only applied to request/response message exchanges.
A notification is not a request to cause something to happen at the
receiver. It might be an 'http request' message format, but I'm not sure its
a 'conceptual' request.

What is the effect of more than 1 identical notification messages?
If a receiver kept a count of messages, this count would be 'inaccurate' -
but that (hit counts) is not a case we consider for idempotency anyway.
If a receiver waited for a particular event - threshold crossed, etc - and
then deleted itself (stopped listening before/without deleting the
subscription) the next event probably would result in a 404 or something
(listener not found). Is this 'allowable' if notifications are idempotent?
(it'd be like two PUTs or two GETs returned an error on the second request
/because/ of the first request).

Also what is sent in a notification?

a) after a POST
post(body1)+nostate=response(success,reply1)+state1
  notify(??)
post(body1)+state1=response(success,reply2)+state2
  notify(??)
post(body1)+state2=response(success,reply3)+state3
  notify(??)

b) after a PUT
put(body1)+nostate=response(success,reply1)+state1
  notify(??)
put(body1)+stateX=response(success,reply1)+state1
  notify(??)

c) after a DELETE
delete()+stateX=response(success,body1)+nostate
  notify(??)
delete()+nostate=response(error)+nostate
  notify(??)

d) after a GET
get()+state1=response(success,body1)+state1
  notify(??)
get()+state1=response(success,body1)+state1
  notify(??)

option a)
Use body - notify(post,success,body1)

option b)
Use state - notify(post,success,state1)





Mike






-----------------------------------------------------------------------------------
Post ID:472
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-31 07:50:59
Subject:Re: [rest-discuss] watched resources must be idempotent
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>
>
> I'm starting to buy Lucas' point that any information in the
> notification other than "something happened" must be considered
> "advisory" and must be available somewhere on the server. Otherwise if
> you miss a single message you get out of sync and I think we're all sick
> of systems like that.

Don't send deltas (you need sequence and reliable delivery to stay in
synch). If you watch a resource that is a collection, either send a snapshot
of the collection (which could be big - so you fragment via hyper-links like
you mentioned) or don't send any details.

But what is the 'non-delta details' that get sent - the result of applying
the original http request, or a replay of the original http request?








-----------------------------------------------------------------------------------
Post ID:473
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-31 08:08:50
Subject:Why is HTTP special?
Message:

http://www.prescod.net/whyhttp.html

	Why is HTTP (1.1) Special?

People learning REST will probably have the reaction that all of us did
at first, why are these people trying to make HTTP (1.1) into some kind
of universal protocol? Let's start by saying that we aren't quite that
crazy. HTTP is not going to be replacing UDP for gaming or DNS for
naming etc. For legacy reasons it isn't even going to replace SMTP or
POP soon, even though it could do those jobs easily. 

	HTTP is general

Still, we suggest that it makes sense to build a wide range of
applications using HTTP, whether they be asynchronous, peer-to-peer,
etc. At first, you may think our HTTP-fixation is an arbitrary fetish
like a fondness for cats over dogs. This is not so. HTTP really is a
better protocol than SMTP or POP or IMAP in a very concrete sense. 

HTTP fits into a class of protocols that are designed to general
purpose. Linda is a famous one. The various RPC protocols are also very
general purpose. Linda bills itself a "coordination language" -- used
for coordinating multiple software processes. Until I have a precise
definition of that term I can't say for sure whether RPC protocols and
HTTP are also coordination languages but the term seems to apply to
them. They are protocols for coordinating multiple independent software
components. 

Definitions aside, the point remains: in terms of generality, HTTP has
more in common with SOAP than with SMTP. It is not just about moving
HTML pages from servers to clients. 

	General purpose protocol

I don't think that I can "prove" that HTTP is more general than other
protocols in a mathematically rigorous way. But I can nevertheless give
you a feeling for the generality of HTTP. 

The most basic computational device is a Turing machine. A Turing
machine is driven by a program expressed as a set of states and a tape.
The tape represents some kind of storage. In the more advanced forms of
the Turing machine, you can read and write to the storage and address
the storage locations by numeric ID. 

HTTP is similar. HTTP allows you to read from the storage with GET,
write to it with PUT and the addresses are URIs. Because disk space in
the real world is limited, HTTP also has DELETE. And because multiple
people will be using the system at once, there is a need for a method
that will create guaranteed-new "storage locations". This is POST. POST
is so incredibly general that you can use it for other things. But you
only absolutely need POST to deal with situations where there might be
race conditions. These primitives allow HTTP to be used as a
coordination language. 

Instead of a state machine, of course, we write our HTTP programs in
general purpose programming languages like Python or C++. The web server
can act as state for the computation (though it may also do much more).
This may not seem immediately interesting because most people have grown
accustomed to using RAM and hard disks for their state. But HTTP allows
us to build distributed applications that share state through HTTP
servers. SMTP lacks equivalent "methods". POP lacks equivalent
"methods". 

FTP is the closest protocol to HTTP conceptually. But really the gap
between FTP and HTTP is huge. FTP lacks the POST method. It lacks
content negotation. It lacks well-defined caching semantics. More
important, though, FTP's semantics do not allow the server to be an
active participant in the computation. HTTP very precisely defines how
the server can do complicated computations by itself. It is not just a
holder of bits -- it can embody a complex service! The web as we know it
demonstrates the extent to which it has succeeded. The Web is an
excellent, scalable, sophisticated e-commerce platform and this is
largely due to smart usage of HTTP by e-commerce providers. 

HTTP is also very extensible through new headers, new methods, new URIs
and new content types. Let's concentrate on the extension of the four
main methods (GET, PUT, POST, DELETE). HTTP 1.1 defines some others.
Extensions to HTTP also define new ones (such as WebDAV). Although the
four methods are "sufficient", it is nice to have other ones for
efficiency and modeling simplicity. For instance WebDAV has a LOCK
method which could be modeled as a POST of a LOCk object. In theory the
LOCK method may be a bit more efficient and a little bit simpler to
implement. 

	Modeling applications in HTTP

It is possible to compose these methods into an infinite variety of
applcations. In some trivial sense you could run the web on top of SMTP
by using it as a tunnel for HTTP. But in a much more concrete sense you
could model SMTP as a series of HTTP POSTs, GETs and PUTs. The resulting
protocol would be no more complicated than SOAP and probably about as
efficient. Most people are probably more comfortable with POP (which
they probably use every day) than with SMTP, so I'll use that as an
example. 

What if your "mailbox" were just a password-protected section of your
website. It would store a bunch of resources with various content types
(mostly text/plain). Your various mail clients would GET from it when
they want to update your client view. When they want to remove a message
they DELETE it. When they want to send a message they POST it to the
mailbox on someone else's server. If the other server wasn't available
then you would instead POST it to queuing intermediary. If you wanted to
update a message in the queue before it was sent you could PUT to it. 

You can see how this modeling process works. You think about the things
you want to work with as resources and you apply HTTP methods to them.
One day I hope and expect that Web resource modeling will be as widely
understood as object oriented modeling. 

If you were away from a proper mail client you would just browse your
mailbox using a standard web browser. Content negotation would ensure
that your mailbox "looks like" a web page when you access it from a
browser. Every mail server could easily have the functionality of
HoTMaiL (which is, after all, just an HTTP-based user interface). 

Unlike SMTP, POP, FTP etc., HTTP is a protocol that you can directly
model applications in terms of. We can model all of the features of
SMTP, POP, FTP etc. in HTTP. The interesting thing is that it usually
isn't much of a conceptual stretch to do so. Just as it is typically
easy to map any data format into XML (once you get the hang of it), it
is easy to map any protocol into HTTP (once you get the hang of it).
Just as any reasonable person will ask, when they see a new data
interchange syntax: "Why couldn't you have done that as XMl", a person
could ask of a new protocol, "Why didn't you do that as HTTP." Think of
HTTP as the emerging default, quasi-universal syntax for TCP-based
protocols, as XML is the default, quasi-universal syntax for structured
data. 

I say "quasi-universal" because there are limits. Just as XML isn't
really great for binary media, HTTP isn't really great for streaming
real-time media. So for those applications you should use something
else. But if your application is within HTTP's purview (i.e. structured
messaging), then you should think twice before inventing Yet Another Way
to manage connections, and manage content-negotiation and manage the
header/body split and invent yet another namespace, and figure out a new
way to handle caching etc. There are huge economies of scale in figuring
out all of these things just once for HTTP. 

	Versus Other Generic Protocols

So HTTP is not properly compared with most of the other Internet
protocols. It is in a totally different class of generality. It might
more relevant to compare it with Tuple-space models (Linda, JavaSpaces,
Tspaces etc.) and the RPC protocols (DCOM, SOAP RPC, etc.). How does it
compare? 

Well, the tuple-space models seem to (as per the name!) require some
kind of shared environment called the tuple space. I don't see how this
can scale up to an application the size of the Web. Maybe I
misunderstand something. 

HTTP's big advantage over RPC protocols (and this is another advantage
over FTP) is that its whole model is organized around addresses.
Ubiquitous, powerful, direct and indirect addressing is what made the
Web so incredibly powerful. RPC protocols hide the "addresses" of
objects in parameters. When you pass a UUID to access a UDDI TModel, you
are really addressing the thing, but because the address is hidden in a
method, you can't address that thing anywhere, such as in an XSLT
stylesheet, or an RDF assertion, or a web browser bookmark, or the
URL-line of a browser, or ... 

RPC divides the world up into self-contained address spaces. This is the
antithesis of the unviversal naming used on the Web. This will cause so
many problems that I am confident predicting that RPC protocols will
fail. 

	HTTP Limitations

There is no doubt that HTTP has its limitations. For one thing there is
not much software out there that knows how to deal with HTTP in a
peer-to-peer or asychronous fashion. There is a lot of software out
there that claims to use HTTP but is well behind the HTTP specification.
Also, HTTP is not going to take over the universe from established
protocols with large software bases. Rather it will capture new markets
that have not yet been tapped. 

Finally, there is a lot of work to do in order to standarize HTTP
solutions to common problems. For instance WebDAV isa standardization of
content management solutions in the HTTP framework. HTTPEvents is a
standardization of HTTP notifications ("asynch", "callbacks" whatever
you want to call it). There are also proposals for making HTTP more
reliable in the sense that every message gets delivered once and only
once.






-----------------------------------------------------------------------------------
Post ID:474
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-31 08:19:12
Subject:Re: [rest-discuss] idempotent notifications
Message:

"S. Mike Dierken" wrote:
> 
> I'm not sure idempotency applies to notifications.
> I thought it only applied to request/response message exchanges.
> A notification is not a request to cause something to happen at the
> receiver. It might be an 'http request' message format, but I'm not sure its
> a 'conceptual' request.

Well if each notification is a "diff" then the requrest is to please
update your local copy so you are in sync with the rest of us.

My point is that 

 a) getting the same notification twice should be harmless

 b) it should always be possible for a client to build up the same
internal state by looking at the resource and its subordinates that it
would have gotten by collecting notifications

> What is the effect of more than 1 identical notification messages?
> If a receiver kept a count of messages, this count would be 'inaccurate' -
> but that (hit counts) is not a case we consider for idempotency anyway.
> If a receiver waited for a particular event - threshold crossed, etc - and
> then deleted itself (stopped listening before/without deleting the
> subscription) the next event probably would result in a 404 or something
> (listener not found). Is this 'allowable' if notifications are idempotent?
> (it'd be like two PUTs or two GETs returned an error on the second request
> /because/ of the first request).

That's borderline. But the subscriber is acting on behalf of a Client
and so I feel it has more leeway for funny behaviour than a Server. When
I say that notifications are idempotent I just mean the two things I
said above.

> Also what is sent in a notification?

I claim, basically nothing. Even less than the HttpEvents spec says. I
claim it should contain:

 1. the HTTP method (Lucas suggests PUT)

 2. the subscriber URI

 3. the subscription URI (in case you want to unsubscribe)

 4. the URI that changed (in case you want to get into sync)

As an *optimization* it could also include information that would help
the client to keep up without constantly pulling extra information from
the server. For instance it could include a "diff" from a previous
labelled version -- but the cient could discard that if it wanted and go
"back to the source." It could also say "what happened" in some HTTP
sense (PUT, GET, DELETE, POST) but again it could figure that stuff out
just by looking at the resource.

If a resource is huge and/or composite (like a website) then for the
purposes of notification, another resource should be generated like a
"changelog". Then you would watch just the changelog. When it changed
you would look at it to see what individual web page had changed.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:475
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-31 08:28:26
Subject:Re: [rest-discuss] watched resources must be idempotent
Message:

"S. Mike Dierken" wrote:
> 
>...
> 
> Don't send deltas (you need sequence and reliable delivery to stay in
> synch). If you watch a resource that is a collection, either send a snapshot
> of the collection (which could be big - so you fragment via hyper-links like
> you mentioned) or don't send any details.

Sending deltas as an *optimization* sounds okay to me...they could be
deltas against a once-a-day golden version so that you can miss several
messages without running into problems. But the point is that you could
always discard the deltas and really sync up properly if you want.

> But what is the 'non-delta details' that get sent - the result of applying
> the original http request, or a replay of the original http request?

You have this notion of the "original http request" that I am trying to
wean you from. If I fire up vi through an ssh connection to edit a
document, there is no original HTTP request. There is just a change. 
The details that get sent would be up to the application. My only
requirements on them would be that a) the client can ignore them and not
lose out on anything other than performance and b) the client can
receive them twice without worrying about corrupting its internal state
(another problem with deltas if you aren't intelligent about saying WHAT
you are applying the delta to).

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:476
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-31 13:24:52
Subject:RE: [rest-discuss] watched resources must be idempotent
Message:

> > It is self evident that non-idempotent queries can't be used
> > for watch expressions, because otherwise the act of performing a watch
> changes
> > the result.

> Do you mean 'non-idempotent HTTP requests can't be used to create a
> subscription'?

No.

> Or do you mean 'the evaluation of whether a subscription matches a
> particular occurrance must not cause a non-idempotent request to be sent to
> the resource that is subscribed'?

Yes.








-----------------------------------------------------------------------------------
Post ID:477
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-31 13:29:36
Subject:RE: [rest-discuss] request in request
Message:

As an example of a really bizarre situation:

There is a store-and-forward gateway.  It has an interface for receiving
messages to forward.  The interface includes authentication.  It is able to
forward messages to recipients whose interface also includes authentication.

> From: Mark Baker [mailto:distobj@...]
...
> In all the funky stuff I've done with HTTP, I've *never* had to
> encapsulate an HTTP message.  Given that, I think it's probably safe to
> say that if you're doing it, either you're doing something wrong, or
> you've got some really bizarre situation (like the one Mike described
> recently).
>
> MB







-----------------------------------------------------------------------------------
Post ID:478
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-01-31 13:28:59
Subject:RE: [rest-discuss] idempotent notifications
Message:

> > notifications overwrite whatever the previous state of the flag (as
> held on the
> > sink).  So the proper method is PUT, not GET.
>
> Agreed, for boolean notifications.  However, not all notifications are
> boolean, the same way that not all resources are boolean.  Sometimes a
> subscription is created for more than just knowing *when* state changes.
> Sometimes it's created to know *how* state changes.
>
> MB

I'd make the argument that messages about "how" are updates, not notifications.
The reason to make a distinction is just to enable divide-and-conquer -- it may
be that you can solve the when and how problems more easily separately than
together.  ...the "how" problem, for example, might be best tackled as a version
control issue.

- Lucas







-----------------------------------------------------------------------------------
Post ID:479
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-31 16:21:49
Subject:Re: [rest-discuss] idempotent notifications
Message:

If notifications contain updates then they must be
POSTs.  This seems ugly.

The agent requesting notification supplied a
notification URI.  It is the responsibility of
the subscriber to know to what resources that
notification URI corresponds.

Unless we are prepared to specify a subsciption
management protocol, there is no need to require
that the subsciption resource be in the
notification.

If we care about synchronization, we should
specify other HTTP methods for version management.
These would be useful regardless of subscription.
I think some are in WebDAV.

I don't think any of the existing HTTP methods
communicate what notifcation communicates.  I
think there are basically 3 messages, all of which
have NO message bodies.

CREATED /notification/path HTTP/1.1
(allowing the ability to watch for the creation of
certain types of resources)

CHANGED /notification/path HTTP/1.1

DELETED /notifiation/path HTTP/1.1
when there will be no more changes
and there is now no accessible info about the
resource.


-Alex-





___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








On Thu, 31 Jan 2002, Paul Prescod wrote:

> "S. Mike Dierken" wrote:
> >
> > I'm not sure idempotency applies to notifications.
> > I thought it only applied to request/response message exchanges.
> > A notification is not a request to cause something to happen at the
> > receiver. It might be an 'http request' message format, but I'm not sure its
> > a 'conceptual' request.
>
> Well if each notification is a "diff" then the requrest is to please
> update your local copy so you are in sync with the rest of us.
>
> My point is that
>
>  a) getting the same notification twice should be harmless
>
>  b) it should always be possible for a client to build up the same
> internal state by looking at the resource and its subordinates that it
> would have gotten by collecting notifications
>
> > What is the effect of more than 1 identical notification messages?
> > If a receiver kept a count of messages, this count would be 'inaccurate' -
> > but that (hit counts) is not a case we consider for idempotency anyway.
> > If a receiver waited for a particular event - threshold crossed, etc - and
> > then deleted itself (stopped listening before/without deleting the
> > subscription) the next event probably would result in a 404 or something
> > (listener not found). Is this 'allowable' if notifications are idempotent?
> > (it'd be like two PUTs or two GETs returned an error on the second request
> > /because/ of the first request).
>
> That's borderline. But the subscriber is acting on behalf of a Client
> and so I feel it has more leeway for funny behaviour than a Server. When
> I say that notifications are idempotent I just mean the two things I
> said above.
>
> > Also what is sent in a notification?
>
> I claim, basically nothing. Even less than the HttpEvents spec says. I
> claim it should contain:
>
>  1. the HTTP method (Lucas suggests PUT)
>
>  2. the subscriber URI
>
>  3. the subscription URI (in case you want to unsubscribe)
>
>  4. the URI that changed (in case you want to get into sync)
>
> As an *optimization* it could also include information that would help
> the client to keep up without constantly pulling extra information from
> the server. For instance it could include a "diff" from a previous
> labelled version -- but the cient could discard that if it wanted and go
> "back to the source." It could also say "what happened" in some HTTP
> sense (PUT, GET, DELETE, POST) but again it could figure that stuff out
> just by looking at the resource.
>
> If a resource is huge and/or composite (like a website) then for the
> purposes of notification, another resource should be generated like a
> "changelog". Then you would watch just the changelog. When it changed
> you would look at it to see what individual web page had changed.
>
>  Paul Prescod
>








-----------------------------------------------------------------------------------
Post ID:480
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-31 16:46:57
Subject:Re: [rest-discuss] idempotent notifications
Message:

> We *could* model our resources such that all notifications are boolean.
> For instance you would get a notification that a thousand page document
> has changed. Then the client uses some WebDAV/DeltaV magic to get a diff
> from the version it has to the version the server has.
> 
> I like the idea of idempotent notifications because it means that the
> listener could go off the network for seven hours and get "back in sync"
> on the very first notification it gets, or even before it gets a
> notification. So for instance if we were in a chat session and I get cut
> off then my chat client could miss a bunch change notifications but sync
> up whenever it wanted to. Loose coupling.

Sure, but you're placing an obligation on the server and the network
to ensure that the notification arrives in order to go do your
"catching up".  That's quite a burden.

An alternative would be that the client requests a resynch when it
comes back online.  This would be done with a GET.  Part of the
request could include the last message id retrieved, and the
server could then send all messages on the GET response that
would get the client up to date.

> So I would say that if an "event" is important enough that a client
> wants to know WHAT changed, not just WHEN it changed then the event
> should be reified in the server as a resource and persist for some
> number of hours or days, unless deleted.

How's that networking adage go?  "Send as much as you can, as soon as
you can".

> As an *optimization*, it may make sense to have message bodies with
> "diffs". But if you detected that you had missed one it would be no big
> deal because you could just sync up.

Right.

> Can you describe an application that is better modeled with
> non-idempotent notifications?

All of them? 8-)

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:481
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-31 17:03:50
Subject:Re: [rest-discuss] idempotent notifications
Message:

Mark Baker wrote:
> 
> > We *could* model our resources such that all notifications are boolean.
> > For instance you would get a notification that a thousand page document
> > has changed. Then the client uses some WebDAV/DeltaV magic to get a diff
> > from the version it has to the version the server has.
> >
> > I like the idea of idempotent notifications because it means that the
> > listener could go off the network for seven hours and get "back in sync"
> > on the very first notification it gets, or even before it gets a
> > notification. So for instance if we were in a chat session and I get cut
> > off then my chat client could miss a bunch change notifications but sync
> > up whenever it wanted to. Loose coupling.
> 
> Sure, but you're placing an obligation on the server and the network
> to ensure that the notification arrives in order to go do your
> "catching up".  That's quite a burden.
> 
> An alternative would be that the client requests a resynch when it
> comes back online.  

Right, I mentioned that point: "even before it gets a notification"

> ... This would be done with a GET.  Part of the
> request could include the last message id retrieved, and the
> server could then send all messages on the GET response that
> would get the client up to date.

If notifications have IDs then they *are* idempotent. The client will
just discard a notification with a message ID that it has already seen.

> > So I would say that if an "event" is important enough that a client
> > wants to know WHAT changed, not just WHEN it changed then the event
> > should be reified in the server as a resource and persist for some
> > number of hours or days, unless deleted.
> 
> How's that networking adage go?  "Send as much as you can, as soon as
> you can".

As long as it is an optimization.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:482
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-31 17:33:10
Subject:Re: [rest-discuss] idempotent notifications
Message:

> If notifications have IDs then they *are* idempotent. The client will
> just discard a notification with a message ID that it has already seen.

Right.  I thought by "idempotent" you meant in the sense of the method
being used.

In this case, the server only needs to use POST, not M-POST, because
the client provides the context (the callback URI) in which idempotence
(or lack thereof) is determined.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:483
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-31 17:53:24
Subject:Re: [rest-discuss] idempotent notifications
Message:

Mark Baker wrote:
> 
> > If notifications have IDs then they *are* idempotent. The client will
> > just discard a notification with a message ID that it has already seen.
> 
> Right.  I thought by "idempotent" you meant in the sense of the method
> being used.

If the events are *logically* idempotent then why wouldn't you want to
use an idempotent method?

> In this case, the server only needs to use POST, not M-POST, because
> the client provides the context (the callback URI) in which idempotence
> (or lack thereof) is determined.

M-POST, isn't that a SOAP thing?

I would say PUT would be the right method. You are "PUT"ting the binary
notification that "something changed". As an optimization you may
include a diff of what changed. But the core semantic content of the
message is idempotent. If you get it twice, ignore the second.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:484
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-31 18:25:38
Subject:Re: [rest-discuss] idempotent notifications
Message:

"S. Alexander Jacobson" wrote:
> 
> If notifications contain updates then they must be
> POSTs.  This seems ugly.

I agree. In recent mails I've been suggesting PUT.

> The agent requesting notification supplied a
> notification URI.  It is the responsibility of
> the subscriber to know to what resources that
> notification URI corresponds.

Orthogonal issue. There is very little no cost in having a header with
the notification URI and it might be useful for simplifying client-side
state management.

> Unless we are prepared to specify a subsciption
> management protocol, there is no need to require
> that the subsciption resource be in the
> notification.

We are doing somewhat of a subscription management protocol. The latest
spec (from yesterday) incorporates Jeff Bone's ideas about:

 1. Expiry
 2. Acknowledgment from the client that it really wants to be subscribed

Plus we have always said that a client may unsubscribe by DELETEing a
subscription resource.

> If we care about synchronization, we should
> specify other HTTP methods for version management.
> These would be useful regardless of subscription.
> I think some are in WebDAV.

Agreed.

> I don't think any of the existing HTTP methods
> communicate what notifcation communicates.  I
> think there are basically 3 messages, all of which
> have NO message bodies.

The message body is an important and useful *optimization*. Sending
diffs is really important for performance. They just have to be set up
so that even if one is "dropped" you can resync easily by going back to
the subscription resource.

> CREATED /notification/path HTTP/1.1
> (allowing the ability to watch for the creation of
> certain types of resources)
> 
> CHANGED /notification/path HTTP/1.1
> 
> DELETED /notifiation/path HTTP/1.1
> when there will be no more changes
> and there is now no accessible info about the
> resource.

I no longer think it is important to say which of these things happened.
You notify the resource of the change. Maybe you have a body that says
what changed. Maybe you don't. If you don't, or it is useless because of
some message that was lost earlier, then you re-sync from the data
source.

You say CREATED is important because if allows you the ability to watch
for the creation of certain types of resources. But you could also model
this as a WATCH on a query. "The list of all stock symbols."

I think that a subscription could outlive a DELETEion. If the resource
goes away and them comes back and then goes away, why not keep
delivering notifications?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:485
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-31 19:26:36
Subject:Re: [rest-discuss] idempotent notifications
Message:

On Thu, 31 Jan 2002, Paul Prescod wrote:
> > The agent requesting notification supplied a
> > notification URI.  It is the responsibility of
> > the subscriber to know to what resources that
> > notification URI corresponds.
>
> Orthogonal issue. There is very little no cost in having a header with
> the notification URI and it might be useful for simplifying client-side
> state management.

The client has to do some form of state management
anyway.  If the client needs the URI, it can
encode that in the notification URL.

The problem for the server is that multiple URIs
may map to the same resource.  Those different
URIs may be used by different clients for various
purposes.  If the server has to send a URI, it
also has to know which URI the client used to
request notification about the Resource.
That is really ugly.

> > Unless we are prepared to specify a subsciption
> > management protocol, there is no need to require
> > that the subsciption resource be in the
> > notification.
>
> We are doing somewhat of a subscription management protocol. The latest
> spec (from yesterday) incorporates Jeff Bone's ideas about:

The subscription URL should be delivered in the
response to notification.  It is a huge waste to
deliver it with each notification.

Again, if the client really want it, the client
could encode it in the notification URL.

>  1. Expiry
>  2. Acknowledgment from the client that it really wants to be subscribed
>
> Plus we have always said that a client may unsubscribe by DELETEing a
> subscription resource.

The client should be able to do subscription
modifications in reply to a notification request.

In particular, some set of 40x responses to a
notification should be the equivalent of
unsubscription. e.g. if the response to a
notification is 403 FORBIDDEN, that is a strong
hint that you don't want the subscription anymore.

> > I don't think any of the existing HTTP methods
> > communicate what notifcation communicates.  I
> > think there are basically 3 messages, all of which
> > have NO message bodies.
>
> The message body is an important and useful *optimization*. Sending
> diffs is really important for performance. They just have to be set up
> so that even if one is "dropped" you can resync easily by going back to
> the subscription resource.

So the notion is that the notification message may
optionally include a last update.  If the content
is optional, I don't think you should really be
using PUT.  Because a series of empty PUT bodies
doesn't mean that nothing has changed, only that
the server decided not to send it.

> > CREATED /notification/path HTTP/1.1
> > (allowing the ability to watch for the creation of
> > certain types of resources)
> >
> > CHANGED /notification/path HTTP/1.1
> >
> > DELETED /notifiation/path HTTP/1.1
> > when there will be no more changes
> > and there is now no accessible info about the
> > resource.
>
> I no longer think it is important to say which of these things happened.
> You notify the resource of the change. Maybe you have a body that says
> what changed. Maybe you don't. If you don't, or it is useless because of
> some message that was lost earlier, then you re-sync from the data
> source.

I think there is a difference between having an
empty body and having a NULL body.

> You say CREATED is important because if allows you the ability to watch
> for the creation of certain types of resources. But you could also model
> this as a WATCH on a query. "The list of all stock symbols."

No because then you can't watch a particular
resource.

Suppose that you are modeling the set of seats in
a theater.  Suppose you want to watch the seat
next to yours:

CREATED: someone sat down in the seat (you can't
         invite a friend to sit next to you)
CHANGED: the person took off her coat
CHANGED: the person she took off her shoes
DELETED: she got up and left and the seat is
 	 now available again

(This example does not include the possibility
that the person could have no mass (be an empty
body), but other applications have that
possibility)

> I think that a subscription could outlive a DELETEion. If the resource
> goes away and them comes back and then goes away, why not keep
> delivering notifications?

ok.  but I think you still want deletion.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:486
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-31 20:15:01
Subject:Re: [rest-discuss] idempotent notifications
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> The client has to do some form of state management
> anyway.  If the client needs the URI, it can
> encode that in the notification URL.

I'm trying to preserve the ability for the notification URL to be
mailto:paul@... .

> The problem for the server is that multiple URIs
> may map to the same resource.  Those different
> URIs may be used by different clients for various
> purposes.  If the server has to send a URI, it
> also has to know which URI the client used to
> request notification about the Resource.
> That is really ugly.

Does it? Or does it just need to send *a* URI? As long as the client can
retrieve the changed state from the URI, maybe it doesn't care if it is
"the same" URI. I have to think that through more when I have time.

>...
> The subscription URL should be delivered in the
> response to notification.  It is a huge waste to
> deliver it with each notification.

Same reasoning as above. Let's say you notice you're getting random,
annoying notifications from some service. Maybe all else has failed and
it is up to a human being to cancel the notifications. The header is
equivalent to this:

> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com

> Again, if the client really want it, the client
> could encode it in the notification URL.

That' going to be one really ugly URL! Anyhow, my three concerns are as
above:

 1. The software may not ask for it but after it gets accidentally
uninstalled, whoever needs to turn off the notifications needs it.

 2. The subscriber may be just be an email address in which case it
isn't possible to arbitrarily munge the subscriber URI.

>...
> The client should be able to do subscription
> modifications in reply to a notification request.
> 
> In particular, some set of 40x responses to a
> notification should be the equivalent of
> unsubscription. e.g. if the response to a
> notification is 403 FORBIDDEN, that is a strong
> hint that you don't want the subscription anymore.

Actually, right now it works the opposite way. If the subscriber doesn't
respond: "Yes, please keep sending me crap" then the sender must quit.
Maybe that obviates point "1" above. 

>...
> So the notion is that the notification message may
> optionally include a last update.  If the content
> is optional, I don't think you should really be
> using PUT.  

My point is that the semantic content of the message is merely:
"something changed". It is a PUT of a boolean. Everything else is up to
the application and should be JUST optimization.

> ... Because a series of empty PUT bodies
> doesn't mean that nothing has changed, only that
> the server decided not to send it.

I think any particular application would either ALWAYS send a diff (or a
message indicating why it didn't send a diff) or NEVER send a diff. The
body is optional at the notification spec level. Some apps may bother
with diffs and some may not.

>...
> I think there is a difference between having an
> empty body and having a NULL body.

I want to leave the structure of the body entirely up to the
application, as HTTP does. I would just put constraints on its semantics
(as HTTP does). 1. A notification should not send information that
cannot be retrieved otherwise (everything other than the boolean is
considered "optimization"). 2. It must not be possible for a client to
get confused if it misses a message or gets one twice.

>...
> Suppose that you are modeling the set of seats in
> a theater.  Suppose you want to watch the seat
> next to yours:
> 
> CREATED: someone sat down in the seat (you can't
>          invite a friend to sit next to you)
> CHANGED: the person took off her coat
> CHANGED: the person she took off her shoes
> DELETED: she got up and left and the seat is
>          now available again

My model is that you get a notification that something happened in the
seat next to you. You look. If there is someone there and there wasn't
before, then it was CREATEd. If there was someone there before and there
isn't now, it was DELETEd. If the value changed it was CHANGED.

If it is vital to know that someone sat down and THEN they took off
their coat and THEN they took off their shoes and THEN they left then
you reify that on the server.

http://www.myseat.com/seat/11213/event_1 = CREATED
http://www.myseat.com/seat/11213/event_2 = CHANGED
http://www.myseat.com/seat/11213/event_3 = CHANGED
http://www.myseat.com/seat/11213/event_4 = DELETED

The list of all such events is available at:

http://www.myseat.com/seat/11213/events

If a customer want the detailed events, they can watch this. If you
don't care about the order of events, you just watch the seat. If there
are twenty people who care about this seat and some of them are off the
network for a time then they can all get back in sync by looking at that
URI.

Because it is necessary to handle this circumstance where clients go
offine and come back on, it is necessary that messages be essentially
irrelevant except for their timing. That's why I don't want to
standardize any indication of HOW something changed. A particular
application can do this *as an optimization* for clients who happen to
have always-on connections.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:487
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-31 20:57:09
Subject:Re: [rest-discuss] idempotent notifications
Message:

> If the events are *logically* idempotent then why wouldn't you want to
> use an idempotent method?

An idempotent POST != an idempotent PUT.  This goes back to the meaning
of PUT vs. POST.

If you assume that these notifications carry no information, which I
believe you've been doing, then I could understand why you'd see them
as equivalent.  But if you accept my "optimization" mentioned earlier,
that the body should carry some representation of the change, then
those representations mean different things when done with PUT or
POST.

> > In this case, the server only needs to use POST, not M-POST, because
> > the client provides the context (the callback URI) in which idempotence
> > (or lack thereof) is determined.
> 
> M-POST, isn't that a SOAP thing?

No, it's from RFC 2774.  It's what you were trying to do with RPOST
earlier.

> I would say PUT would be the right method. You are "PUT"ting the binary
> notification that "something changed". As an optimization you may
> include a diff of what changed. But the core semantic content of the
> message is idempotent. If you get it twice, ignore the second.

PUT is *a* right method, but so is POST.  It depends on the app, and
on what the subscriber wants.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:488
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-31 21:00:17
Subject:Re: [rest-discuss] idempotent notifications
Message:

----- Original Message -----
From: "S. Alexander Jacobson" <alex@...>

>
> I don't think any of the existing HTTP methods
> communicate what notifcation communicates.  I
> think there are basically 3 messages, all of which
> have NO message bodies.
>
> CREATED /notification/path HTTP/1.1
> (allowing the ability to watch for the creation of
> certain types of resources)
>
> CHANGED /notification/path HTTP/1.1
>
> DELETED /notifiation/path HTTP/1.1
> when there will be no more changes
> and there is now no accessible info about the
> resource.
>

I see six possible messages - only some of which might make sense with Web
REST.
They are: create, read, update, delete, add and remove. The last two - add
and remove - apply to collections.

At first I thought 'create' might only apply to a type-based or class-based
system, but with the Web, you can reference instances outside the scope of
their lifetime (which is wicked cool). So watching for the create of a
particular resource does make sense. If you want to do type-based stuff -
like watching for a new resource of a certain type - you would model the
type as a collection of all instances and look for 'add'.

So... I concur with Alex about notification messages identifying the type of
change made - but I would like all six noted here.
Paul wants only 'changed', but I see little extra cost to identifying the
type of change and I do see cost using further messages to identify the type
of change. I'm thinking of pub/sub with many many listeners - you'd get an
'implosion' of 'was that change a delete or not?' If listeners almost never
care or try to find out, then it's not as big a deal.
Another thing, while I'm up here in the ivory tower, since I would like a
notification for 'read', that wouldn't make sense via a 'change'
notification. (The reason I want a 'read' is that when coupled with a
response status of 'security error' you can detect security issues and
stuff. And I know that non-http based modifications don't have these
concepts, but they can be mapped.)











-----------------------------------------------------------------------------------
Post ID:489
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-01-31 21:02:05
Subject:Re: [rest-discuss] idempotent notifications
Message:

----- Original Message -----
From: "S. Alexander Jacobson" <alex@...>
>
> The problem for the server is that multiple URIs
> may map to the same resource.  Those different
> URIs may be used by different clients for various
> purposes.  If the server has to send a URI, it
> also has to know which URI the client used to
> request notification about the Resource.
> That is really ugly.
>

Multiple URI mappings is a very important situation and any notification
spec should describe the expected behavior. I doubt that mandating that all
URI mappings receive the event will fly - but that would be the easiest for
the clients.






-----------------------------------------------------------------------------------
Post ID:490
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-31 21:12:44
Subject:Re: [rest-discuss] idempotent notifications
Message:

Mark Baker wrote:
> 
>...[M-POST]
> 
> No, it's from RFC 2774.  It's what you were trying to do with RPOST
> earlier.

Not according to grep. http://www.ietf.org/rfc/rfc2774.txt

But anyhow, I get your point. M-POST is some kind of reliable post with
a message ID.

>...
> PUT is *a* right method, but so is POST.  It depends on the app, and
> on what the subscriber wants.

Are you deliberately avoiding examples? 

Would you also say that some times DELETE is an appropriate
notification? 

Is the right method chosen at the application level or should the client
TELL the server what it wants the server to do in a standardized way?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:491
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-31 21:19:33
Subject:Re: [rest-discuss] idempotent notifications
Message:

"S. Mike Dierken" wrote:
> 
> ...
> 
> So... I concur with Alex about notification messages identifying the type of
> change made - but I would like all six noted here.
> Paul wants only 'changed', but I see little extra cost to identifying the
> type of change and I do see cost using further messages to identify the type
> of change. I'm thinking of pub/sub with many many listeners - you'd get an
> 'implosion' of 'was that change a delete or not?' 

Fine. So you admit that it is an optimization. All I want to do is leave
the precise details of the optimization to the application. If it wants
to send Unix-format diffs, then it can. If it wants to have six event
types, then it can. If it wants twenty event types, then it can. All I
ask is that the information about what happened also exist in some form
on the web server so that people who miss a message can get caught up.

> ... If listeners almost never
> care or try to find out, then it's not as big a deal.
> Another thing, while I'm up here in the ivory tower, since I would like a
> notification for 'read', that wouldn't make sense via a 'change'
> notification. (The reason I want a 'read' is that when coupled with a
> response status of 'security error' you can detect security issues and
> stuff. And I know that non-http based modifications don't have these
> concepts, but they can be mapped.)

You could do a regular CHANGE watch on the file that logs READs. Then if
you miss a notification you can always get caught up by reading the
READ-logfile. If the only place that information is stored is in the
notification then one lost notification and you won't know that some
hacker broke into your system.

As an optimization, notifications about the logfile could of course
include a summary of what happened. The client would only resynch from
the actual logfile resource if it realized that it missed a
notification.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:492
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-31 21:39:14
Subject:Re: [rest-discuss] idempotent notifications
Message:

> So... I concur with Alex about notification messages identifying the type of
> change made - but I would like all six noted here.
> Paul wants only 'changed', but I see little extra cost to identifying the

My objection to communicating the type of change is that it's counter to
what WATCH means.  WATCH means "Watch for change of state".  There are
*many* ways in which state may change, and none of those should matter
for WATCH.  All that matters is what the change is.

Re CREATE, CHANGE, DELETE, I'm asking that WATCH mean CHANGE.  CREATE
and DELETE can be determined by subscribing to a CHANGE of the
container of the resource in question.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:493
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-31 21:40:46
Subject:Re: [rest-discuss] idempotent notifications
Message:

Mark Baker wrote:
> 
> ...
>
> Re CREATE, CHANGE, DELETE, I'm asking that WATCH mean CHANGE.  CREATE
> and DELETE can be determined by subscribing to a CHANGE of the
> container of the resource in question.

Would you not say that the deletion of an object is a change of the
object? Before it returned 200 and a message body, now it returns 404
and an error report? And vice versa?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:494
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-31 21:59:04
Subject:Re: [rest-discuss] idempotent notifications
Message:

> > 
> > No, it's from RFC 2774.  It's what you were trying to do with RPOST
> > earlier.
> 
> Not according to grep. http://www.ietf.org/rfc/rfc2774.txt

That's because it defines the "M-" prefix that can be used with any
HTTP method.

> But anyhow, I get your point. M-POST is some kind of reliable post with
> a message ID.

Not exactly, but it doesn't matter here.

> > PUT is *a* right method, but so is POST.  It depends on the app, and
> > on what the subscriber wants.
> 
> Are you deliberately avoiding examples? 

Yes, because they're a pain in the ass to describe.  Ok, so without going
into detail...

Consider two stock quote services.  One pumps out absolute values, and
the other pumps out deltas.  The former could notify with PUT, and the
latter could notify with POST.

> Would you also say that some times DELETE is an appropriate
> notification? 

If that's the way the subscriber wants to know about something, I
suppose so.  But there's no body, and a successful notification can only
happen once.  I can't think of a case where I'd need to use it.

> Is the right method chosen at the application level or should the client
> TELL the server what it wants the server to do in a standardized way?

Not sure what the former means, but the latter is what I had in mind
(and what we've implemented).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:495
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-31 22:15:01
Subject:Re: [rest-discuss] idempotent notifications
Message:

> > Re CREATE, CHANGE, DELETE, I'm asking that WATCH mean CHANGE.  CREATE
> > and DELETE can be determined by subscribing to a CHANGE of the
> > container of the resource in question.
> 
> Would you not say that the deletion of an object is a change of the
> object?

This is one of those "axiom of choice" things.  You can see the world
that way, or you can use the container view.  Personally, we've gone
with the container view (for the most part).  We don't have enough
experience with it yet to know if that's the right thing or not, but
I have confidence in it.  So no, we don't count the deletion of a
resource as a change of state of that resource.  But when the client
goes to catch up on state, it will find out.  Until then, it will just
notice that the state hasn't updated in a while (like a stale cache).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:496
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-31 22:28:12
Subject:Re: [rest-discuss] idempotent notifications
Message:

On Thu, 31 Jan 2002, S. Mike Dierken wrote:
> of change. I'm thinking of pub/sub with many many listeners - you'd get an
> 'implosion' of 'was that change a delete or not?' If listeners almost never
> care or try to find out, then it's not as big a deal.

Good point!
It also means there is a tradeoff between message
size and callbacks.

In particular, it would be nice if the notifier
can asssign different clients different URLs at
which to review the current state of the resource.

But, it is really an optimization.  The spec.
should allow but not require the notification
agent to send "preemptive redirects"

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:497
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-31 22:44:32
Subject:Re: [rest-discuss] idempotent notifications
Message:

On Thu, 31 Jan 2002, Paul Prescod wrote:
> > The client has to do some form of state management
> > anyway.  If the client needs the URI, it can
> > encode that in the notification URL.
>
> I'm trying to preserve the ability for the notification URL to be
> mailto:paul@... .

!!??? NOT USE HTTP!?

If you're doing that then you should use the
existing standards for listservs.  I don't know
the standard, but I do know that Pine says that
mail from Yahoo contains "List Management
Information" and that if I click on it, I get the
opportunity to click on an UNSUB URL.

> > The problem for the server is that multiple URIs
> > may map to the same resource.  Those different
> > URIs may be used by different clients for various
> > purposes.  If the server has to send a URI, it
> > also has to know which URI the client used to
> > request notification about the Resource.
> > That is really ugly.
>
> Does it? Or does it just need to send *a* URI? As long as the client can
> retrieve the changed state from the URI, maybe it doesn't care if it is
> "the same" URI. I have to think that through more when I have time.

It matters because the resource may have different
access protections when accessed from different
URIs or suppose that the client subscribed to an
HTTP URI, but the notifier supplies an HTTPS URI
and the client can't do HTTPS.

> > The subscription URL should be delivered in the
> > response to notification.  It is a huge waste to
> > deliver it with each notification.
>
> Same reasoning as above. Let's say you notice you're getting random,
> annoying notifications from some service. Maybe all else has failed and
> it is up to a human being to cancel the notifications. The header is
> equivalent to this:
>
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com

See above re the listserv standard.  But, I think
for this standard, if you are using an asynch
protocol, the client should just be required to
refresh subscription periodically.

> > Again, if the client really want it, the client
> > could encode it in the notification URL.
>
> That' going to be one really ugly URL!

Its up to the client!  The client could just
maintain a private map from notification URLs
to a resource and subscription URLs.  It would be
prettier but would require more client side state.

> Anyhow, my three concerns are as
> above:
>
>  1. The software may not ask for it but after it gets accidentally
> uninstalled, whoever needs to turn off the notifications needs it.

Then, it should be optional.  In high frequency
notifications, you don't need it in every message.

>  2. The subscriber may be just be an email address in which case it
> isn't possible to arbitrarily munge the subscriber URI.

* The subscriber can generate 1 email address
per notification URL

* The convention for email notification should
be different.  In particular, the URI that changed
should appear in the subject: header

* Email should include a reply-to/from address...


> > The client should be able to do subscription
> > modifications in reply to a notification request.
> >
> > In particular, some set of 40x responses to a
> > notification should be the equivalent of
> > unsubscription. e.g. if the response to a
> > notification is 403 FORBIDDEN, that is a strong
> > hint that you don't want the subscription anymore.
>
> Actually, right now it works the opposite way. If the subscriber doesn't
> respond: "Yes, please keep sending me crap" then the sender must quit.
> Maybe that obviates point "1" above.


That won't work well for email unless you require
the recipient to reply to each email.

> > ... Because a series of empty PUT bodies
> > doesn't mean that nothing has changed, only that
> > the server decided not to send it.
>
> I think any particular application would either ALWAYS send a diff (or a
> message indicating why it didn't send a diff) or NEVER send a diff. The
> body is optional at the notification spec level. Some apps may bother
> with diffs and some may not.

But you need to require that at the protocol level
which is just wierd.

> Because it is necessary to handle this circumstance where clients go
> offine and come back on, it is necessary that messages be essentially
> irrelevant except for their timing. That's why I don't want to
> standardize any indication of HOW something changed. A particular
> application can do this *as an optimization* for clients who happen to
> have always-on connections.

Ok.
1. You can require that HTTP messages always
represent change since the last successful
delivery.  (the server then need to track when the
last successful delivery was)

2. use an email like protocol and have every
message contain the date at which the message was
sent.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:498
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-01-31 22:51:27
Subject:Re: [rest-discuss] Why is HTTP special?
Message:

Paul, good stuff.  Some comments;

> The various RPC protocols are also very
> general purpose.

This is like saying that Ethernet is general purpose.  It's true, but
not too useful.  RPC is a lower layer than HTTP because it defines no
application semantics, leaving them for the "API" to define.

Linda, like HTTP and FTP and NNTP, defines the methods.  So you've
got an application layer contract - a coordination language -
between endpoints a priori.

> Linda bills itself a "coordination language" -- used
> for coordinating multiple software processes. Until I have a precise
> definition of that term I can't say for sure whether RPC protocols and
> HTTP are also coordination languages but the term seems to apply to
> them.

"RPC" in general isn't.  But any coordination language can be built
on top with RPC methods.  HTTP is a coordination language.

> Definitions aside, the point remains: in terms of generality, HTTP has
> more in common with SOAP than with SMTP. It is not just about moving
> HTML pages from servers to clients. 

I'd say it's the other way around.  SMTP "DATA" has a precise
meaning, not unlike POST.  SOAP defines no meanings; you can either
build them on top (RPC), or you can inherit them from the underlying
protocol.

> HTTP is similar. HTTP allows you to read from the storage with GET,
> write to it with PUT and the addresses are URIs. Because disk space in
> the real world is limited, HTTP also has DELETE. And because multiple
> people will be using the system at once, there is a need for a method
> that will create guaranteed-new "storage locations".

I'd say that POST was the movement of the tape.  PUT creates new
locations.

> FTP is the closest protocol to HTTP conceptually. But really the gap

I think NNTP is probably closest.  It has POST (that's where HTTP's
POST came from), a basic get (ARTICLE), and a very specific type of
put (for setting read messages).

> important, though, FTP's semantics do not allow the server to be an
> active participant in the computation. HTTP very precisely defines how
> the server can do complicated computations by itself. It is not just a
> holder of bits -- it can embody a complex service!

You mean the app here I guess.  You should distinguish between the
web server and the web app.

> efficiency and modeling simplicity. For instance WebDAV has a LOCK
> method which could be modeled as a POST of a LOCk object. In theory the

PUT actually, since it is defined absolutely.

> You can see how this modeling process works. You think about the things
> you want to work with as resources and you apply HTTP methods to them.
> One day I hope and expect that Web resource modeling will be as widely
> understood as object oriented modeling. 

Indeed, they are already closely related.  Component based modelling is
even closer because you work from a generic containment based API.

> I say "quasi-universal" because there are limits. Just as XML isn't
> really great for binary media, HTTP isn't really great for streaming
> real-time media. So for those applications you should use something
> else.

(though perhaps with HTTP's application semantics)

> There is no doubt that HTTP has its limitations. For one thing there is
> not much software out there that knows how to deal with HTTP in a
> peer-to-peer or asychronous fashion.

I don't know what that means.

> There is a lot of software out
> there that claims to use HTTP but is well behind the HTTP specification.
> Also, HTTP is not going to take over the universe from established
> protocols with large software bases

... anytime soon.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:499
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-31 22:57:14
Subject:Re: [rest-discuss] idempotent notifications
Message:

On Thu, 31 Jan 2002, Mark Baker wrote:
> > Would you not say that the deletion of an object is a change of the
> > object?
>
> This is one of those "axiom of choice" things.  You can see the world
> that way, or you can use the container view.

But, suppose I just want to watch the seat to my
right.  I don't want to watch the whole theater
for people sitting and filter it to find the seat
to my right.  I just want to watch the seat to my
right.  How do I do that in the container view?

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:500
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-01-31 23:06:26
Subject:Re: [rest-discuss] Why is HTTP special?
Message:

Paul,

You refer to IMAP at the beginning of the article
but don't explain why it is better than HTTP.

IMAP has lots of features that HTTP lacks.  It has
methods that correspond to GET, POST, PUT.  It has
a better representation of the notion of
containers.  It has search.

ODBC/SQL is also nice from the perspective you
give.  The problem is that it does not specify a
way of passing the types of objects!!!!!

Regarding universality.  I would say that much of
the universality of a communication protocol is a
shared ontology aka a shared list of MIME
content-types.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax




On Thu, 31 Jan 2002, Mark Baker wrote:

> Paul, good stuff.  Some comments;
>
> > The various RPC protocols are also very
> > general purpose.
>
> This is like saying that Ethernet is general purpose.  It's true, but
> not too useful.  RPC is a lower layer than HTTP because it defines no
> application semantics, leaving them for the "API" to define.
>
> Linda, like HTTP and FTP and NNTP, defines the methods.  So you've
> got an application layer contract - a coordination language -
> between endpoints a priori.
>
> > Linda bills itself a "coordination language" -- used
> > for coordinating multiple software processes. Until I have a precise
> > definition of that term I can't say for sure whether RPC protocols and
> > HTTP are also coordination languages but the term seems to apply to
> > them.
>
> "RPC" in general isn't.  But any coordination language can be built
> on top with RPC methods.  HTTP is a coordination language.
>
> > Definitions aside, the point remains: in terms of generality, HTTP has
> > more in common with SOAP than with SMTP. It is not just about moving
> > HTML pages from servers to clients.
>
> I'd say it's the other way around.  SMTP "DATA" has a precise
> meaning, not unlike POST.  SOAP defines no meanings; you can either
> build them on top (RPC), or you can inherit them from the underlying
> protocol.
>
> > HTTP is similar. HTTP allows you to read from the storage with GET,
> > write to it with PUT and the addresses are URIs. Because disk space in
> > the real world is limited, HTTP also has DELETE. And because multiple
> > people will be using the system at once, there is a need for a method
> > that will create guaranteed-new "storage locations".
>
> I'd say that POST was the movement of the tape.  PUT creates new
> locations.
>
> > FTP is the closest protocol to HTTP conceptually. But really the gap
>
> I think NNTP is probably closest.  It has POST (that's where HTTP's
> POST came from), a basic get (ARTICLE), and a very specific type of
> put (for setting read messages).
>
> > important, though, FTP's semantics do not allow the server to be an
> > active participant in the computation. HTTP very precisely defines how
> > the server can do complicated computations by itself. It is not just a
> > holder of bits -- it can embody a complex service!
>
> You mean the app here I guess.  You should distinguish between the
> web server and the web app.
>
> > efficiency and modeling simplicity. For instance WebDAV has a LOCK
> > method which could be modeled as a POST of a LOCk object. In theory the
>
> PUT actually, since it is defined absolutely.
>
> > You can see how this modeling process works. You think about the things
> > you want to work with as resources and you apply HTTP methods to them.
> > One day I hope and expect that Web resource modeling will be as widely
> > understood as object oriented modeling.
>
> Indeed, they are already closely related.  Component based modelling is
> even closer because you work from a generic containment based API.
>
> > I say "quasi-universal" because there are limits. Just as XML isn't
> > really great for binary media, HTTP isn't really great for streaming
> > real-time media. So for those applications you should use something
> > else.
>
> (though perhaps with HTTP's application semantics)
>
> > There is no doubt that HTTP has its limitations. For one thing there is
> > not much software out there that knows how to deal with HTTP in a
> > peer-to-peer or asychronous fashion.
>
> I don't know what that means.
>
> > There is a lot of software out
> > there that claims to use HTTP but is well behind the HTTP specification.
> > Also, HTTP is not going to take over the universe from established
> > protocols with large software bases
>
> ... anytime soon.
>
> MB
> --
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@...
> http://www.markbaker.ca   http://www.planetfred.com
>







-----------------------------------------------------------------------------------
Post ID:501
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-01-31 23:42:07
Subject:Re: [rest-discuss] Why is HTTP special?
Message:

"S. Alexander Jacobson" wrote:
> 
> Paul,
> 
> You refer to IMAP at the beginning of the article
> but don't explain why it is better than HTTP.
> 
> IMAP has lots of features that HTTP lacks.  It has
> methods that correspond to GET, POST, PUT.  It has
> a better representation of the notion of
> containers.  It has search.

Okay, but how much work would it be to define a protocol with all of
IMAPs features that conforms to the HTTP syntax and model versus vice
versa? Adding "search" to HTTP would be trivial. Would adding URI
handling and content-negotiation to IMAP be similarly trivial?

> ODBC/SQL is also nice from the perspective you
> give.  The problem is that it does not specify a
> way of passing the types of objects!!!!!

Also not very well geared for large scale, loosely coupled computing.

> Regarding universality.  I would say that much of
> the universality of a communication protocol is a
> shared ontology aka a shared list of MIME
> content-types.

I agree that this is necessary for an application. But I wouldn't say
that it is a benefit of the protocol itself.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:502
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 00:16:53
Subject:Re: [rest-discuss] idempotent notifications
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>


> "S. Mike Dierken" wrote:
> >
> > ...
> >
> > So... I concur with Alex about notification messages identifying the
type of
> > change made - but I would like all six noted here.
> > Paul wants only 'changed', but I see little extra cost to identifying
the
> > type of change and I do see cost using further messages to identify the
type
> > of change. I'm thinking of pub/sub with many many listeners - you'd get
an
> > 'implosion' of 'was that change a delete or not?'
>
> Fine. So you admit that it is an optimization. All I want to do is leave
> the precise details of the optimization to the application. If it wants
> to send Unix-format diffs, then it can. If it wants to have six event
> types, then it can. If it wants twenty event types, then it can. All I
> ask is that the information about what happened also exist in some form
> on the web server so that people who miss a message can get caught up.
>
I don't mean the details in the body, I mean (from Alex's example) the
method used for the notification.
Even with no details about the current or changed values of the the
resource, I would like to know what type of operation occurred.

"Having information about what happened on the web server" - the web server
would have the results of applying what happned, but it wouldn't have a
record of what happened. It wouldn't (in general) have an audit trail - like
'paul edited this file at 12:00am with vi'. It would have 'the file says
"hello world"'.

Also, I don't want 'twenty event types', I only want HTTP referenceable
'event types' - a mapping of what occurred into http state transition
operations. Having 'twenty event types' is analagous to having twenty http
methods. Yes, I know the resource could have been changed through some other
means than http - but the subscription and notifications are expressed in
terms of http, so the notification should be /fully/ expresed in terms of
http.


> > ... If listeners almost never
> > care or try to find out, then it's not as big a deal.
> > Another thing, while I'm up here in the ivory tower, since I would like
a
> > notification for 'read', that wouldn't make sense via a 'change'
> > notification. (The reason I want a 'read' is that when coupled with a
> > response status of 'security error' you can detect security issues and
> > stuff. And I know that non-http based modifications don't have these
> > concepts, but they can be mapped.)
>
> You could do a regular CHANGE watch on the file that logs READs. Then if
> you miss a notification you can always get caught up by reading the
> READ-logfile. If the only place that information is stored is in the
> notification then one lost notification and you won't know that some
> hacker broke into your system.
If you don't have 'reliable' delivery.
Watching a file that contains READ occurrances is fine - but I would like to
declare that in the subscription in a standardized way (WATCH /foo/logins
method=READ) rather than a URI up to application definition (WATCH
/foo/logins/all_reads).








-----------------------------------------------------------------------------------
Post ID:503
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 00:54:58
Subject:Re: [rest-discuss] idempotent notifications
Message:

"S. Mike Dierken" wrote:
> 
>...
> I don't mean the details in the body, I mean (from Alex's example) the
> method used for the notification.

I think that there are strong backwards-compatibility forces that argue
in favour of using standard HTTP methods. But actually I'm willing to
allow the application to use whatever methods (standard or extension) it
wants.

> Even with no details about the current or changed values of the the
> resource, I would like to know what type of operation occurred.

You *might* like to know. But is it worth complicating the
specification?

> "Having information about what happened on the web server" - the web server
> would have the results of applying what happned, but it wouldn't have a
> record of what happened. It wouldn't (in general) have an audit trail - like
> 'paul edited this file at 12:00am with vi'. It would have 'the file says
> "hello world"'.

If the audit trail is important then the server should have a resource
representing the audit trail. If the audit trail is NOT important then
why do notification clients care about it? I'm a hardliner on this
principle that there should be nothing in the notification that is not
just a summary of information available on the site.

> Also, I don't want 'twenty event types', I only want HTTP referenceable
> 'event types' - a mapping of what occurred into http state transition
> operations. Having 'twenty event types' is analagous to having twenty http
> methods. 

I am not convinced that the basic HTTP methods are automatically the set
of event types all applications would like. 

>...
> If you don't have 'reliable' delivery.

I think that part of the genius of HTTP is loose binding. And part of
that is presuming that you don't have anything more reliable than TCP.

> Watching a file that contains READ occurrances is fine - but I would like to
> declare that in the subscription in a standardized way (WATCH /foo/logins
> method=READ) rather than a URI up to application definition (WATCH
> /foo/logins/all_reads).

And some other user is going to want to watch READ occurrences FROM a
particular range of IP addresses. We either need to define a really
hairy, Turing-complete filter language or we need to leave it up to the
application. I claim that the "HTTP solution" is to leave it up to the
application to do with resource modeling. Now why is your seemingly
reasonable request any different in kind, not just degree, from the guy
who wants to filter by IP address or time of day or content-type or ...

That content-type example is particularly interesting because it is
purely in the domain of HTTP so it falls into the same category as the
method. Should people be able to filter on content-type as well as
method? What about filtering on Host:. etc. etc.

Just do it with the URI and be done with it! Reformulating queries and
filters as URIs is one of the most brilliant things about the Web and I
want to emulate it.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:504
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 02:24:45
Subject:Summarization on notifications?
Message:

I've unfortunately had to tune out the last couple of days due to "real" work,
looks like there's been a significant amount of consensus building.  Would someone
(Paul, Alex, Mike, anyone?) mind summarizing the current state-of-consensus?

This would probably be useful anyway to ensure everyone's on the same page, always
a challenge. ;-)

jb








-----------------------------------------------------------------------------------
Post ID:505
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 03:05:22
Subject:Re: Summarization on notifications?
Message:

Mostly we talk about the things that we don't have consensus on.

I've done some major cleanups on the spec at 

 * http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents

Alex has almost talked me into removing the "Watched-URI" and
"Subscription-URI" headers.

Lucas more or less talked me into removing the Events header.

Mike still likes something like the Events header but I'm convinced it
is just extra junk.

Mark convinced me that the notification should be done using whatever
METHOD the application wants. POST most of the time, PUT occasionally,
maybe NOTIFY if they want to be very explicit...

I added a variants of your ideas on Expiration and Subscription
cancellation.

It occurs to me now that there is nothing to prevent man-in-the-middle
attacks ("Here's your stock price Mr. Gates!") but I don't think that's
our responsibility. They can use signing and SSL.

I've borrowed Lucas' philosophy on the idempotency of notifications.
(see the spec)

Somebody needs to think through the SMTP and the Query param bindings.

I've clarified my thoughts on how to handle notifications for
collections. Collections are just documents that happen to contain URIs
to other documents. Just hang a WATCH on that document.

I've also clarified my thoughts on message bodies. A notification's only
responsibility is to report that something changed. It is totally about
temporality. It's the secret spy-code where the phone rings twice with
no message. 

The message body is ONLY a HINT about what changed. It isn't the
"payload" in any sense. If it is important (e.g. a msg in a chat
session) then it should be a first class resource on the SERVER so that
disconnected clients can "get caught up" even if they missed one or all
of the messages. I hate using services where you have to ask people
"what did I miss while my connection was down." I think that's totally
against REST. On the other hand, there are important optimizations you
can do if you allow message bodies so it is allowed only as an
optimization.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:506
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-01 03:06:09
Subject:Expiration
Message:

I have gone through the language regarding watch expiration and have
the following comments.

* Dates may not be the only, or even the most, important semantic for
expirations.  The most obvious exception is a request for one single
notification.  A usecase for one-shot notifications is a user
requesting a resource that is not yet available.  Another possible
exception is a pay-per-use magazine subscription, where a user buys
twelve monthly updates.  I suggest that "Requested-Expiration" be
renamed "Requested-Expiration-Date" and second expiration header named
"Requested-Expiration-Count" be added.  Finally, there is a third
possible semantic that is probably the default case: "do this watch
for as long as you feel like".

* The prefix "Requested-" is redundant.  Better wording would be
"Expiration-Date" and "Expiration-Count".

* If a publisher rejects a watch request because of an unsupported expiration
setting (such as a date too far in the future or a count beyond what has been
paid for), the requester should be able to diagnose the problem.  There should
be a return status code for "Invalid value for requested expiration".  Because
new global HTTP status codes are undesirable, possible candidates from existing
status codes are:
"417"  ; Section 10.4.18: Expectation Failed
"412"  ; Section 10.4.13: Precondition Failed
"409"  ; Section 10.4.10: Conflict

None of these is ideal.  However, 417 brings up the possibility of
_not_ using a new header dedicated to expiration, because an expect
header already exists to support the need:
Expect: Expiration;date=Jan 1, 2003
Expect: Expiration;count=12
Expect: Expiration;adhoc

Unfortunately the 417 status code indicates that the expiration
header is not supported rather than that the expiration value was
unacceptable.  Are there solutions within RFC 2616?

The 412 status code is a fairly good match, though I don't quite
understand it.  Here is the definition:

10.4.13 412 Precondition Failed
   The precondition given in one or more of the request-header fields
   evaluated to false when it was tested on the server. This response
   code allows the client to place preconditions on the current resource
   metainformation (header field data) and thus prevent the requested
   method from being applied to a resource other than the one intended.

Placing preconditions sounds like just the right thing, but the
problem in this case would have nothing to do with getting the wrong
resource.

The 409 status code is IMO the best match:

10.4.10 409 Conflict
    The request could not be completed due to a conflict with the current
   state of the resource. This code is only allowed in situations where
   it is expected that the user might be able to resolve the conflict
   and resubmit the request. The response body SHOULD include enough
    information for the user to recognize the source of the conflict.
   Ideally, the response entity would include enough information for the
   user or user agent to fix the problem; however, that might not be
   possible and is not required.    Conflicts are most likely to occur
   in response to a PUT request. For
   example, if versioning were being used and the entity being PUT
   included changes to a resource which conflict with those made by an
   earlier (third-party) request, the server might use the 409 response
   to indicate that it can't complete the request. In this case, the
   response entity would likely contain a list of the differences
   between the two versions in a format defined by the response
   Content-Type.

This is a fairly good match, so I would adopt it.

* The "subscription-expiration" header is required.  Since it
is reasonable that many requests will be on a "good enough" basis
("do the watch for as long as is feasible"), I suggest that this be
the default value.  If there is a default value then there is no need
to have an expiration request header be a MUST.

* I believe that this language overspecifies: "The client MAY renew
the subscription before this time. If it does not, the server MAY stop
sending notifications after that time. The server MAY also remove the
Subscription URI."  This behavior should be left to the implementation.

* There is no need to assume that the above list of types of expiration is
exhaustive.  The specification should allow for extension.

Putting all the above together, I propose that the following text:
"Expiration: The response to the Subscription MUST include a header
called "Subscription-Expiration". This indicates the time that the
subscription expires. The client MAY renew the subscription before
this time. If it does not, the server MAY stop sending notifications
after that time. The server MAY also remove the Subscription URI."

Be changed to the following:

Expiration: The response to the Subscription MAY include a header
called "Subscription-Expiration".  The expiration may take any of the
following forms:
Expect: Expiration;date=Jan 1, 2003
Expect: Expiration;count=12
Expect: Expiration;adhoc
Expect: Expiration;extension-field

extension-field  = token [ "=" ( token | quoted-string ) ]

In the case of Expiration;date, the field value is an HTTP-date, as
described in section 3.3.1; it MUST be sent in RFC 1123 [8]-date format.

In the case of Expiration;count, the field value is an unsigned
integer.

In the case of Expiration;adhoc, the server may cease performing the
watch at any time.  If the request does not specify an expiration, a
server MUST use an expiration setting equivalent to Expiration;adhoc.
It is expected that servers will continue performing an
Expiration;adhoc watch for as long as is practically feasible.

All responses to the watch request that are rejected for reasons of
unacceptable expiration field values MUST use status code 409 (Conflict).

- Lucas







-----------------------------------------------------------------------------------
Post ID:507
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 04:49:58
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:


Paul Prescod wrote:

> I've done some major cleanups on the spec at
>
>  * http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents

Even better.  Taking a look now.

> Alex has almost talked me into removing the "Watched-URI" and
> "Subscription-URI" headers.

So what takes their place?  Do we reify subscriptions or not?  (Looking at
the spec now, answer's probably in there.)

> It occurs to me now that there is nothing to prevent man-in-the-middle
> attacks ("Here's your stock price Mr. Gates!") but I don't think that's
> our responsibility. They can use signing and SSL.

I think end-to-end security has to be the application's responsibility.

jb








-----------------------------------------------------------------------------------
Post ID:508
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 05:04:38
Subject:Re: [rest-discuss] Expiration
Message:

Thanks for your comments and ideas. Overall I think they are good.

Lucas Gonze wrote:
> 
> I have gone through the language regarding watch expiration and have
> the following comments.
> 
> * Dates may not be the only, or even the most, important semantic for
> expirations.  The most obvious exception is a request for one single
> notification.  A usecase for one-shot notifications is a user
> requesting a resource that is not yet available.  Another possible
> exception is a pay-per-use magazine subscription, where a user buys
> twelve monthly updates.  I suggest that "Requested-Expiration" be
> renamed "Requested-Expiration-Date" and second expiration header named
> "Requested-Expiration-Count" be added.  Finally, there is a third
> possible semantic that is probably the default case: "do this watch
> for as long as you feel like".

Okay, of course expiration counts should go both ways. The client should
request one and the server should say what it decided upon.

> * The prefix "Requested-" is redundant.  Better wording would be
> "Expiration-Date" and "Expiration-Count".

But it is really just a request (or expectation). Your idea of using
Expect: is good.

> * If a publisher rejects a watch request because of an unsupported expiration
> setting (such as a date too far in the future or a count beyond what has been
> paid for), the requester should be able to diagnose the problem.  

My sense was that it wouldn't be an exception, the server would just
substitute what it really had. Like if you ask to read() 1000 bytes but
there are only 500 left, I get 500 back.

I'm worried about negotiation round trips. "Gimme this. No! Okay this.
No! Okay this. No!" Why not just have the server tell the client what it
can have. The client can cancel it if it isn't happy.

Plus, HTTP (surprisingly!) doesn't really standardize how to report
which expectation wasn't met. So how would you figure it out.

Is there anything seriously wrong with failing silently? The client can
check what it got against what it requested and puke if it wants or else
just take what it got.

Maybe there should be a Prefer: header that has the same syntax as
Expect:.

>...
> The 409 status code is IMO the best match:

I think that we need to figure out the issue above before we choose a
response code. 

I didn't really understand why you disliked 417, though:

> Unfortunately the 417 status code indicates that the expiration
> header is not supported rather than that the expiration value was
> unacceptable.

I think you misunderstood 14.20: " The server MUST respond with a 417
(Expectation Failed) status if any of the expectations cannot be met
..."

That seems perfect.

>...
> * The "subscription-expiration" header is required.  Since it
> is reasonable that many requests will be on a "good enough" basis
> ("do the watch for as long as is feasible"), I suggest that this be
> the default value.  If there is a default value then there is no need
> to have an expiration request header be a MUST.

It isn't a MUST. It's a MAY in the spec as it is:

"The message MAY contain a header called "Requested-Expiration"."

> * I believe that this language overspecifies: "The client MAY renew
> the subscription before this time. If it does not, the server MAY stop
> sending notifications after that time. The server MAY also remove the
> Subscription URI."  This behavior should be left to the implementation.

Debatable...what's the point of standardizing the headers if we don't
standardize the associated behaviour?

>...
> Expiration: The response to the Subscription MAY include a header
> called "Subscription-Expiration".  

Just one? I might want a year or twelve issues. Whichever comes first.

>...
> In the case of Expiration;adhoc, the server may cease performing the
> watch at any time.  

I would say that the Server needs to report its policy in the response.
i.e. One Month, 12 requests, etc. Otherwise, how will the client know
when it is time to renew?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:509
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 05:21:46
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

Jeff Bone wrote:
> 
> ...
> 
> > Alex has almost talked me into removing the "Watched-URI" and
> > "Subscription-URI" headers.
> 
> So what takes their place?  Do we reify subscriptions or not?  (Looking at
> the spec now, answer's probably in there.)

I think we always intended to reify subscriptions. The question is
whether we redundantly inform the client in notifications:

 a) what URI it is being notified about
 b) what subscription caused the notification

He has some good arguments why we don't have to do that. The client can
have a mapping from subscriber URIs to watches and subscriptions. It
could also munge them into the subscriber URI itself. So the extra bytes
are kind of a waste. Plus they are redundant and could be confusing if
the client subscribed under one URI and gets a notification about an
alternate URI for the same resource.

But at a deep level I hate the idea of inscrutable bytes arriving from
some remote source without telling me WHY they are arriving or HOW I
would stop them. That's why I wanted headers that would make the message
self describing. You would just click (literally or metaphorically) on
the "unsubscribe URI" and the messages would stop arriving....

Still undecided what's most important. Maybe it is an issue for
negotiation: a Verbose: header which defaults to True. Yeah, I kind of
like that idea.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:510
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-01 05:50:43
Subject:RE: [rest-discuss] Expiration
Message:

Much of your response I need to digest for a few days.  The following are only
those responses that seem solid:

> Okay, of course expiration counts should go both ways. The client should
> request one and the server should say what it decided upon.

Short of having a bid/counterbid/countercounterbid process, which is too hard to
implement, my suggestion was that we just have
bid/reject/bid-1/reject/bid-N/accept.

> Plus, HTTP (surprisingly!) doesn't really standardize how to report
> which expectation wasn't met. So how would you figure it out.

yup!  way!  Extension status-codes are legal...  What is the cost of a new
status code?  It seems completely reasonable to assume that a client which has
initiated a WATCH transaction would know how to understand related status codes.
A 4xx code is the expected extension code, given that the 417 expectation
implies that.

> I think you misunderstood 14.20: " The server MUST respond with a 417
> (Expectation Failed) status if any of the expectations cannot be met
> .."

Very possible.  I find rfc 2616 not unlike ancient runes/nostradamus.


> > * The "subscription-expiration" header is required.  Since it
> > is reasonable that many requests will be on a "good enough" basis
> > ("do the watch for as long as is feasible"), I suggest that this be
> > the default value.  If there is a default value then there is no need
> > to have an expiration request header be a MUST.
>
> It isn't a MUST. It's a MAY in the spec as it is:
>
> "The message MAY contain a header called "Requested-Expiration"."

Sorry, no.  I have reloaded the page several times and it still says MUST.


> > * I believe that this language overspecifies: "The client MAY renew
> > the subscription before this time. If it does not, the server MAY stop
> > sending notifications after that time. The server MAY also remove the
> > Subscription URI."  This behavior should be left to the implementation.
>
> Debatable...what's the point of standardizing the headers if we don't
> standardize the associated behaviour?

There is no point in either.  :)

Standards are not a goal in themselves, and I am not convinced that
canonicalization is constructive at this early stage.  My feeling is that
http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents is part of an ongoing
series of thought experiments  regarding asynchronous design patterns in HTTP.

Specification is always destructive in that it reduces the available range of
expression.  Overspecifying is not a service.


> > Expiration: The response to the Subscription MAY include a header
> > called "Subscription-Expiration".
>
> Just one? I might want a year or twelve issues. Whichever comes first.

hmm....   a relative date?  a compound expression?  need to mull this over.  I
would prefer to avoid this kind of negotiation, which leads inevitably to yet
another programming language.


> > In the case of Expiration;adhoc, the server may cease performing the
> > watch at any time.
>
> I would say that the Server needs to report its policy in the response.
> i.e. One Month, 12 requests, etc. Otherwise, how will the client know
> when it is time to renew?

For the most part it's not important.  Servers currently return 404 whenever it
pleases them.  For the same reasons watches should be assumed to go until they
stop.

- Lucas








-----------------------------------------------------------------------------------
Post ID:511
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 06:01:45
Subject:Comments on latest rev of the HttpEvents spec
Message:

Great stuff, Paul!  :-)

(1) I think we should go all the way with the "subscription"
terminology.  Instead of "watchable resource" and "Watched-URI,"
"subscribable resource" and "Subscribed-URI".  Instead of just
"Location," "Subscription-Location."  Etc.

(2) Kill "Event."  The semantics of change are
application-dependent.  For most things, the notification of a
state change is sufficient; HTTP already provides a mechanism for
then retreiving the new state representation.  (The one caveat
being a change to a resource with lots of subscriptions could
generate a GET storm, but the application designer should
anticipate this.)  For anything other than simple change
notificatins, applications should define their own
change-representation notification schemes.

(3) The language about message ordering is IMO dangerous.
Requiring a publisher to deliver messages in order implies
something about the server-side state that is perhaps best left
to individual applications.  Instead, if (from the server / HTTP
perspective) notifications do not carry state but are simply
notifications of state change, then message ordering becomes
unimportant.

(4) It might be useful to require an appropriate validator
(entity tag or last-modified header) in every notification.  In a
sense, clients are simply caches for particular representations,
and the HttpEvents "protocol" is just a push-based cache
invalidation protocol.  We should reuse the appropriate pieces of
HTTP in this capacity.

(5) I'm still uncomfortable talking about the mail binding at
this time.  That's not to say it's not important to have one,
just that IMO it's best left to a separate specification.









-----------------------------------------------------------------------------------
Post ID:512
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 06:07:05
Subject:Re: [rest-discuss] Why is HTTP special?
Message:

On Thu, 31 Jan 2002, Paul Prescod wrote:
> Okay, but how much work would it be to define a protocol with all of
> IMAPs features that conforms to the HTTP syntax and model versus vice
> versa? Adding "search" to HTTP would be trivial. Would adding URI
> handling and content-negotiation to IMAP be similarly trivial?

Re URI handling, do you mean RFC2192?
Re content negotiation, do you mean:
Content-type: multipart/alternative

> > ODBC/SQL is also nice from the perspective you
> > give.  The problem is that it does not specify a
> > way of passing the types of objects!!!!!
>
> Also not very well geared for large scale, loosely coupled computing.

Why?

> > Regarding universality.  I would say that much of
> > the universality of a communication protocol is a
> > shared ontology aka a shared list of MIME
> > content-types.
>
> I agree that this is necessary for an application. But I wouldn't say
> that it is a benefit of the protocol itself.

I think it is the main benefit of the protocol and
the big problem with most RPC protocols.  They
don't provide a standard way of representing
all types.


-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:513
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 06:59:17
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Thu, 31 Jan 2002, Paul Prescod wrote:
> But at a deep level I hate the idea of inscrutable bytes arriving from
> some remote source without telling me WHY they are arriving or HOW I
> would stop them.

I get that all the time on the various sites I
have run.  Various software and other websites
incorrectly requesting stuff that used to exist or
stuff that NEVER existed on my web server.

I think it is part of life when you expose a
public web server.

Since the client can request a secret URL, the
notifier would be getting a 404 and would then
stop sending.  If it keeps sending it is just
behaving badly.

> That's why I wanted headers that would make the message
> self describing. You would just click (literally or metaphorically) on
> the "unsubscribe URI" and the messages would stop arriving....

As you noted before.  Unless the notification URL
says to continue, notification stops.  So this
isn't an issue.

> Still undecided what's most important. Maybe it is an issue for
> negotiation: a Verbose: header which defaults to True. Yeah, I kind of
> like that idea.

You are making the spec too complex.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:514
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 07:10:03
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

"S. Alexander Jacobson" wrote:
> 
> On Thu, 31 Jan 2002, Paul Prescod wrote:
> > But at a deep level I hate the idea of inscrutable bytes arriving from
> > some remote source without telling me WHY they are arriving or HOW I
> > would stop them.
> 
> I get that all the time on the various sites I
> have run.  Various software and other websites
> incorrectly requesting stuff that used to exist or
> stuff that NEVER existed on my web server.

I found a case that is greatly simplified if notifications contain URIs.
If you set up a new intermediary such as the one I'm starting to
describe at NotificationQueuing, then you need to communicate all of
the  URI->(watched-URI, subscription-URI) mappings to the intermediary.
It is much better if the notifications are just self-describing so that
lest advance coordination is necessary.

NotificationQueuing =
http://internet.conveyor.com/RESTwiki/moin.cgi/NotificationQueuing

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:515
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 07:38:03
Subject:Re: [rest-discuss] Comments on latest rev of the HttpEvents spec
Message:

Jeff Bone wrote:
> 
> Great stuff, Paul!  :-)
> 
> (1) I think we should go all the way with the "subscription"
> terminology.  Instead of "watchable resource" and "Watched-URI,"
> "subscribable resource" and "Subscribed-URI".  Instead of just
> "Location," "Subscription-Location."  Etc.

Not bad...I wonder if we'll regret using pub/sub terminology if people
think it is too unlike pub/sub. When you subscribe to Playboy you don't
get a once a month notification that there is a new edition available.
You get a *magazine*. So our model is somewhat different. As you said,
it is almost cache invalidation.

If you don't think it is a problem want to go through and unify
terminology while you are studying it, that's okay with me.

> (2) Kill "Event."  The semantics of change are
> application-dependent.  For most things, the notification of a
> state change is sufficient; HTTP already provides a mechanism for
> then retreiving the new state representation.  (The one caveat
> being a change to a resource with lots of subscriptions could
> generate a GET storm, but the application designer should
> anticipate this.)  For anything other than simple change
> notificatins, applications should define their own
> change-representation notification schemes.

That's what I've been saying. The application designer can use the body
for hints that avoid GET storms.

> (3) The language about message ordering is IMO dangerous.
> Requiring a publisher to deliver messages in order implies
> something about the server-side state that is perhaps best left
> to individual applications.  Instead, if (from the server / HTTP
> perspective) notifications do not carry state but are simply
> notifications of state change, then message ordering becomes
> unimportant.

I guess I'll take it out and see if a need for it arises. My main
concern is that while you are retrying one event you don't want to build
up a larger and larger queue of events you are retrying for the same
missing subscriber until you start to interfere with network
performance.

> (4) It might be useful to require an appropriate validator
> (entity tag or last-modified header) in every notification. 

Require is a little strong. Remember that part of the genious of HTTP is
that basic implementations are so simple. MUST's start raising the bar.

Maybe it is a feature that clients may ask for along with minimized
notification bodies and whatever else we come up with.

> ... In a
> sense, clients are simply caches for particular representations,
> and the HttpEvents "protocol" is just a push-based cache
> invalidation protocol.  We should reuse the appropriate pieces of
> HTTP in this capacity.

One reason that I'm not happy with it yet as a cache invalidation
protocol is that it is not good at replicating collections. It's easy to
watch a document that represents a collection. But you can only
replicate the sub-resources if you understand the syntax of the
container. HTTP should have a "give me this resource's children" method
or something...

> (5) I'm still uncomfortable talking about the mail binding at
> this time.  That's not to say it's not important to have one,
> just that IMO it's best left to a separate specification.

Doesn't make much difference to me. What is important is the
architectural decision of whether we allow mailto: URIs to be
subscription targets or always require a proxying intermediary.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:516
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 07:54:03
Subject:Re: [rest-discuss] Expiration
Message:

Lucas Gonze wrote:
> 
> Much of your response I need to digest for a few days.  The following are only
> those responses that seem solid:
> 
> > Okay, of course expiration counts should go both ways. The client should
> > request one and the server should say what it decided upon.
> 
> Short of having a bid/counterbid/countercounterbid process, which is too hard to
> implement, my suggestion was that we just have
> bid/reject/bid-1/reject/bid-N/accept.

I don't see the benefit of bidding and counter-bidding. It isn't
haggling. The subscriber should say what it wants. The publisher is
boss. It should say what it offers. That's it. The question in my mind
is whether the publisher should throw an error when the client asks for
too much or whether it should just say: "The best I could do is X. If
you want to delete the subscription, go ahead."

> > "The message MAY contain a header called "Requested-Expiration"."
> 
> Sorry, no.  I have reloaded the page several times and it still says MUST.

There are two different relevant parts:

> The message MAY contain a header called "Requested-Expiration". 

> The response to the Subscription MUST include a header called "Subscription-Expiration". 

The spec is still working on the "you tell me what I want I'll tell you
what I decided" model.

>...
> Standards are not a goal in themselves, and I am not convinced that
> canonicalization is constructive at this early stage.  

Standards are not the end-goal but clients and servers (subscribers and
publishers) that work together without negotiation is a goal and it
takes standards. Even if only six people ever make software that works
together and we are all on this list, the point is that we can only make
software that works together with standards.

>...
> Specification is always destructive in that it reduces the available range of
> expression.  Overspecifying is not a service.

You're going meta on me. I left a lot of freedom to the implementation:

> > "The client MAY renew
> > the subscription before this time. If it does not, the server MAY stop
> > sending notifications after that time. The server MAY also remove the
> > Subscription URI."  This behavior should be left to the implementation.

All that is standardized is that the server is "within its rights" to
stop delivering notifications to the client and forget about it after
the expiry time. The point is the server shouldn't just decide to stop
delivering notifications whenever it feels like. It made a commitment.

>...
> hmm....   a relative date?  a compound expression?  need to mull this over.  I
> would prefer to avoid this kind of negotiation, which leads inevitably to yet
> another programming language.

I understand, but you wedged the door a little bit by going beyond my
purely temporal expirations. The nice thing about temporal expirations
is that you know how long you have to renew. 

>...
> For the most part it's not important.  Servers currently return 404 whenever it
> pleases them.  For the same reasons watches should be assumed to go until they
> stop.

How will you even know that's happened? I think that the server should
make a commitment.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:517
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 08:27:01
Subject:Re: [rest-discuss] Why is HTTP special?
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> Re URI handling, do you mean RFC2192?

The protocol doesn't know anything about RFC2192, does it?

> Re content negotiation, do you mean:
> Content-type: multipart/alternative

Don't know what you mean. Can IMAP do content-negotiation so that I can
ask for a particular message in different content-types depending on the
client?

Anyhow, what makes IMAP particularly weak compared to HTTP is that it
isn't designed to allow the server to do arbitrary computation in the
generation of responses. It accepts data and moves data but it can't
generate it without warping the protocol.

> > > ODBC/SQL is also nice from the perspective you
> > > give.  The problem is that it does not specify a
> > > way of passing the types of objects!!!!!
> >
> > Also not very well geared for large scale, loosely coupled computing.
> 
> Why?

Exposing your relational database schema to the world is not good
encapsulation!

>...
> I think it is the main benefit of the protocol and
> the big problem with most RPC protocols.  They
> don't provide a standard way of representing
> all types.

We'll have to agree to disagree. The list of MIME types are part of the
Internet. Any protocol can easily adopt the relevant ones.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:518
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 09:15:00
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Thu, 31 Jan 2002, Paul Prescod wrote:
> I found a case that is greatly simplified if notifications contain URIs.
> If you set up a new intermediary such as the one I'm starting to
> describe at NotificationQueuing, then you need to communicate all of
> the  URI->(watched-URI, subscription-URI) mappings to the intermediary.
> It is much better if the notifications are just self-describing so that
> lest advance coordination is necessary.

I don't think NotificationQueuing makes sense.
Why not just have an offline client ask for the
access log of its relay server?

Either way, if the intermediary just stores the
URIs requested the client can do mapping whenever
it likes.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:519
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 09:24:06
Subject:Re: [rest-discuss] Comments on latest rev of the HttpEvents spec
Message:

On Thu, 31 Jan 2002, Paul Prescod wrote:
> That's what I've been saying. The application designer can use the body
> for hints that avoid GET storms.

Ugh.  If you are doing this, then you should allow
notification messages to specify alternative
servers (preemptive redirect).

> I guess I'll take it out and see if a need for it arises. My main
> concern is that while you are retrying one event you don't want to build
> up a larger and larger queue of events you are retrying for the same
> missing subscriber until you start to interfere with network
> performance.

If the client misses notifications, that is OK.
Why not just drop them?

> > (4) It might be useful to require an appropriate validator
> > (entity tag or last-modified header) in every notification.
>
> Require is a little strong. Remember that part of the genious of HTTP is
> that basic implementations are so simple. MUST's start raising the bar.
>
> Maybe it is a feature that clients may ask for along with minimized
> notification bodies and whatever else we come up with.

Paul, this thing should be really easy to
implement.
The pure URI version with message dropping allowed
means that each time a watched resource is changed
it just iterates through a notification list
issuing ___ requests with no content.

I think this gets you almost everything you want.

Adding all sorts of negotiation seems annoying.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:520
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 09:33:01
Subject:Re: [rest-discuss] Comments on latest rev of the HttpEvents spec
Message:

"S. Alexander Jacobson" wrote:
> 
> On Thu, 31 Jan 2002, Paul Prescod wrote:
> > That's what I've been saying. The application designer can use the body
> > for hints that avoid GET storms.
> 
> Ugh.  If you are doing this, then you should allow
> notification messages to specify alternative
> servers (preemptive redirect).

I may do that but it is also easy to do that at the application
layer...anyhow, I call it "watched-URI". You call it
preemptive-redirect. It's a URI where you can get the resource.

> > I guess I'll take it out and see if a need for it arises. My main
> > concern is that while you are retrying one event you don't want to build
> > up a larger and larger queue of events you are retrying for the same
> > missing subscriber until you start to interfere with network
> > performance.
> 
> If the client misses notifications, that is OK.
> Why not just drop them?

What if the notification is for an important email that just arrived?
Late is better than never. Retry is just a MAY. If a publisher doesn't
want to implement it, they don't have to. Depends on the
mission-criticality of the application.

>...
> 
> Paul, this thing should be really easy to
> implement.
> The pure URI version with message dropping allowed
> means that each time a watched resource is changed
> it just iterates through a notification list
> issuing ___ requests with no content.

Versus tagging each URI with "Watched-URI: $uri \nSubscription-URI:
$sub_base?$uri". It's not hard either way.

> I think this gets you almost everything you want.
> 
> Adding all sorts of negotiation seems annoying.

A few flags are not a major deal. We're talking about implementing in
two hours or three!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:521
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 09:38:14
Subject:Re: [rest-discuss] Why is HTTP special?
Message:

On Fri, 1 Feb 2002, Paul Prescod wrote:
> > Re URI handling, do you mean RFC2192?
> The protocol doesn't know anything about RFC2192, does it?

Does it need to?  What are you trying to
accomplish?

> > Re content negotiation, do you mean:
> > Content-type: multipart/alternative
>
> Don't know what you mean. Can IMAP do content-negotiation so that I can
> ask for a particular message in different content-types depending on the
> client?

That is the purpose of multipart/alternative.  See
RFC2046 sec. 5.1.4:

  Systems should recognize that the content of the
  various parts are interchangeable. Systems
  should choose the "best" type based on the local
  environment and references, in some cases even
  through user interaction

> Anyhow, what makes IMAP particularly weak compared to HTTP is that it
> isn't designed to allow the server to do arbitrary computation in the
> generation of responses. It accepts data and moves data but it can't
> generate it without warping the protocol.

I don't think so.  Pick an application that works
better for HTTP than IMAP.  Its just that most
implementations are designed for actual mailboxes.

Nothing prevents a server from virtualizing
"mailboxes"

Arguably IMAP is nicer in that it more clearly
differentiates between update and query!

> > > > ODBC/SQL is also nice from the perspective you
> > > > give.  The problem is that it does not specify a
> > > > way of passing the types of objects!!!!!
> > >
> > > Also not very well geared for large scale, loosely coupled computing.
> >
> > Why?
>
> Exposing your relational database schema to the world is not good
> encapsulation!

Nothing stops you from exposing a view of your
schema rather than your underlying schema.  If you
do end up exposing your schema, you can always
expose a view later when you change it.

Since there is a pretty direct mapping between
resources and objects in table, I am not really
sure what you are arguing here.

> > I think it is the main benefit of the protocol and
> > the big problem with most RPC protocols.  They
> > don't provide a standard way of representing
> > all types.
>
> We'll have to agree to disagree. The list of MIME types are part of the
> Internet. Any protocol can easily adopt the relevant ones.

But they don't.  In particular, XML-RPC does not
use MIME content types.  Niether does RMI or
Corba.  SOAP sort-of uses them in the SOAP with
attachments spec, but it is really an
afterthought.

The reason why HTTP and SMTP have been so
succesful in letting people talk to one another is
MIME.  No non-MIME transport protocol has been
particularly successful.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:522
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 09:59:16
Subject:Re: [rest-discuss] Comments on latest rev of the HttpEvents spec
Message:

On Fri, 1 Feb 2002, Paul Prescod wrote:
> > Ugh.  If you are doing this, then you should allow
> > notification messages to specify alternative
> > servers (preemptive redirect).
>
> I may do that but it is also easy to do that at the application
> layer...anyhow, I call it "watched-URI". You call it
> preemptive-redirect. It's a URI where you can get the resource.

If watched-URI is optional, then I don't have a
strong objection to it.  I just want to make sure
that systems work properly with trivial
implementations.

> > > I guess I'll take it out and see if a need for it arises. My main
> > > concern is that while you are retrying one event you don't want to build
> > > up a larger and larger queue of events you are retrying for the same
> > > missing subscriber until you start to interfere with network
> > > performance.
> >
> > If the client misses notifications, that is OK.
> > Why not just drop them?
>
> What if the notification is for an important email that just arrived?
> Late is better than never. Retry is just a MAY. If a publisher doesn't
> want to implement it, they don't have to. Depends on the
> mission-criticality of the application.

OK.  But if notification bodies are optional, then
you don't need to accumulate a queue of update
messages for the client.  You just need to send
the last one.

> >
> > Paul, this thing should be really easy to
> > implement.
> > The pure URI version with message dropping allowed
> > means that each time a watched resource is changed
> > it just iterates through a notification list
> > issuing ___ requests with no content.
>
> Versus tagging each URI with "Watched-URI: $uri \nSubscription-URI:
> $sub_base?$uri". It's not hard either way.

It is harder because then server implementations
MUST know what their URI is.  I've seen too many
server environments where you don't.

> > I think this gets you almost everything you want.
> >
> > Adding all sorts of negotiation seems annoying.
>
> A few flags are not a major deal. We're talking about implementing in
> two hours or three!

As long as support for negotiation isn't
mandatory!

I want subscription to be as simple as

  POST /foo/bar/subscription HTTP/1.0
  Subscriber: http://myserver/foo/bar/handler


----
Note in reading the spec. again I think the big
gap is actually in acquiring the subscription
resource!

For example, you might want a polling server to
notify you of changes to a resource even if the
underlying resource server is not implementing
this protocol (and therefore doesn't send a
Subscriptions: header).

Rather than having a resource issue a
Subsriptions: header, it makes much more sense for
a subscription to issue a "location:" header
pointing to the underlying subscribed resource.

Even better, it should issue a location-regex:
header.  That way you could watch collections of
urls that match a particular regex or set of
regexes.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:523
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 10:08:59
Subject:Re: [rest-discuss] Comments on latest rev of the HttpEvents spec
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> OK.  But if notification bodies are optional, then
> you don't need to accumulate a queue of update
> messages for the client.  You just need to send
> the last one.

If the application has meaningful notification bodies then it might
prefer to queue and retry.


>...
> It is harder because then server implementations
> MUST know what their URI is.  I've seen too many
> server environments where you don't.

All I ask is that you know ONE of your URIs. i.e. that you can generate
a URI for yourself. 

Anyhow, I'll keep thinking about this.

>...
> Note in reading the spec. again I think the big
> gap is actually in acquiring the subscription
> resource!

You don't need to get a subscription resource if you already know of a
server that provides that service. The Subscription: URI is for when you
DON'T know of one and you DO want to ask the server whether it can do it
for you.

> For example, you might want a polling server to
> notify you of changes to a resource even if the
> underlying resource server is not implementing
> this protocol (and therefore doesn't send a
> Subscriptions: header).

No problem. If you now how to generate a Subscriptions resource just by
pasting together uris then you can do that.

> Rather than having a resource issue a
> Subsriptions: header, it makes much more sense for
> a subscription to issue a "location:" header
> pointing to the underlying subscribed resource.

I think this is an orthogonal issue. But yes, I do want subscription
resources to be self-describing about what they are watching,  what
their expiry policy is, etc. There will be standard headers for that
stuff.

> Even better, it should issue a location-regex:
> header.  That way you could watch collections of
> urls that match a particular regex or set of
> regexes.

How would you implement that as a polling proxy? I think that this is
way into the domain of the application now. If it wants to provide it
then it could do so by providing you with a WATCH on a regex URI query
that generates a container object...like watching your vanity search on
Google.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:524
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 10:20:24
Subject:Re: [rest-discuss] Why is HTTP special?
Message:

"S. Alexander Jacobson" wrote:
> 
> On Fri, 1 Feb 2002, Paul Prescod wrote:
> > > Re URI handling, do you mean RFC2192?
> > The protocol doesn't know anything about RFC2192, does it?
> 
> Does it need to?  What are you trying to
> accomplish?

I'd like (e.g.) to be able to make a resource such that references to
that resource result in redirects to another resource on another machine
with no coordination between the two machines.

>...
> > Don't know what you mean. Can IMAP do content-negotiation so that I can
> > ask for a particular message in different content-types depending on the
> > client?
> 
> That is the purpose of multipart/alternative.  See
> RFC2046 sec. 5.1.4:

It isn't the same thing. The information producer has to generate all of
the types speculatively.

>...
> I don't think so.  Pick an application that works
> better for HTTP than IMAP. 

Does IMAP even have a notion of non-authorized references that would
allow me to reference public IMAP servers? Anyhow, I gave you an example
above.

>...
> Nothing stops you from exposing a view of your
> schema rather than your underlying schema.  If you
> do end up exposing your schema, you can always
> expose a view later when you change it.

It typically is not that easy in practice. You really need a rich,
Turing complete, programmatic layer between outsiders and your databases
-- much more than a view with some stored procedures. You need to be
able to unify multiple data sources. So you would have to *implement*
the ODBC/SQL interface in code.

Even relational companies do not push ODBC/SQL as a good middle-teir
integration so I

> Since there is a pretty direct mapping between
> resources and objects in table, I am not really
> sure what you are arguing here.

That ODBC/SQL is only intended to be an abstraction layer over
relational databases. Trying to make it a general purpose integration
layer for (e.g.) structured data and multiple data sources will be
painful.

>...
> The reason why HTTP and SMTP have been so
> succesful in letting people talk to one another is
> MIME.  No non-MIME transport protocol has been
> particularly successful.

I will agree that this is yet another reason why the RPCs will probably
fail...

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:525
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 10:24:50
Subject:Re: [rest-discuss] Comments on latest rev of the HttpEvents spec
Message:

On Fri, 1 Feb 2002, Paul Prescod wrote:
> > OK.  But if notification bodies are optional, then
> > you don't need to accumulate a queue of update
> > messages for the client.  You just need to send
> > the last one.
>
> If the application has meaningful notification bodies then it might
> prefer to queue and retry.

It could always consolidate all the changes into
one message body, avoiding queuing.

> > It is harder because then server implementations
> > MUST know what their URI is.  I've seen too many
> > server environments where you don't.
>
> All I ask is that you know ONE of your URIs. i.e. that you can generate
> a URI for yourself.

The problem is that the URI you generate for
yourself may be inaccessible by the client.

> > Note in reading the spec. again I think the big
> > gap is actually in acquiring the subscription
> > resource!
>
> You don't need to get a subscription resource if you already know of a
> server that provides that service. The Subscription: URI is for when you
> DON'T know of one and you DO want to ask the server whether it can do it
> for you.

The issue is that, as the spec stands, you can't
(at the protocol level) correlate a subscription
with a resource unless that resource support it.

I suppose that is ok.  It is just a little wierd.
There is no reason some subscription directory
page can't provide URLs of various subscription
resources.  However, if it does, I think it would
be nice if subcription resources identified
themselves in some way so that user-agents can
handle them in some automated way.

> > For example, you might want a polling server to
> > notify you of changes to a resource even if the
> > underlying resource server is not implementing
> > this protocol (and therefore doesn't send a
> > Subscriptions: header).
>
> No problem. If you now how to generate a Subscriptions resource just by
> pasting together uris then you can do that.

??? Can you explain?
I think the answer above is that you just know
out-of-band the resource to which the subscription
refers.

> > Rather than having a resource issue a
> > Subsriptions: header, it makes much more sense for
> > a subscription to issue a "location:" header
> > pointing to the underlying subscribed resource.
>
> I think this is an orthogonal issue. But yes, I do want subscription
> resources to be self-describing about what they are watching,  what
> their expiry policy is, etc. There will be standard headers for that
> stuff.

ok.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:526
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 10:28:40
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

"S. Alexander Jacobson" wrote:
> 
> ...
> 
> I don't think NotificationQueuing makes sense.
> Why not just have an offline client ask for the
> access log of its relay server?

What do you mean by relay server? In what sense is the queuing
intermediary not a relay server?

> Either way, if the intermediary just stores the
> URIs requested the client can do mapping whenever
> it likes.

Probably. It's just so ugly to have to pass around those double-encoded
URIs.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:527
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 10:37:21
Subject:Re: [rest-discuss] Comments on latest rev of the HttpEvents spec
Message:

"S. Alexander Jacobson" wrote:
> 
> ...
> >
> > If the application has meaningful notification bodies then it might
> > prefer to queue and retry.
> 
> It could always consolidate all the changes into
> one message body, avoiding queuing.

It's up to the application. I don't know if there is anything we
disagree on here.

>...
> ??? Can you explain?
> I think the answer above is that you just know
> out-of-band the resource to which the subscription
> refers.

There is a CGI script that does polling. You call it like this:

http://poll.com/poll.cgi?uri=http://www.slashdot.org

Now you get "first post" every time. Except for the double encoding.
Argh, why can't URIs contain URIs?

This is another way of getting a subscription to slashdot rather than
going to the page and asking it how to subscribe to it. The primary
reason resources can declare themselves watchable and nominate their
subscriptions URI is because they can implement something much more
efficient than polling!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:528
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 10:46:35
Subject:Re: [rest-discuss] Why is HTTP special?
Message:

On Fri, 1 Feb 2002, Paul Prescod wrote:
> > On Fri, 1 Feb 2002, Paul Prescod wrote:
> > > > Re URI handling, do you mean RFC2192?
> > > The protocol doesn't know anything about RFC2192, does it?
> >
> > Does it need to?  What are you trying to
> > accomplish?
>
> I'd like (e.g.) to be able to make a resource such that references to
> that resource result in redirects to another resource on another machine
> with no coordination between the two machines.

E.g. someone emails you a web page with an IMAP
URL in it.  You click on the URL and your browser
retrieves the IMAP page?

That is the whole purpose of RFC2192?

If you mean 30x style redirection, you can return
a message with a message/external-body pointing to
some IMAP URL.

> >...
> > > Don't know what you mean. Can IMAP do content-negotiation so that I can
> > > ask for a particular message in different content-types depending on the
> > > client?
> >
> > That is the purpose of multipart/alternative.  See
> > RFC2046 sec. 5.1.4:
>
> It isn't the same thing. The information producer has to generate all of
> the types speculatively.

You want server negotiation rather than client
negotiation.  The HTTP spec appears to discourage
server negotiation.

In practice, the server has only a finite set of
types and can enumerate them without sending them
all using the message/external-body.

If you really want the equivalent of Accept:,
style content-negotiation, you can implement it
with Search.

> >...
> > I don't think so.  Pick an application that works
> > better for HTTP than IMAP.
>
> Does IMAP even have a notion of non-authorized references that would
> allow me to reference public IMAP servers?

Yes, it is like anonymous FTP.  See e.g.
http://www.cyrusoft.com/support/faq/anonimap.html

> > Nothing stops you from exposing a view of your
> > schema rather than your underlying schema.  If you
> > do end up exposing your schema, you can always
> > expose a view later when you change it.
>
> It typically is not that easy in practice. You really need a rich,
> Turing complete, programmatic layer between outsiders and your databases
> -- much more than a view with some stored procedures. You need to be
> able to unify multiple data sources. So you would have to *implement*
> the ODBC/SQL interface in code.

Why?   You are just implementing

  SELECT contentType,content FROM resources
  WHERE id='someuri.html'.


> Even relational companies do not push ODBC/SQL as a good middle-teir
> integration so I

Actually, Oracle basically thinks of web apps as a
think layer on top of stored procedures and
queries.

> > Since there is a pretty direct mapping between
> > resources and objects in table, I am not really
> > sure what you are arguing here.
>
> That ODBC/SQL is only intended to be an abstraction layer over
> relational databases. Trying to make it a general purpose integration
> layer for (e.g.) structured data and multiple data sources will be
> painful.

So you want an odbc URL.  That exists.
Delivering an odbcURL + SQL tuple seems pretty
straightforward.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:529
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 10:50:41
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

> > I don't think NotificationQueuing makes sense.
> > Why not just have an offline client ask for the
> > access log of its relay server?
>
> What do you mean by relay server? In what sense is the queuing
> intermediary not a relay server?

Sorry, I meant queuing intermediary.
The point remains with either terminology.


> > Either way, if the intermediary just stores the
> > URIs requested the client can do mapping whenever
> > it likes.
>
> Probably. It's just so ugly to have to pass around those double-encoded
> URIs.

Why are you passing them?

Suppose that the client has two subscriptions:
  http://intermediary.com/~client/sub1
   and
  http://intermediary.com/~client/sub2

It then requests all updates simply by doing:

  http://intermediary.com/getLog?user=client

it gets back

  /sub1
  /sub2

The client knows how to map these back into URLs
somewhere else.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:530
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 15:10:33
Subject:Re: [rest-discuss] Comments on latest rev of the HttpEvents spec
Message:


Paul Prescod wrote:

> Jeff Bone wrote:
> >
> > Great stuff, Paul!  :-)
> >
> > (1) I think we should go all the way with the "subscription"
> > terminology.  Instead of "watchable resource" and "Watched-URI,"
> > "subscribable resource" and "Subscribed-URI".  Instead of just
> > "Location," "Subscription-Location."  Etc.
>
> Not bad...I wonder if we'll regret using pub/sub terminology if people
> think it is too unlike pub/sub. When you subscribe to Playboy you don't
> get a once a month notification that there is a new edition available.
> You get a *magazine*. So our model is somewhat different. As you said,
> it is almost cache invalidation.

OTOH, I think this is easily justified --- for Web-based subscriptions
today, you don't expect to get the content sent to you, you expect to have
the content change from time to time and you're expected to go and get it.
This is just gravy on top of that. :-)

> > (4) It might be useful to require an appropriate validator
> > (entity tag or last-modified header) in every notification.
>
> Require is a little strong. Remember that part of the genious of HTTP is
> that basic implementations are so simple. MUST's start raising the bar.

That's true.  Perhaps SHOULD.  The problem with MAY is that nobody
implements it, and application developers can't depend on it.

> One reason that I'm not happy with it yet as a cache invalidation
> protocol is that it is not good at replicating collections. It's easy to
> watch a document that represents a collection. But you can only
> replicate the sub-resources if you understand the syntax of the
> container. HTTP should have a "give me this resource's children" method
> or something...

I was just thinking about this in the shower thismorning, just a few minutes
ago! (Ugh, I know, TMI. ;-)  Cf. next message, "Notifications on
Containers."

jb








-----------------------------------------------------------------------------------
Post ID:531
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 15:27:38
Subject:Notifications on Containers
Message:

So we've got a problem we need to solve with notifications on
containers.  As a cautionary note:  I think we need to tread
lightly, here.  We don't want to hardwire any particular kind of
container semantics into the spec --- IMO, one of the problems
with DAV is that it imposes a new and rigid container semantics
on Web-based systems, one that isn't necessarily universal.  That
said...

When subscribing to a container, there are two possible kinds of
notification of interest:  changes to the contents of the
container (i.e., what is in it) --- potentially recursively ---
and changes *in* the contents of the container (i.e., changes to
the things in it) --- again potentially recursively.  In order to
subscribe to a particular subtree of the resource space, however
an application may define that, you shouldn't have to subscribe
to each individual resource in that subtree.  So we need two
mechanisms:  a notification-time specifier that indicates which
resource has changed, and a subscription-time specifier that
indicates the "depth" of the subscription.

NOTIFICATION SPECIFIER
----------------------------

This one's easy.  A container which generates notifications
SHOULD include a header "Changed-URI" that gives the full URI for
the resource which has changed, generating this event.  The
Changed-URI MAY be a different URI than the Subscribed-URI /
Watched-URI associated with the subscription.  A Changed-URI in a
notification SHOULD (?) be a sub-URI of the Subscribed-URI, i.e.,
a URI that has as a leading substring the full Subscribed-URI.

SUBSCRIPTION SPECIFIER
----------------------------

This one is tricky.  At a first pass, it might be acceptable to
simply allow two kinds of container subscriptions:  subscriptions
to change notifications when the top-level contents of the
container change, and subscriptions to changes to the top-level
contents or to any of the contained objects, recursively.  I.e.,
a "recursive" boolean.  There are perhaps two ways to do this.

(1)  On the subscription request, the client could pass a header
"Recursive-Subscription" along to the subscribed resource.

(2)  We could introduce some URI magic.  Before everyone begins
yelling that this violates URI opacity, consider OPTIONS *.  It's
already the case that * is in effect a special URI that in the
context of OPTIONS means "state of the server that receives the
request."  With that in mind, assume

    /foo
    /foo/bar
    /foo/baz/baf

/foo/ is a container that contains a non-container /foo/bar, and
a container /foo/baz/ that itself contains a non-container
/foo/baz/baf.  A subscriber might specify

    /foo/*

To get notifications in all of the following circumstances:  (a)
the contents of /foo/ change.  (b) The state of /foo/bar
changes.  (c)  The contents of /foo/baz/ change.  (d)  The state
of /foo/baz/baf changes.

A subscription on just /foo/ would simply generate events when
the contents of /foo/ change.

I actually prefer the second option;  it gives a name-based
mechanism for distinguishing between the object itself and the
subtree, and let's name-based dispatch code figure out what's
going on rather than having to grope through the headers.
Sticking it in the headers feels a bit too much to me like RPC
with paramater-passing in the headers.  But it's only a mild
preference.

$0.02,

jb








-----------------------------------------------------------------------------------
Post ID:532
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 15:50:11
Subject:Re: [rest-discuss] Notifications on Containers
Message:

We might also need a way for a resource to indicate that it supports
recursive subscription.  Any thoughts on this?

Jeff Bone wrote:

> So we've got a problem we need to solve with notifications on
> containers.  As a cautionary note:  I think we need to tread
> lightly, here.  We don't want to hardwire any particular kind of
> container semantics into the spec --- IMO, one of the problems
> with DAV is that it imposes a new and rigid container semantics
> on Web-based systems, one that isn't necessarily universal.  That
> said...
>
> When subscribing to a container, there are two possible kinds of
> notification of interest:  changes to the contents of the
> container (i.e., what is in it) --- potentially recursively ---
> and changes *in* the contents of the container (i.e., changes to
> the things in it) --- again potentially recursively.  In order to
> subscribe to a particular subtree of the resource space, however
> an application may define that, you shouldn't have to subscribe
> to each individual resource in that subtree.  So we need two
> mechanisms:  a notification-time specifier that indicates which
> resource has changed, and a subscription-time specifier that
> indicates the "depth" of the subscription.
>
> NOTIFICATION SPECIFIER
> ----------------------------
>
> This one's easy.  A container which generates notifications
> SHOULD include a header "Changed-URI" that gives the full URI for
> the resource which has changed, generating this event.  The
> Changed-URI MAY be a different URI than the Subscribed-URI /
> Watched-URI associated with the subscription.  A Changed-URI in a
> notification SHOULD (?) be a sub-URI of the Subscribed-URI, i.e.,
> a URI that has as a leading substring the full Subscribed-URI.
>
> SUBSCRIPTION SPECIFIER
> ----------------------------
>
> This one is tricky.  At a first pass, it might be acceptable to
> simply allow two kinds of container subscriptions:  subscriptions
> to change notifications when the top-level contents of the
> container change, and subscriptions to changes to the top-level
> contents or to any of the contained objects, recursively.  I.e.,
> a "recursive" boolean.  There are perhaps two ways to do this.
>
> (1)  On the subscription request, the client could pass a header
> "Recursive-Subscription" along to the subscribed resource.
>
> (2)  We could introduce some URI magic.  Before everyone begins
> yelling that this violates URI opacity, consider OPTIONS *.  It's
> already the case that * is in effect a special URI that in the
> context of OPTIONS means "state of the server that receives the
> request."  With that in mind, assume
>
>     /foo
>     /foo/bar
>     /foo/baz/baf
>
> /foo/ is a container that contains a non-container /foo/bar, and
> a container /foo/baz/ that itself contains a non-container
> /foo/baz/baf.  A subscriber might specify
>
>     /foo/*
>
> To get notifications in all of the following circumstances:  (a)
> the contents of /foo/ change.  (b) The state of /foo/bar
> changes.  (c)  The contents of /foo/baz/ change.  (d)  The state
> of /foo/baz/baf changes.
>
> A subscription on just /foo/ would simply generate events when
> the contents of /foo/ change.
>
> I actually prefer the second option;  it gives a name-based
> mechanism for distinguishing between the object itself and the
> subtree, and let's name-based dispatch code figure out what's
> going on rather than having to grope through the headers.
> Sticking it in the headers feels a bit too much to me like RPC
> with paramater-passing in the headers.  But it's only a mild
> preference.
>
> $0.02,
>
> jb
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:533
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 15:53:39
Subject:Notifications can't be GETs
Message:

Quick thought:  a notification shouldn't use the GET method on
the Subscriber resource --- doing so might be interpreted by an
intermediary as a request for the state of the Subscriber
resource.  Anytime a Subscriber responds to a GET request, the
response SHOULD be explicitly non-cacheable.  A notification
itself SHOULD be a method other than GET;  I'm in favor of saying
it MUST be a POST.

Thoughts?

jb








-----------------------------------------------------------------------------------
Post ID:534
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 16:05:03
Subject:Re: [rest-discuss] Notifications on Containers
Message:

Jeff, Paul,

> So we've got a problem we need to solve with notifications on
> containers.

Can you explain this one again?  It is not clear.
The context of this discussio is cache
invalidation.  The notion is that the cache
contains some set of resources and we want the
cache to request only the documents which have
changed.  Is there another application for this or
do we think this particular application is
sufficiently common to warrant special spec.
features?

> When subscribing to a container, there are two possible kinds of
> notification of interest:  changes to the contents of the
> container (i.e., what is in it) --- potentially recursively ---
> and changes *in* the contents of the container (i.e., changes to
> the things in it) --- again potentially recursively.

So a client can subscribe either to pages
generated with this:

(1)    find -newer lastcheck htdocs -print0

or pages generated with this:

(2)    find -newer lastcheck htdocs -exec cat;


> So we need two
> mechanisms:  a notification-time specifier that indicates which
> resource has changed, and a subscription-time specifier that
> indicates the "depth" of the subscription.

Whether the cache wants (1) or (2) depends on
whether the it can update itself using sub-file
level diffs.

But, I am not seeing why this stuff isn't already
covered in the existing notification spec?

Why do need need a special protocol for
containers, when I can define resources that
correspond to arbitrary container semantics and
subscribe to them?

I think the issue here is really specifying a
common use case for diff and is irrelevant to
whether the resource is a container or not.
(I am with Mark here; the notion of container is
sort of meaningless in HTTP)


On Fri, 1 Feb 2002, Jeff Bone wrote:
> NOTIFICATION SPECIFIER
> ----------------------------
>
> This one's easy.  A container which generates notifications
> SHOULD include a header "Changed-URI" that gives the full URI for
> the resource which has changed, generating this event.  The
> Changed-URI MAY be a different URI than the Subscribed-URI /
> Watched-URI associated with the subscription.  A Changed-URI in a
> notification SHOULD (?) be a sub-URI of the Subscribed-URI, i.e.,
> a URI that has as a leading substring the full Subscribed-URI.

This just seems like a special case of where to
retrieve the diff.


> SUBSCRIPTION SPECIFIER
> ----------------------------
>
> This one is tricky.  At a first pass, it might be acceptable to
> simply allow two kinds of container subscriptions:  subscriptions
> to change notifications when the top-level contents of the
> container change, and subscriptions to changes to the top-level
> contents or to any of the contained objects, recursively.  I.e.,
> a "recursive" boolean.  There are perhaps two ways to do this.

I think there are more.  Look at all the options
to the unix 'find' command.
* last modified
* last accessed
* last created
* depth
* file patter (e.g. only .html)
* file owner/group

This seems like a minefield.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax









-----------------------------------------------------------------------------------
Post ID:535
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 16:07:26
Subject:Re: [rest-discuss] Notifications can't be GETs
Message:

Notifications may not be GETs because a
notification is an update the the notified
resource!

If notifications are booleans then they are PUT.
If notifications have time stamps or optional
content they are POST.

-Alex-

On Fri, 1 Feb 2002, Jeff Bone wrote:

>
> Quick thought:  a notification shouldn't use the GET method on
> the Subscriber resource --- doing so might be interpreted by an
> intermediary as a request for the state of the Subscriber
> resource.  Anytime a Subscriber responds to a GET request, the
> response SHOULD be explicitly non-cacheable.  A notification
> itself SHOULD be a method other than GET;  I'm in favor of saying
> it MUST be a POST.
>
> Thoughts?
>
> jb
>
>
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:536
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-01 16:10:48
Subject:Re: [rest-discuss] Notifications can't be GETs
Message:

Haven't caught up on your rest-discuss reading yet, Jeff? 8-)
(I know I haven't).

Lucas and I talked about this.  I think any method with side-effects
is ok.

> Quick thought:  a notification shouldn't use the GET method on
> the Subscriber resource --- doing so might be interpreted by an
> intermediary as a request for the state of the Subscriber
> resource.  Anytime a Subscriber responds to a GET request, the
> response SHOULD be explicitly non-cacheable.  A notification
> itself SHOULD be a method other than GET;  I'm in favor of saying
> it MUST be a POST.
> 
> Thoughts?
> 
> jb

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:537
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-02-01 14:35:03
Subject:history of URI parameters
Message:

Came across this again...


----- Forwarded message from "Roy T. Fielding" <fielding@...> -----

Date: Mon, 03 Jan 2000 11:28:23 -0800
From: "Roy T. Fielding" <fielding@...>
To: Mark Nottingham <mnot@...>
Cc: http-wg@..., mnot@...
Subject: Re: server parsing of URI path parameters 

In message <19991230095914.A436@...>, Mark Nottingham writes:
>
>I've been looking at use of parameters on path segments of URIs, as
>discussed in RFC2396 (section 3.3).
>
>As I understand it, the original reason that parameters were used,
>and therefore the semicolon was a reserved character, is
>pre-HTTP/1.1 range specification.

Actually, no, they were introduced in RFC 1808 long before the range
hack.  Before that, I'd say they were most influenced by the deisre
to support versioning a la VMS.

>I'm not clear on their current use, and was a bit surprised
>to see 2396 say that each path segment could have its own parameters, so
>that you could get:
>  http://www.foo.com/bar;a=1;b=2/baz/bat.gif;g=5
>and so forth. If anyone could clear up the history here, I'd be grateful.

Think of it as an issue of precedence.  In almost all URL parsers,
the slash characters have precedence over any other character during
routine parsing of components.  The result is that the path is
separated into path segments before anything looks at the semicolons.

>With that in mind, a more HTTP-specific question: How should an
>origin server treat a request that includes parameters? Some trival
>testing suggests that current practice is to treat them as part of
>the path, so that an error is returned. Would it be better to have
>them ignore parameters that aren't understood?

That is entirely dependent on the nature of the resource.  A server
can interpret its own namespace however it wants.

Cheers,

....Roy


----- End forwarded message -----

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:538
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 16:51:27
Subject:Re: [rest-discuss] idempotent notifications
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>
>
> > Even with no details about the current or changed values of the the
> > resource, I would like to know what type of operation occurred.
>
> You *might* like to know. But is it worth complicating the
> specification?
No. *I* would like to know. Other people *might* want to know. But *I*
definitely do.








-----------------------------------------------------------------------------------
Post ID:539
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 16:52:28
Subject:Re: [rest-discuss] idempotent notifications
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>


> "S. Mike Dierken" wrote:
>
> > "Having information about what happened on the web server" - the web
server
> > would have the results of applying what happned, but it wouldn't have a
> > record of what happened. It wouldn't (in general) have an audit trail -
like
> > 'paul edited this file at 12:00am with vi'. It would have 'the file says
> > "hello world"'.
>
> If the audit trail is important then the server should have a resource
> representing the audit trail. If the audit trail is NOT important then
> why do notification clients care about it? I'm a hardliner on this
> principle that there should be nothing in the notification that is not
> just a summary of information available on the site.

I suspect that approach won't scale well.







-----------------------------------------------------------------------------------
Post ID:540
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 16:54:51
Subject:Re: [rest-discuss] idempotent notifications
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>
>
> > Also, I don't want 'twenty event types', I only want HTTP referenceable
> > 'event types' - a mapping of what occurred into http state transition
> > operations. Having 'twenty event types' is analagous to having twenty
http
> > methods.
>
> I am not convinced that the basic HTTP methods are automatically the set
> of event types all applications would like.

If the applications are 'resource modelling aware' they can only coordinate
via 'resource modification' - and we've already determined that there
are/should be a small number of common/generic modification primitives.
Just as applications understand what deleting a resource means, or posting
to a resource means, they will understand the inverse - a resource was
deleted, a resource was posted to.








-----------------------------------------------------------------------------------
Post ID:541
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 17:02:07
Subject:Re: [rest-discuss] idempotent notifications
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

>
> > Watching a file that contains READ occurrances is fine - but I would
like to
> > declare that in the subscription in a standardized way (WATCH
/foo/logins
> > method=READ) rather than a URI up to application definition (WATCH
> > /foo/logins/all_reads).
>
> And some other user is going to want to watch READ occurrences FROM a
> particular range of IP addresses. We either need to define a really
> hairy, Turing-complete filter language or we need to leave it up to the
> application. I claim that the "HTTP solution" is to leave it up to the
> application to do with resource modeling. Now why is your seemingly
> reasonable request any different in kind, not just degree, from the guy
> who wants to filter by IP address or time of day or content-type or ...

It isn't. That is the kind of filtering I would like to be able to do (other
than the IP example, unless it is framed as an http uri). Just like HTTP
allows me to send JPEG when everybody else is doing HTML. There is a slot
for the concept - not everybody uses it, but its there. Just like not
everybody would use the 'watch for this operation+status on this resource'.
There could be a default to 'watch for method=POST|DELETE|PUT status=2xx on
this resource'

>
> That content-type example is particularly interesting because it is
> purely in the domain of HTTP so it falls into the same category as the
> method. Should people be able to filter on content-type as well as
> method? What about filtering on Host:. etc. etc.
Yes.

>
> Just do it with the URI and be done with it! Reformulating queries and
> filters as URIs is one of the most brilliant things about the Web and I
> want to emulate it.
Perhaps - let me think about it and write down some samples. I like that
idea too - but I'm not sure if that looseness would hurt a 'watch'
pseudo-method (the appearance of being custom/proprietary/non-standard may
slow adoption). A more rigorous/burned-into-the-protocol approach is harder
to do and also harder to deploy, but it might make some people more
confident that it is okay to use.










-----------------------------------------------------------------------------------
Post ID:542
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 17:12:12
Subject:Re: [rest-discuss] idempotent notifications
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>


> "S. Mike Dierken" wrote:
> >
> >...
> > I don't mean the details in the body, I mean (from Alex's example) the
> > method used for the notification.
>
> I think that there are strong backwards-compatibility forces that argue
> in favour of using standard HTTP methods. But actually I'm willing to
> allow the application to use whatever methods (standard or extension) it
> wants.
Yes, I agree completely - the examples were very consice and communicated
the intent just fine, but I wouldn't use those as HTTP methods.
Something like:

--CREATED--
POST /notification/path HTTP/1.1
Content-Type: application/x-www-form-url-encoded

uri=http://shop.widgets-r-us.com/accounting/po/ack/123/
method=PUT

--CHANGED--
POST /notification/path HTTP/1.1
Content-Type: application/x-www-form-url-encoded

uri=http://events.dierken.com/who/mike/status/
method=PUT


--DELETED--
POST /notification/path HTTP/1.1
Content-Type: application/x-www-form-url-encoded

uri=http://rooms.hot-live-chat.com/rooms/98034/55/
method=DELETE








-----------------------------------------------------------------------------------
Post ID:543
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 17:19:25
Subject:Re: Summarization on notifications?
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

>
> I've clarified my thoughts on how to handle notifications for
> collections. Collections are just documents that happen to contain URIs
> to other documents. Just hang a WATCH on that document.
Woohoo! Yes, by george, you've got it! As a Groves dude, this should be
pretty straightforward for you to work out the details of.
And the resource (aka 'collection') may have metadata separate from the list
of URIs - how do distinguish between the two? That's where the 'add/remove'
comes from - they are 'updates' to the 'default collection' property. But
that is all really too complex for now - I can build it in the app layer
with the low level primitives.








-----------------------------------------------------------------------------------
Post ID:544
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 17:24:14
Subject:Re: Summarization on notifications?
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>
>

> I've also clarified my thoughts on message bodies. A notification's only
> responsibility is to report that something changed. It is totally about
> temporality. It's the secret spy-code where the phone rings twice with
> no message.
>
I'm concerned that if this is deployed bodyless by default, there will be a
tremendous amount of traffic back to the server (and there already is that
at the tcp/ip level, this would add more) - a type of 'ack implosion'.
As long as /my/ apps can send the data I'm fine with that, but I'd recommend
the 'no-body' approach as a 'security' optimization at the cost of
scalability.







-----------------------------------------------------------------------------------
Post ID:545
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 17:28:18
Subject:Re: [rest-discuss] Expiration
Message:

----- Original Message -----
From: "Lucas Gonze" <lucas@...>
>
> * The prefix "Requested-" is redundant.  Better wording would be
> "Expiration-Date" and "Expiration-Count".
Would 'max-age' (as applied to the messages) be relevant?
Also, how would you ask for messages from the past (if you had a system with
an 'audit trail'/history)?
The KnowNow stuff has a max-age parameter when creating a subscription, but
I haven't followed this 'expiration' discussion, so it might not be
relevant.







-----------------------------------------------------------------------------------
Post ID:546
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 17:31:17
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>
>
> But at a deep level I hate the idea of inscrutable bytes arriving from
> some remote source without telling me WHY they are arriving or HOW I
> would stop them. That's why I wanted headers that would make the message
> self describing. You would just click (literally or metaphorically) on
> the "unsubscribe URI" and the messages would stop arriving....
>
I feel the same - but it is also possible that response codes to the notify
might be useful (404 not found).
But with some UI agent storing the notifications, it might be better to
'stop the noise now' via the URI in a header.
I like both approaches.






-----------------------------------------------------------------------------------
Post ID:547
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 17:39:13
Subject:Re: [rest-discuss] Comments on latest rev of the HttpEvents spec
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> >
> > Ugh.  If you are doing this, then you should allow
> > notification messages to specify alternative
> > servers (preemptive redirect).
>
> I may do that but it is also easy to do that at the application
> layer...anyhow, I call it "watched-URI". You call it
> preemptive-redirect. It's a URI where you can get the resource.
>

If the client knows what it is watching, and the 'watched-uri' doesn't match
its list, what happens?







-----------------------------------------------------------------------------------
Post ID:548
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 17:41:24
Subject:Re: [rest-discuss] Comments on latest rev of the HttpEvents spec
Message:

----- Original Message -----
From: "S. Alexander Jacobson" <alex@...>
>
> Rather than having a resource issue a
> Subsriptions: header, it makes much more sense for
> a subscription to issue a "location:" header
> pointing to the underlying subscribed resource.
>
> Even better, it should issue a location-regex:
> header.  That way you could watch collections of
> urls that match a particular regex or set of
> regexes.
>

Watching collections via patterns is way cool - can you provide some
examples of what that would look like?






-----------------------------------------------------------------------------------
Post ID:549
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-02-01 17:46:04
Subject:Re: [rest-discuss] Notifications can't be GETs
Message:

If I parse this right, and I'm not sure I do, then I believe the answer
is that it should be a PUT.

Jeff Bone wrote:
> 
> Quick thought:  a notification shouldn't use the GET method on
> the Subscriber resource --- doing so might be interpreted by an
> intermediary as a request for the state of the Subscriber
> resource.  Anytime a Subscriber responds to a GET request, the
> response SHOULD be explicitly non-cacheable.  A notification
> itself SHOULD be a method other than GET;  I'm in favor of saying
> it MUST be a POST.
> 
> Thoughts?
> 
> jb






-----------------------------------------------------------------------------------
Post ID:550
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 17:47:42
Subject:Re: [rest-discuss] Notifications on Containers
Message:

----- Original Message -----
From: "Jeff Bone" <jbone@...>
To: <rest-discuss@yahoogroups.com>
Sent: Friday, February 01, 2002 7:27 AM
Subject: [rest-discuss] Notifications on Containers


>
> When subscribing to a container, there are two possible kinds of
> notification of interest:  changes to the contents of the
> container (i.e., what is in it) --- potentially recursively ---
> and changes *in* the contents of the container (i.e., changes to
> the things in it) --- again potentially recursively.

Yes - containers are interesting. I spent quite a bit of time implementing
this last year at a previous company.
Only got to 'depth=1' because I allowed for multiple sub-collections rather
than one default. And I was using SQL and didn't want a bazillion queries
fired off for each event for each subscription.
It's one thing to define (fully) what the problem is, its another to specify
what portion will be implemented and implement it.






-----------------------------------------------------------------------------------
Post ID:551
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-01 18:04:09
Subject:Re: [rest-discuss] Notifications on Containers
Message:

You may want to distinguish changes that affect the collection via
add/remove and changes that affect the content of the container via update.
Useful, but probably too application specific for everybody (but if it is
really common, it can at least be described).

Recursive stuff is fun. If a resource has more than one named collection
that's even more fun. If it has one 'default' un-named collection its easier
to use the URL sub-path pattern matching approach (but, like you said, URI
opaqueness will break, as well as the 'web-ness' of the Web).

Doing this URI pattern stuff will be really powerful but only for a sub-set
of all applications. So that'll probably end up at the application level and
require documentation of 'my way' of doing things.

If I were doing my own app and had multiple named collections per resource
I'd use

WATCH /foo/bar;children
WATCH /foo/bar;referrers
WATCH /foo/bar;permissions
WATCH /foo/bar (implies /foo/bar;*)

If I didn't have named collections but had one 'default' collection I'd use:
WATCH /foo/bar?method=ADD








-----------------------------------------------------------------------------------
Post ID:552
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-01 18:15:56
Subject:Re: [rest-discuss] history of URI parameters
Message:

Good find.

The mention of ";" appears to be counter to his suggestion on FoRK to
use it as a universal modifier for resource properties (if I understood
him).  My investigations have left me concluding what Roy describes
below, that it's entirely opaque.

BTW, in the hopes of giving me the will necessary to polish off my
opacity report, I'll give you all the URI to it, incomplete as it is.
Comments, suggestions, and encouragement are all welcome.

http://www.markbaker.ca/2002/01/UriOpacityInvestigation/

> 
> Came across this again...
> 
> 
> ----- Forwarded message from "Roy T. Fielding" <fielding@...> -----
> 
> Date: Mon, 03 Jan 2000 11:28:23 -0800
> From: "Roy T. Fielding" <fielding@...>
> To: Mark Nottingham <mnot@...>
> Cc: http-wg@..., mnot@...
> Subject: Re: server parsing of URI path parameters 
> 
> In message <19991230095914.A436@...>, Mark Nottingham writes:
> >
> >I've been looking at use of parameters on path segments of URIs, as
> >discussed in RFC2396 (section 3.3).
> >
> >As I understand it, the original reason that parameters were used,
> >and therefore the semicolon was a reserved character, is
> >pre-HTTP/1.1 range specification.
> 
> Actually, no, they were introduced in RFC 1808 long before the range
> hack.  Before that, I'd say they were most influenced by the deisre
> to support versioning a la VMS.
> 
> >I'm not clear on their current use, and was a bit surprised
> >to see 2396 say that each path segment could have its own parameters, so
> >that you could get:
> >  http://www.foo.com/bar;a=1;b=2/baz/bat.gif;g=5
> >and so forth. If anyone could clear up the history here, I'd be grateful.
> 
> Think of it as an issue of precedence.  In almost all URL parsers,
> the slash characters have precedence over any other character during
> routine parsing of components.  The result is that the path is
> separated into path segments before anything looks at the semicolons.
> 
> >With that in mind, a more HTTP-specific question: How should an
> >origin server treat a request that includes parameters? Some trival
> >testing suggests that current practice is to treat them as part of
> >the path, so that an error is returned. Would it be better to have
> >them ignore parameters that aren't understood?
> 
> That is entirely dependent on the nature of the resource.  A server
> can interpret its own namespace however it wants.
> 
> Cheers,
> 
> ....Roy
> 
> 
> ----- End forwarded message -----
> 
> -- 
> Mark Nottingham
> http://www.mnot.net/
>  
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:553
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-02-01 18:37:33
Subject:Re: [rest-discuss] history of URI parameters
Message:

Nice! 

Another thing to note is that a URI with a query is effectively
always a leaf node, whilst one with parameters can be a parent.


2396 says of parameters

   Each path segment may include a sequence of parameters, indicated
   by the semicolon ";" character.  The parameters are not
   significant to the parsing of relative references.

which seems to fit nicely into your doc's concept of whether a
separator is significant in terms of establishing a hierarchical
relationship.

I'm leaning towards a use of parameters as ways to identify
contextually (?) different variants of a resource; I know you talked
about using conneg to negotiate an edit form of a LDAP entry (for
example), but I still scratch my head at that. IMHO it makes more
sense to say

  http://address.example.org/UserEntry <-- a representation of the entry
  http://address.example.org/UserEntry;editform <-- the editable form

Thoughts? 



On Fri, Feb 01, 2002 at 01:15:56PM -0500, Mark Baker wrote:
> Good find.
> 
> The mention of ";" appears to be counter to his suggestion on FoRK to
> use it as a universal modifier for resource properties (if I understood
> him).  My investigations have left me concluding what Roy describes
> below, that it's entirely opaque.
> 
> BTW, in the hopes of giving me the will necessary to polish off my
> opacity report, I'll give you all the URI to it, incomplete as it is.
> Comments, suggestions, and encouragement are all welcome.
> 
> http://www.markbaker.ca/2002/01/UriOpacityInvestigation/
> 
> > 
> > Came across this again...
> > 
> > 
> > ----- Forwarded message from "Roy T. Fielding" <fielding@...> -----
> > 
> > Date: Mon, 03 Jan 2000 11:28:23 -0800
> > From: "Roy T. Fielding" <fielding@...>
> > To: Mark Nottingham <mnot@...>
> > Cc: http-wg@..., mnot@...
> > Subject: Re: server parsing of URI path parameters 
> > 
> > In message <19991230095914.A436@...>, Mark Nottingham writes:
> > >
> > >I've been looking at use of parameters on path segments of URIs, as
> > >discussed in RFC2396 (section 3.3).
> > >
> > >As I understand it, the original reason that parameters were used,
> > >and therefore the semicolon was a reserved character, is
> > >pre-HTTP/1.1 range specification.
> > 
> > Actually, no, they were introduced in RFC 1808 long before the range
> > hack.  Before that, I'd say they were most influenced by the deisre
> > to support versioning a la VMS.
> > 
> > >I'm not clear on their current use, and was a bit surprised
> > >to see 2396 say that each path segment could have its own parameters, so
> > >that you could get:
> > >  http://www.foo.com/bar;a=1;b=2/baz/bat.gif;g=5
> > >and so forth. If anyone could clear up the history here, I'd be grateful.
> > 
> > Think of it as an issue of precedence.  In almost all URL parsers,
> > the slash characters have precedence over any other character during
> > routine parsing of components.  The result is that the path is
> > separated into path segments before anything looks at the semicolons.
> > 
> > >With that in mind, a more HTTP-specific question: How should an
> > >origin server treat a request that includes parameters? Some trival
> > >testing suggests that current practice is to treat them as part of
> > >the path, so that an error is returned. Would it be better to have
> > >them ignore parameters that aren't understood?
> > 
> > That is entirely dependent on the nature of the resource.  A server
> > can interpret its own namespace however it wants.
> > 
> > Cheers,
> > 
> > ....Roy
> > 
> > 
> > ----- End forwarded message -----
> > 
> > -- 
> > Mark Nottingham
> > http://www.mnot.net/
> >  
> > 
> > 
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> > 
> >  
> > 
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> > 
> > 
> 
> MB
> -- 
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@...
> http://www.markbaker.ca   http://www.planetfred.com

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:554
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-02-01 18:41:33
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

A list of URIs is too limiting - it may not be practical or possible
to enumerate them all...



On Fri, Feb 01, 2002 at 09:19:25AM -0800, S. Mike Dierken wrote:
> 
> ----- Original Message -----
> From: "Paul Prescod" <paul@...>
> 
> >
> > I've clarified my thoughts on how to handle notifications for
> > collections. Collections are just documents that happen to contain URIs
> > to other documents. Just hang a WATCH on that document.
> Woohoo! Yes, by george, you've got it! As a Groves dude, this should be
> pretty straightforward for you to work out the details of.
> And the resource (aka 'collection') may have metadata separate from the list
> of URIs - how do distinguish between the two? That's where the 'add/remove'
> comes from - they are 'updates' to the 'default collection' property. But
> that is all really too complex for now - I can build it in the app layer
> with the low level primitives.
> 
> 
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:555
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 19:20:27
Subject:SQL Trees (was Re: [rest-discuss] Notifications on Containers)
Message:

On Fri, 1 Feb 2002, S. Mike Dierken wrote:
> Yes - containers are interesting. I spent quite a bit of time implementing
> this last year at a previous company.
> Only got to 'depth=1' because I allowed for multiple sub-collections rather
> than one default. And I was using SQL and didn't want a bazillion queries
> fired off for each event for each subscription.
> It's one thing to define (fully) what the problem is, its another to specify
> what portion will be implemented and implement it.

FYI, celko describes a very nice way of managing
acyclic graphs using SQL without generating
bazillion queries.

The trick is to treat subtrees as subsets and give
each node a left,right bound on the total number
of leaves.

Very elegant and very inexpensive.  Gave me a
whole new respect for the power of SQL.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:556
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 19:22:21
Subject:Re: [rest-discuss] Comments on latest rev of the HttpEvents spec
Message:

On Fri, 1 Feb 2002, S. Mike Dierken wrote:
> Watching collections via patterns is way cool - can you provide some
> examples of what that would look like?

I think it is application level.  But I would
imaging wanting to know e.g usage of a
particular set of conference rooms ...

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:557
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 19:27:00
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Fri, 1 Feb 2002, S. Mike Dierken wrote:
> I'm concerned that if this is deployed bodyless by default, there will be a
> tremendous amount of traffic back to the server (and there already is that
> at the tcp/ip level, this would add more) - a type of 'ack implosion'.
> As long as /my/ apps can send the data I'm fine with that, but I'd recommend
> the 'no-body' approach as a 'security' optimization at the cost of
> scalability.

I'm not sure that scaling issues are soo bad.
Servers with lots of subscribers can push
notification out to slaves on other networks in
larger batches.

The spec can also recommend that clients wait to
get the new version of the resource until it is
demanded by a user.

The server can enforce this by spreading out
notification over time, so that clients that do
immediate request updates are spread over time.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:558
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 19:30:38
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Fri, 1 Feb 2002, S. Mike Dierken wrote:
> I feel the same - but it is also possible that response codes to the notify
> might be useful (404 not found).
> But with some UI agent storing the notifications, it might be better to
> 'stop the noise now' via the URI in a header.
> I like both approaches.

User agents that store notifications can PUT to
the URI to create a listenning resource on the
intermediary notification server.  Once the
resource is created notifications will get a non
40x response.

Btw, this means that notifications MUST be POST.
PUT tells the intermediary to create a listener at
that URI.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:559
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 19:42:20
Subject:Traffic
Message:

You see, this is why I'm afraid to go to sleep at night. I never know
how much crud will be awaiting me in the morning.

Maybe if we're all in that state we should consciously slow down...

Anyhow, we'll all be at the Python conference next week, right? ;) ;) ;)

As an aside, there seems to be a frightening overlap of rest-discuss
subscribers and Python programmers. And Tim B-L is a keynoter next week.
And Dan C. has been a Python programmer for ages. Coincidence? I
wonder....

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:560
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 19:46:55
Subject:What method?
Message:

Every body agrees that they shouldn't be GETs. The only question is
whether the spec should be explicit about that or just depend on common
sense. I'm in favour of being explicit.

Next question is whether to hard-code a method. My sense is that you
don't buy much by doing so. 99% of all services will use PUT or POST
depending on whether the change is relative to the previous state fo the
resource or absolute (Mark Baker's idea...stock price change versus new
stock price).

Leaving open the option of other methods doesn't seem to have much
interoperability cost to me. People will only use it when they think
that their subscribers will understand it. And it "feels" to me like it
might allow some kinds of coordination where I say: "this thing is going
to change in the future. I want that change to trigger a DELETE over
here and a LOCK over there and ..." 

Of course authentication issues get weird because now the publisher is
standing in for you...so this might not work really in practice.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:561
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 19:54:51
Subject:Etags
Message:

Jeff Bone wrote:
> 
> ...
> 
> > > (4) It might be useful to require an appropriate validator
> > > (entity tag or last-modified header) in every notification.
> >
> > Require is a little strong. Remember that part of the genious of HTTP is
> > that basic implementations are so simple. MUST's start raising the bar.
> 
> That's true.  Perhaps SHOULD.  The problem with MAY is that nobody
> implements it, and application developers can't depend on it.

SHOULD also means they can't depend upon it. Anyhow, here is the
original proposal:

(4) It might be useful to require an appropriate validator
(entity tag or last-modified header) in every notification.  In a
sense, clients are simply caches for particular representations,
and the HttpEvents "protocol" is just a push-based cache
invalidation protocol.  We should reuse the appropriate pieces of
HTTP in this capacity.

Maybe you can go into more detail about why this is important for
clients, servers, intermediaries, how you expect it to be used etc. so
we can figure out how important it is.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:562
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 19:59:53
Subject:Re: [rest-discuss] What method?
Message:

Your point about the existence of intermediaries
requires that the method be neither PUT nor
DELETE.

If I want an intermediary to listen at a
particular URI, I will PUT a listener there.

If I want an intermediate to stop listening, I
will DELETE the listener.

If I want to change the listener in some way
(e.g. log to a different file), I will probably
want to be able to POST a change to the listener
as well.

If I want to get the current status of the
listener I will probably want to GET it.

In general we need to make a distinction between
the way the notification agent talks to a
notification listener and the way the owner of the
listener controls it.

Therefore, I think notification requires a new
method e.g. NOTIFY.

-Alex-

On Fri, 1 Feb 2002, Paul Prescod wrote:

> Every body agrees that they shouldn't be GETs. The only question is
> whether the spec should be explicit about that or just depend on common
> sense. I'm in favour of being explicit.
>
> Next question is whether to hard-code a method. My sense is that you
> don't buy much by doing so. 99% of all services will use PUT or POST
> depending on whether the change is relative to the previous state fo the
> resource or absolute (Mark Baker's idea...stock price change versus new
> stock price).
>
> Leaving open the option of other methods doesn't seem to have much
> interoperability cost to me. People will only use it when they think
> that their subscribers will understand it. And it "feels" to me like it
> might allow some kinds of coordination where I say: "this thing is going
> to change in the future. I want that change to trigger a DELETE over
> here and a LOCK over there and ..."
>
> Of course authentication issues get weird because now the publisher is
> standing in for you...so this might not work really in practice.
>
>  Paul Prescod
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:563
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 19:57:46
Subject:Re: [rest-discuss] Notifications can't be GETs
Message:


"S. Alexander Jacobson" wrote:

> Notifications may not be GETs because a
> notification is an update the the notified
> resource!

Yup.  It wasn't clear that everybody agreed to this --- have been
reading the list in a lossy fashion due to time constraints, thought I
remembered seeing somebody advocating for notifications being any old
method.

jb








-----------------------------------------------------------------------------------
Post ID:564
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 20:08:09
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:


"S. Alexander Jacobson" wrote:

> User agents that store notifications can PUT to
> the URI to create a listenning resource on the
> intermediary notification server.  Once the
> resource is created notifications will get a non
> 40x response.
>
> Btw, this means that notifications MUST be POST.
> PUT tells the intermediary to create a listener at
> that URI.

Frightening as it is, I find myself in complete agreement here.  The motivation
for suggesting POST was just this, an analysis of the impact of PUT on
intermediaries.

jb








-----------------------------------------------------------------------------------
Post ID:565
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 20:13:51
Subject:Re: [rest-discuss] What method?
Message:

"S. Alexander Jacobson" wrote:
>  ....
> In general we need to make a distinction between
> the way the notification agent talks to a
> notification listener and the way the owner of the
> listener controls it.

I think that the listener manager is a totally different resource than
the listener URI. In particular, the listener manager may own many
particular listener URIs...

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:566
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 20:34:14
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

Jeff Bone wrote:
> 
>...
> 
> Frightening as it is, I find myself in complete agreement here.  The motivation
> for suggesting POST was just this, an analysis of the impact of PUT on
> intermediaries.

If you want to use POST to mean two different things on the same
resource (or GET or ...) then probably you should just split the
resource.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:567
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 20:44:47
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:


Paul Prescod wrote:

> Jeff Bone wrote:
> >
> >...
> >
> > Frightening as it is, I find myself in complete agreement here.  The motivation
> > for suggesting POST was just this, an analysis of the impact of PUT on
> > intermediaries.
>
> If you want to use POST to mean two different things on the same
> resource (or GET or ...) then probably you should just split the
> resource.

I don't think we disagree on this, but maybe I'm missing something.  I'm suggesting
that a POST to the Subscriber: URI has as its appropriate (and only) interpretation
that the Subscribed-URI has changed.  (Applications might further describe *how* it
has changed via headers or body, but IMO that's app-specific and should be
out-of-scope for our purposes.)  What other interpretation of POST could there be?
And why allow any other method to have those semantics?

jb








-----------------------------------------------------------------------------------
Post ID:568
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 20:46:08
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:


Mark Nottingham wrote:

> A list of URIs is too limiting - it may not be practical or possible
> to enumerate them all...

Yup, very important point.

jb








-----------------------------------------------------------------------------------
Post ID:569
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 20:58:52
Subject:Re: [rest-discuss] Etags
Message:

Paul Prescod wrote:

> SHOULD also means they can't depend upon it. Anyhow, here is the
> original proposal:

Good point.  So you've argued me back to my original position, which you didn't
seem to agree with. ;-)  Notifications MUST include a validator.  Note that a
notification is however a request, so actually using the etag or last-modified
header is probably inappropriate;  we probably need a notification-specific
version of these things.

> (4) It might be useful to require an appropriate validator
> (entity tag or last-modified header) in every notification.  In a
> sense, clients are simply caches for particular representations,
> and the HttpEvents "protocol" is just a push-based cache
> invalidation protocol.  We should reuse the appropriate pieces of
> HTTP in this capacity.
>
> Maybe you can go into more detail about why this is important for
> clients, servers, intermediaries, how you expect it to be used etc. so
> we can figure out how important it is.

Consider that a subscriber is really in a sense a cache for the subscribed
resource.  This cache supports a "standard" HTTP-based interface (the Subscriber
interface) allowing subscribable resources to pre-emptively notify the cache of
changes and thereby invalidate cached entities.  Given this, it seems useful to
include data in a notification which the cache / subscriber can check against
similar data for its cached representation to determine whether to proceed with
refreshing it.

Using such information would permit caches to avoid extraneous GET / refresh
operations.  Consider:  notification to a list of subscribers is likely to take
time.  A subscribed resource changes.  During the notification process but
before a particular subscriber is notified, that subscriber does a GET and
obtains the current representational state.  They then receive a notification
that the state is changed, but in fact they have the current and correct state.
A mandatory validator in the notification would allow the subscriber to check
its cached copy and determine that a GET was unnecessary at that point.

This is important for servers because it lightens the GET load when things
change;  it's important both for servers and traditional proxy caches as it can
potentially significantly reduce the burden of keeping the cache fresh.  It's
important to clients because, as mentioned, clients are conceptually nothing
more than specialized caches;  the benefits to proxies apply as well to clients.

Does that help, or was it clear as mud? ;-)

jb








-----------------------------------------------------------------------------------
Post ID:570
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 21:08:41
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Fri, 1 Feb 2002, Jeff Bone wrote:
> I don't think we disagree on this, but maybe I'm missing something.  I'm suggesting
> that a POST to the Subscriber: URI has as its appropriate (and only) interpretation
> that the Subscribed-URI has changed.  (Applications might further describe *how* it
> has changed via headers or body, but IMO that's app-specific and should be
> out-of-scope for our purposes.)  What other interpretation of POST could there be?
> And why allow any other method to have those semantics?

My argument in my last mail on this issue is that
POST to the subscriber URL may be an update to the
listener e.g. you may want to tell the listener to
log notifications to a different file or you know
want it to page a user when it recieves
notification.

See my last message for all scenarios.
I argue that therefore either you need a new
method or you need to pass something in the
header/body saying the POST is a notification.

Paul argues that listener management should
happend at a different URL from notification.

I don't think that makes sense.  You can only
notify a listener if it exists.  The most
obvious way to create a listener at a URL is to
PUT a listener there.  The alternative is some
form of RPC with some listener manager which is
ugly.

I suspec Paul is concerned with the example in (1)
describing why CVSSTAT is bad.  The difference is
that NOTIFY is not idempotent so this argument
doesn't apply.

-Alex-

(1) http://www.w3.org/DesignIssues/Architecture

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:571
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 21:17:44
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

Jeff Bone wrote:
> 
>....
> 
> I don't think we disagree on this, but maybe I'm missing something.  I'm suggesting
> that a POST to the Subscriber: URI has as its appropriate (and only) interpretation
> that the Subscribed-URI has changed.  (Applications might further describe *how* it
> has changed via headers or body, but IMO that's app-specific and should be
> out-of-scope for our purposes.)  What other interpretation of POST could there be?
> And why allow any other method to have those semantics?

One way of looking at it is that the notifications are trying to
replicate the content from the publisher to the subscriber. So the
publisher PUSHes representations of the resource or POSTs
representations of changes or extensions to the resource. This would
imply that it would DELETE if the resource was deleted. I don't think
that view is going to go anywhere.

Whether or not you agree with this model you might still want to allow
the application to choose its own method. It would be up to the
publisher and subscriber to decide what the methods mean exactly.

Another way of looking at it (Alex's) is that the POSTs to the listener
would come from the app that owns the listener and would be used to
configure it. So then the publisher should send NOTIFYs.

Or you could say that POSTs on listeners come from publishers but
DELETEs come from the application. Not sure what you would say about
PUT, probably from the publisher...

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:572
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 21:39:36
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:


"S. Alexander Jacobson" wrote:

> Paul argues that listener management should
> happend at a different URL from notification.

I agree.  "Listener management" --- if it's provided by the listener at all --- should
happen at a different URL.  Overloading POST to the same resource to do both notification
and listener management begins to slip away from resource modeling to RPC-land, IMHO.

> I don't think that makes sense.  You can only
> notify a listener if it exists.  The most
> obvious way to create a listener at a URL is to
> PUT a listener there.

Since when is creating the "listener" the Subscribable entity's responsibility?  (I
assume by listener you mean the client-side interface onto which notifications are
dispatched, i.e. the "observer" or what we've been calling the "Subscriber.")

jb








-----------------------------------------------------------------------------------
Post ID:573
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 21:46:43
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:


Paul Prescod wrote:

> One way of looking at it is that the notifications are trying to
> replicate the content from the publisher to the subscriber.

Here I think we disagree --- I started off this whole tangent at that point of view and
have basically convinced myself / been convinced by the conversation (some of it yours!
;-) that what we're specifying is purely a *change notification* protocol, and that
proactive *state replication* in-band with notifications is best left out-of-scope.
(Neither specified nor prohibited.)

That's not to say it's not attractive in many scenarios --- just that we should take baby
steps.  "Hey, this changed" is simpler on a whole lot of dimensions than "Hey, this
changed and here's the new state."  It's more general, too.

jb








-----------------------------------------------------------------------------------
Post ID:574
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 21:59:36
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Fri, 1 Feb 2002, Jeff Bone wrote:
> Since when is creating the "listener" the Subscribable entity's responsibility?  (I
> assume by listener you mean the client-side interface onto which notifications are
> dispatched, i.e. the "observer" or what we've been calling the "Subscriber.")

OIC.  We are having a miscommunication.
The scenario I am describing is one in which the
client has some intermediary that takes care of
listening for notification messages (that hosts
listeners).  So the listener is owned by the
client not by the "subscribable entity."

I imagine a workflow that looks something like
this:

1. client PUTS listener at
     http://intermediary.com/~client/subcription1

2. client PUTS another listener at
     http://intermediary.com/~client/subcription2

3. client requests notifications on http://foo.com
   to be deliverd to the subscription1 URL.

4. client requests notifications on http://goo.com
   to be delivered to the subscription2 URL.

5. intermediary.com recieved NOTIFY messages at
     http://intermediary.com/~client/subcription1
     http://intermediary.com/~client/subcription2
     http://intermediary.com/~client/subcription1

    in all of these cases intermediary responds
    with non 40x status codes

6. client requests changes by e.g.
     http://intermediarty.com/getLogs?user=client

7. client decides that foo.com info is really
   important and would like to be sent a page
   when foo.com changes.  Client issues a POST
   to
     http://intermediary.com/~client/subcription1

8. client is no longer interested in goo.com and
   does
   DELETE http://intermediary.com/~client/subcription2

9. intermdiary recieves another NOTIFY message at
     http://intermediary.com/~client/subcription2
   and now responds with a 404 Not Found.

10 the notification server sees that there is now
no listener and deletes the subscription for
     http://intermediary.com/~client/subcription2

Do you see why a separate listener manager makes
no sense?

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:575
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 22:16:10
Subject:Re: [rest-discuss] Etags
Message:

Jeff Bone wrote:
> 
>...
> 
> Consider that a subscriber is really in a sense a cache for the subscribed
> resource.  

Be careful there...if this is true then we get back to treating PUT as
PUSH CONTENT and POST as PUSH DELTA.

> ... 
> Using such information would permit caches to avoid extraneous GET / refresh
> operations.  Consider:  notification to a list of subscribers is likely to take
> time.  A subscribed resource changes.  During the notification process but
> before a particular subscriber is notified, that subscriber does a GET and
> obtains the current representational state.  They then receive a notification
> that the state is changed, but in fact they have the current and correct state.

Will this happen often enough to worry about? Why would the client do a
GET before it is notified? Maybe just dumb luck. Maybe clairvoyance.
Neither seem important enough to worry about.

> This is important for servers because it lightens the GET load when things
> change;

But maybe standard caching handles that. The client gets a notification
of a change. It asks its local caching proxy for the document. The
caching proxy uses all of the standard HTTP voodoo to say whether its
local copy is fresh "enough".

On the other hand, the etag might be useful to let the client push
through the proxy and really get the latest version if necessary. This
is the more compelling use-case for me. The client says to its local
caching proxy: "I just got this notification that version X of a
resource is available. Please give me a version that is at least that
recent."

>...  it's important both for servers and traditional proxy caches as it can
> potentially significantly reduce the burden of keeping the cache fresh.  It's
> important to clients because, as mentioned, clients are conceptually nothing
> more than specialized caches;  the benefits to proxies apply as well to clients.

I don't mind having optimizations as a SHOULD. They are best practices
that clients and intermediaries do not rely upon but may use to improve
performance. Arguably, all optimizations should be MAY or SHOULD. If you
want to write this up as an optimization SHOULD or MAY, I'd buy it.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:576
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 22:20:03
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:


"S. Alexander Jacobson" wrote:

> On Fri, 1 Feb 2002, Jeff Bone wrote:
> > Since when is creating the "listener" the Subscribable entity's responsibility?  (I
> > assume by listener you mean the client-side interface onto which notifications are
> > dispatched, i.e. the "observer" or what we've been calling the "Subscriber.")
>
> OIC.  We are having a miscommunication.
> The scenario I am describing is one in which the
> client has some intermediary that takes care of
> listening for notification messages (that hosts
> listeners).  So the listener is owned by the
> client not by the "subscribable entity."

We're cool.  This is useful.  I just think we shouldn't necessarily specify listener
management in the same context as just plain notifications.  With you all the way to (6)
with the exception that we aren't assuming NOTIFY, we're assuming POST.

> 6. client requests changes by e.g.
>      http://intermediarty.com/getLogs?user=client
>

Resource model alert!  I have no idea what this means. ;-)

> 7. client decides that foo.com info is really
>    important and would like to be sent a page
>    when foo.com changes.  Client issues a POST
>    to
>      http://intermediary.com/~client/subcription1

I think that this has to be something other than POST, as the POST on that resource
indicates changes on http://foo.com.

> 8. client is no longer interested in goo.com and
>    does
>    DELETE http://intermediary.com/~client/subcription2

No problem.

> 9. intermdiary recieves another NOTIFY message at
>      http://intermediary.com/~client/subcription2
>    and now responds with a 404 Not Found.

Fine, with the exceptions noted above.  Can't assume NOTIFY.  It's a bad idea, because
not all resources are listeners.

jb








-----------------------------------------------------------------------------------
Post ID:577
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-01 22:27:13
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> 1. client PUTS listener at
>      http://intermediary.com/~client/subcription1
> 
> 2. client PUTS another listener at
>      http://intermediary.com/~client/subcription2
> 
> 3. client requests notifications on http://foo.com
>    to be deliverd to the subscription1 URL.
> 
> 4. client requests notifications on http://goo.com
>    to be delivered to the subscription2 URL.

I see these steps very differently. In particular I see the first two
steps as being unnecessary extra coordination headache. Listeners are
not files. Practically speaking the component that implements a listener
is a CGI-alike. It looks like:

http://intermediary.com/listener.cgi?user=paulp

Now without any further coordination with the intermediary, I can go all
over the Web registering URIs like:

http://intermediary.com/listener.cgi?user=paulp&site=http://www.slashdot.org
http://intermediary.com/listener.cgi?user=paulp&site=http://www.news.com
http://intermediary.com/listener.cgi?user=paulp&site=http://www.slate.com

...

The listeners are dynamically created. Or they are in theory "always
there" like every possible Google query is a resource that is always
available.

I configure these by fiddling with listener.cgi, maybe through a web
page. For instance I might tell it to reject notifications from
particular domains or the opposite, reject notifications from domains I
haven't told you about. Or reject notifications that don't have a magic
cookie header. Generally you would manage subscriptions in bulk, not
per-URI, although you could of course do that too if listener.cgi
happens to support it.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:578
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 22:34:31
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Fri, 1 Feb 2002, Jeff Bone wrote:
> We're cool.  This is useful.  I just think we shouldn't necessarily specify listener
> management in the same context as just plain notifications.  With you all the way to (6)
> with the exception that we aren't assuming NOTIFY, we're assuming POST.

I agree we should not be specifying listener
management.  That is why I want notification to be
a distinct method (so as not to get confused with
whatever listener management the client
implements).

If I understand you correctly, the only issue here
is whether the new method should be one for the
client to update the state of the listener or
whether it should be to notify the listener of a
change to the subscribed resource.

I think that it is more natural to use POST to
modify the listener (because we don't want to
write a listener management spec).

However, you don't like NOTIFY because it only
applies to listener URLs and not all URLs are
listener URLs.

So, my question to you is whether all HTTP methods
have to apply to all resources.  The spec has
various 50x status codes, like 501 Not Implemented
or 503 Service Unavailable that I think make it OK
to define methods that don't apply to all
resources.

> > 6. client requests changes by e.g.
> >      http://intermediarty.com/getLogs?user=client
> >
>
> Resource model alert!  I have no idea what this means. ;-)

Yeah.  Me neither.  My point is simply that the
client uses the intermediary to retrieve all of
its notifications.  I am not trying to specify
that interface.  Just provide a simple example.

> > 7. client decides that foo.com info is really
> >    important and would like to be sent a page
> >    when foo.com changes.  Client issues a POST
> >    to
> >      http://intermediary.com/~client/subcription1
>
> I think that this has to be something other than POST, as the POST on that resource
> indicates changes on http://foo.com.

As I said above, I don't see why we can't use
NOTIFY to indicate a change on http://foo.com
and leave POST for the listener to manage itself
in the normal HTTP way.
(Otherwise you start defining a listener
management protocol)

> Can't assume NOTIFY.  It's a bad idea, because
> not all resources are listeners.

See above.  Why does that matter?

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:579
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 22:46:11
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Fri, 1 Feb 2002, Paul Prescod wrote:
> Generally you would manage subscriptions in bulk, not
> per-URI, although you could of course do that too if listener.cgi
> happens to support it.

Paul,

This is also a good way to do listener
management.  If you want to be promiscuous, go
right ahead.  My point is simply to leave
flexibility for the client to manage the listener
however it wants.  I think the only way to do that
is to use an explicit NOTIFY method (or methods).

-Alex-

PS My gut also says that NOTIFY really means
something quite distinct from POST.  In
particular, POST says something about a resource
is to be changed in some way.  NOTIFY signals that
the change has already happened.


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax









-----------------------------------------------------------------------------------
Post ID:580
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 22:52:16
Subject:Re: [rest-discuss] Etags
Message:


Paul Prescod wrote:

> Jeff Bone wrote:
> >
> >...
> >
> > Consider that a subscriber is really in a sense a cache for the subscribed
> > resource.

What I really mean here is this:  HTTP is REpresentational State Transfer.  This is
orthogonal in some respects to whether it's push or pull.  Independent of that, the
basic idea is that state is transferred from origins to others;  those others then do
things with that state.  So in essence it's an object migration protocol for arbitrary
representations of object state, and everybody but the origin server receives /
maintains / caches one of these representations in order to act on it.  Even a browser
can be viewed as a cache with a pretty face.  What we're really adding with HttpEvents
is an optional cache invalidation protocol which operates via HTTP and for which both
sides present a resource-based and HTTP-appropriate interface.

> Be careful there...if this is true then we get back to treating PUT as
> PUSH CONTENT and POST as PUSH DELTA.

Not necessarily.  As mentioned, I'm in favor of treating notifications as just that,
strictly that from the perspective of HttpEvents:  a notification that change has
happened.  It's up to the client to get the state.  Pushing state is an optimization.
(As an optimization, though, it seems that treating those methods that way might be
appropriate in some contexts, but the negotiation details seem hairy so we should
leave it alone.

> Will this happen often enough to worry about? Why would the client do a
> GET before it is notified? Maybe just dumb luck. Maybe clairvoyance.
> Neither seem important enough to worry about.

This kind of argument scares me.  ;-)

Seriously, I see no harm in having the origin server provide a timestamp with each
state-change notification that says "state changed at this time."  Seems to me there's
no downside.  (Or, alternatively, not a timestamp but a fingerprint, etc.  Just
something to let the subscriber check their current representation state against the
origin state.)

> But maybe standard caching handles that. The client gets a notification
> of a change. It asks its local caching proxy for the document. The
> caching proxy uses all of the standard HTTP voodoo to say whether its
> local copy is fresh "enough".

That's true --- but what if the client is itself an intermediary? :-)

> I don't mind having optimizations as a SHOULD. They are best practices
> that clients and intermediaries do not rely upon but may use to improve
> performance. Arguably, all optimizations should be MAY or SHOULD. If you
> want to write this up as an optimization SHOULD or MAY, I'd buy it.

Okay, I haven't come up with a use case for why this should be a MUST, so I'm willing
to let it be optional.

jb








-----------------------------------------------------------------------------------
Post ID:581
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-01 23:01:41
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:


"S. Alexander Jacobson" wrote:

> I agree we should not be specifying listener
> management.  That is why I want notification to be
> a distinct method (so as not to get confused with
> whatever listener management the client
> implements).

The problem with this is that (a) *new methods impose unnecessary adoption friction*, and (b)
*NOTIFY to a listener is not a reasonable part of the generic interface of resources, as not
all resources can be listeners.*  New methods should only be created for generic operations
that are universally meaningful to all potential resources.

> However, you don't like NOTIFY because it only
> applies to listener URLs and not all URLs are
> listener URLs.
>
> So, my question to you is whether all HTTP methods
> have to apply to all resources.

I believe this to be the case.  Whether or not a particular resource supports a particular
method should be an authorization concern, not an interface concern.  Truly universal generic
interfaces have LOTs of benefits;  introducing new type-specific interfaces for certain
resource types is a slippery slope toward losing all the benefits of genericity.

> As I said above, I don't see why we can't use
> NOTIFY to indicate a change on http://foo.com
> and leave POST for the listener to manage itself
> in the normal HTTP way.

Let me think about this.  The argument for is that this already exists for proxy caches;  the
argument against is that reusing it for this purpose may confuse the issue, *and* it's not
clear that it's generic enough.  Maybe it doesn't break things.  Let me digest this.

We're getting awfully close to the same problem as notification for proxy caches with all of
this...  hmmm....

jb








-----------------------------------------------------------------------------------
Post ID:582
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-01 23:21:43
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Fri, 1 Feb 2002, Jeff Bone wrote:
> > I agree we should not be specifying listener
> > management.  That is why I want notification to be
> > a distinct method (so as not to get confused with
> > whatever listener management the client
> > implements).
>
> The problem with this is that (a) *new methods impose unnecessary adoption friction*,

That was MY argument before.  YOU pursuaded me
that new methods are OK. If you want, I can go
rehash YOUR arguments :-)

> and (b)
> *NOTIFY to a listener is not a reasonable part of the generic interface of resources, as not
> all resources can be listeners.*

Yeah, thats what I think we are disagreeing about.

> New methods should only be created for generic operations
> that are universally meaningful to all potential resources.

I don't think LOCK works on all resources.
I don't think POST makes sense for static files.

> I believe this to be the case.  Whether or not a particular resource supports a particular
> method should be an authorization concern, not an interface concern.

How do you explain the differences between:
401 Unauthorized
403 Forbidden
405 Method Not Allowed
501 Not Implemented
503 Service Unavailable

It certainly seems like the HTTP spec contemplates
new non-universal methods.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:583
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-02 01:11:29
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

----- Original Message -----
From: "Mark Nottingham" <mnot@...>


>
> A list of URIs is too limiting - it may not be practical or possible
> to enumerate them all...
That's just from Pauls example. However, is it a 'web collection' is the
things inside aren't first-class resources (uri addressable)?

>
>
>
> On Fri, Feb 01, 2002 at 09:19:25AM -0800, S. Mike Dierken wrote:
> >
> > ----- Original Message -----
> > From: "Paul Prescod" <paul@...>
> >
> > >
> > > I've clarified my thoughts on how to handle notifications for
> > > collections. Collections are just documents that happen to contain
URIs
> > > to other documents. Just hang a WATCH on that document.
> > Woohoo! Yes, by george, you've got it! As a Groves dude, this should be
> > pretty straightforward for you to work out the details of.
> > And the resource (aka 'collection') may have metadata separate from the
list
> > of URIs - how do distinguish between the two? That's where the
'add/remove'
> > comes from - they are 'updates' to the 'default collection' property.
But
> > that is all really too complex for now - I can build it in the app layer
> > with the low level primitives.
> >
> >
> >






-----------------------------------------------------------------------------------
Post ID:584
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-02 01:12:42
Subject:Re: SQL Trees (was Re: [rest-discuss] Notifications on Containers)
Message:

----- Original Message ----- 
From: "S. Alexander Jacobson" <alex@...>
> 
> FYI, celko describes a very nice way of managing
> acyclic graphs using SQL without generating
> bazillion queries.
> 
> The trick is to treat subtrees as subsets and give
> each node a left,right bound on the total number
> of leaves.
> 
> Very elegant and very inexpensive.  Gave me a
> whole new respect for the power of SQL.
> 
Cool - I'll track that down sometime...






-----------------------------------------------------------------------------------
Post ID:585
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-02 01:17:16
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

"S. Alexander Jacobson" wrote:

> That was MY argument before.  YOU pursuaded me
> that new methods are OK. If you want, I can go
> rehash YOUR arguments :-)

This I can say with absolute certainty:  you may have come to your conclusion based on something I
said that you misinterpreted, but it has *never* been my position that new methods are a good
thing, generally speaking.

> I don't think LOCK works on all resources.

I think LOCK the most bletcherous partial-birth abortion in DAV, so that's not a good example.

> It certainly seems like the HTTP spec contemplates
> new non-universal methods.

No doubt.  Lots of things have been "tried" in HTTP at various points, and there is quite a bit of
ambiguity.  My own REST quest is to try to discern what the minimal, diamond-like core of ideas
within HTTP actually consists of;  to figure out, to crib Paul, what the "lambda calculus"-like
underpinnings of the Web are for which everything else is extraneous, sugar, or damage. :-)

jb








-----------------------------------------------------------------------------------
Post ID:586
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-02 01:27:57
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

----- Original Message -----
From: "S. Alexander Jacobson" <alex@...>

I suggest that 'subscription' is a superset of 'listener' and 'route' - it
is a relationship between 'source' and 'destination'.
Your example has this - the 'destination' is
http://intermediarty.com/getLogs?user=client (and what's 'get' doing in the
uri??)
If you want to tell the intermediary how to behave, use this uri (possibly
qualified bythe subscription id) and not the public listener uri.


>
> I imagine a workflow that looks something like
> this:

>
> 6. client requests changes by e.g.
>      http://intermediarty.com/getLogs?user=client
>








-----------------------------------------------------------------------------------
Post ID:587
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-02 01:30:33
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

----- Original Message ----- 
From: "S. Alexander Jacobson" <alex@...>
> 

> PS My gut also says that NOTIFY really means
> something quite distinct from POST.  In
> particular, POST says something about a resource
> is to be changed in some way.  NOTIFY signals that
> the change has already happened.

I agree.







-----------------------------------------------------------------------------------
Post ID:588
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-02 01:31:28
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Fri, 1 Feb 2002, Jeff Bone wrote:
> No doubt.  Lots of things have been "tried" in HTTP at various points, and there is quite a bit of
> ambiguity.  My own REST quest is to try to discern what the minimal, diamond-like core of ideas
> within HTTP actually consists of;  to figure out, to crib Paul, what the "lambda calculus"-like
> underpinnings of the Web are for which everything else is extraneous, sugar, or damage. :-)

OK.  I agree.  Therefore I think the whole
structure of the HTTPEvents spec is wrong.

Clients that want notification should just open up
a persistent GET on a watcher resource.

The watcher resource just sends chunks whenever
the watched resource changes.

You and others made a compelling argument that
this sort of architecture is very scalable so why
not use it.


-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:589
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-02 01:32:22
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

----- Original Message -----
From: "Jeff Bone" <jbone@...>
>
> The problem with this is that (a) *new methods impose unnecessary adoption
friction*, and (b)
> *NOTIFY to a listener is not a reasonable part of the generic interface of
resources, as not
> all resources can be listeners.*  New methods should only be created for
generic operations
> that are universally meaningful to all potential resources.
>

What does it mean to POST to an HTML file? It isn't meaningful. It /might/
be meaningful if you craft a server to do something - but then so would
NOTIFY.






-----------------------------------------------------------------------------------
Post ID:590
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-02 01:35:20
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Fri, 1 Feb 2002, Jeff Bone wrote:
> > It certainly seems like the HTTP spec contemplates
> > new non-universal methods.
>
> No doubt.  Lots of things have been "tried" in HTTP at various points, and there is quite a bit of
> ambiguity.  My own REST quest is to try to discern what the minimal, diamond-like core of ideas
> within HTTP actually consists of;  to figure out, to crib Paul, what the "lambda calculus"-like
> underpinnings of the Web are for which everything else is extraneous, sugar, or damage. :-)

Ok. If you don't want persistent GET, you have to
make an argument why NOTIFY isn't right, rather
than a general philsophical point.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:591
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-02 02:35:13
Subject:HttpEvents as currently contemplated are extraneous?
Message:

So just finished an afternoon reread of Ari Luotonen's book,
hadn't looked at it in a couple of years;  also some material
online.  I've *almost* convinced myself that HttpEvents as we are
currently discussing them are mostly extraneous.  I'm going to
say some things about my understanding of the current very rough
but gradually converging consensus, then lay out the strawman for
why this approach is unnecessary.  It's a straw man, whack away.

CURRENT CONSENSUS:  An HttpEvents protocol could be any one of or
combination of things.  It might be (1) simply a state-change
notification protocol, (2) a push-based state replication
protocol, or (3) a subscription / listener management protocol.
It appears that we are generally converging on (1), viewing (2)
as either an optimization or application-specific or both, and
(3) as interesting but somewhat out-of-scope for this spec.  (We
are talking about reifying subscribers and subscriptions, but
pushing out "listener management" etc.)

Is that about right?

If so, then we may be spinning our wheels somewhat; various folks
did a fair bit of work on NOTIFY back in the early days [1] in
the context of proxy cache notification and in the course of the
HTTP-NG discussions.  Not sure what the current state of NOTIFY
is;  did it ever go anywhere?  I apologize if there's an obvious
answer to this, as my own "cache" of HTTP caching-related
information is a bit stale.  No mention of NOTIFY / this draft in
Ari's 1998 book, and very little I can find via Google.

BUT...

[1] describes a protocol extension (with a "new" method, NOTIFY)
that solves (1) in a very HTTPish way.  It doesn't reify
subscriptions, but it doesn't have to --- it appears that
subscriptions are at-most-once commitments to notify the
subscriber that the state of a resource has changed, for the
purpose of cache invalidation.  Renewal of the subscription
appears to happen incrementally --- the subscription "expires"
after the first notification, and is "renewed" on the subsequent
GET (if any) that happens to refresh the cache after the
notification is received.

The more I think about this, the more elegant it seems.

Here's how this protocol could be used to accomplish (1):

CLIENT -> SERVER
----------------------
GET /foo HTTP/1.1
Accept: text/html
Proxy-Features: my.host.com; notify

(Note that we're "pretending" to be our own proxy server cache.
We're requesting notification of state change on the resource if
it's available.)

SERVER -> CLIENT
---------------------
201 OK
Cache-Control: notify
Content-Type: text/html

...text...

(The SERVER responds and says, among other things, that it is
willing to notify (via the Cache-Control directive) the CLIENT
at-most-once (?) that the resource has changed by possibly
emitting a NOTIFY for that resource to the CLIENT at some later
date.)

Later on, when /foo changes, the SERVER initiates a connection
back to CLIENT (the machine specified in Proxy-Features:, i.e.
my.host.com) and sends notification that the state change
occurred / the cached copy (if any) has expired:

SERVER -> CLIENT
---------------------
NOTIFY /foo HTTP/1.1

(Presumably the fully-qualified URI is somehow reconstructed from
TCP connection data.  This is gross and unworkable, so I would
assume that instead NOTIFY is required to provide a
fully-qualified URI.)

The client CLIENT proceed to refresh its cache via a GET.  At
this point, the SERVER is presumably allowed to stop sending
further notifications;  in order to receive the next
notification, the client parameterizes the GET so that it looks
just like the first one.  This cycle repeats, ad infinitum, as
long as the CLIENT is interested in being updated about state
changes on SERVER/foo:

CLIENT -> SERVER
----------------------
GET /foo HTTP/1.1
Accept: text/html
Proxy-Features: my.host.com; notify

...lather, rinse, repeat...

DISCUSSION
--------------

PROS:  This seems generally workable.  It avoids issues with
management of subscriptions, etc. by its at-most-once
notification semantics.  (It's at-most-once in that notifications
aren't guaranteed;  the origin server may provide data to feed
cache age and freshness calculations, and the client / proxy must
use its own heuristics to determine whether to trust a cached
object in the absense of a notification.)  The net effect is the
same as (1) in that clients receive state change notifications
for particular objects.  *** It also partially addresses Lucas'
concern about state-leakage, in much the same manner that Lucas
suggested;  a notification client need only support the NOTIFY
method.  Responses to NOTIFY aren't described, but presumably a
reasonable set of responses could be specified so that extra
state isn't leaked in response to a NOTIFY. ***  It also, as Alex
notes, avoids complications with overloading the semantics of
i.e. POST.

CONS:  As noted in [1], any point-to-point notification protocol
suffers when there are a large number of parties interested in
receiving notifications;  the draft explicitly states that
"clients should not attempt to use this facility as a matter of
course" for that reason.  IMO, we're no better or worse off in
this regard with either [1] or HttpEvents as contemplated.  There
are some problems with this draft, such as the lack of fully
qualifying the URI in the NOTIFY message --- how does the
notification client know what the notification relates to?  Also,
the terminology is very proxy specific.  It doesn't reify the
notion of a subscription, but given a one-shot semantics I'm not
sure this is necessary or even desirable. (!) :-/

TANGENTIAL ISSUES
------------------------

Most of the notification application scenarios I've been
contemplating are actually made simpler by simply recasting them
in terms of proxy cache invalidation and assuming something like
the above.  This does *not* specify any state replication /
update by piggybacking the NOTIFY, nor does it address the issue
of fan-out.  It also doesn't address the issue of proxy fan-out,
where a *request* to an intermediary needs to be fanned out to
multiple origin servers, but that's a completely different topic
and scenario.




[1]  http://www.w3.org/TR/WD-proxy










-----------------------------------------------------------------------------------
Post ID:592
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-02 03:59:48
Subject:What's Wrong With HTTP (and Why It Doesn't Matter)
Message:

Good food for thought...  going back through old bookmarks, came
across this talk by Jeffrey Mogul from USENIX '98.  Interesting
POV on many things, not sure about some of the conclusions (i.e.,

the "not the only game in town" is / was definitely an academic
point
of view disconnected with commercial reality.)

    http://www.usenix.org/events/usenix99/invited_talks/mogul.pdf

jb










-----------------------------------------------------------------------------------
Post ID:593
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-02 04:58:05
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

> What does it mean to POST to an HTML file? It isn't meaningful. It /might/
> be meaningful if you craft a server to do something - but then so would
> NOTIFY.

You don't POST to an HTML file, you post to a resource represented by
an HTML file.  If that resource is mailing list, then POSTing adds a
new message to it.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:594
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-02 13:44:41
Subject:Re: [rest-discuss] HttpEvents as currently contemplated are extraneous?
Message:

Jeff Bone wrote:
> 
>...
> 
> CURRENT CONSENSUS:  An HttpEvents protocol could be any one of or
> combination of things.  It might be (1) simply a state-change
> notification protocol, (2) a push-based state replication
> protocol, or (3) a subscription / listener management protocol.
> It appears that we are generally converging on (1), viewing (2)
> as either an optimization or application-specific or both, and
> (3) as interesting but somewhat out-of-scope for this spec.  (We
> are talking about reifying subscribers and subscriptions, but
> pushing out "listener management" etc.)

You should separate listener management and subscription management. The
latter is in scope because it is part of the relationship between
publisher and subscriber. The former is not.

> If so, then we may be spinning our wheels somewhat; various folks
> did a fair bit of work on NOTIFY back in the early days [1] in
> the context of proxy cache notification and in the course of the
> HTTP-NG discussions.  Not sure what the current state of NOTIFY
> is;  did it ever go anywhere?  I apologize if there's an obvious
> answer to this, as my own "cache" of HTTP caching-related
> information is a bit stale.  No mention of NOTIFY / this draft in
> Ari's 1998 book, and very little I can find via Google.

Mnot seems to think it is still a very open issue. (btw, we could have
been more forthcoming with comments on his spec):

 * http://groups.yahoo.com/group/rest-discuss/message/292

Following some links he's provided, I'd say it is still under active
standardization. 

>...
>...
> CONS:  As noted in [1], any point-to-point notification protocol
> suffers when there are a large number of parties interested in
> receiving notifications;  the draft explicitly states that
> "clients should not attempt to use this facility as a matter of
> course" for that reason.  IMO, we're no better or worse off in
> this regard with either [1] or HttpEvents as contemplated.  

First, it isn't sufficient to say: "Their spec doesn't scale but ours
doesn't either."

Second, I think that a subscription based spec is more amenable to
optimization. If the publisher pushes enough information to the client
that the client is "happy" then there is no need for a GET which avoids
a GET-flood. I would expect this to be the common case.

Consider implementing a chat program using only GETs and cache
invalidation. You would double the latency, bandwidth usage etc.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:595
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-02 16:47:46
Subject:RE: [rest-discuss] Expiration
Message:

I like max-age.  Suggest adding an expiration type of Date-relative.  

> -----Original Message-----
> From: S. Mike Dierken [mailto:mdierken@...]
> Sent: Friday, February 01, 2002 12:28 PM
> To: Rest-Discuss; Lucas Gonze
> Subject: Re: [rest-discuss] Expiration
> 
> 
> 
> ----- Original Message -----
> From: "Lucas Gonze" <lucas@...>
> >
> > * The prefix "Requested-" is redundant.  Better wording would be
> > "Expiration-Date" and "Expiration-Count".
> Would 'max-age' (as applied to the messages) be relevant?
> Also, how would you ask for messages from the past (if you had a system with
> an 'audit trail'/history)?
> The KnowNow stuff has a max-age parameter when creating a subscription, but
> I haven't followed this 'expiration' discussion, so it might not be
> relevant.
> 
> 
> 
> 






-----------------------------------------------------------------------------------
Post ID:596
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-02 17:01:02
Subject:RE: [rest-discuss] HttpEvents as currently contemplated are extraneous?
Message:

I find your comments here extremely sensible, parsimonious, etc, and register a
strong +1 for many if not all features of WD-Proxy.  More detailed comments
follow, but without having read the WD-Proxy spec in detail yet.

Proxies
=======

A proxy oriented approach has been a ghost in the backround of these
conversations all along.  I have stayed away from it because whenever I try to
model the actual interactions using proxies I find an awkward fit in using
proxies to do active work.  The syntax of a request to a proxy is slightly
different than the syntax of a request to a normal host.  As a result the end
application can't be a CGI script.  I don't advocate that implementations should
only ever be CGI, but rather that it must be possible for implementations to be
CGI.  I advocate this because of the huge boost to adoption that CGI enables --
the backdoor is often the only door for new technology.

Now, there's a question of whether most servers will accept a proxy request
where the Host: header is their own domain.  I tested this just now by setting
my proxy server to yahoo.com and requesting http://www.yahoo.com.  When I set my
proxy as a user preference in Opera, I got back a 200 OK but no content.  When I
set Opera to use Muffin as a proxy, then set Muffin to use Yahoo as a proxy,
then requested yahoo.com (as well as hotmail.com) I got successful test results.
...inconclusive, obviously.  A question: to what degree is a request to a proxy
a legal request to an endpoint server?

A really great reason to use a proxy approach is that proxies can already handle
the request-in-request pattern.

One-shots
=========

I haven't been able to think of a problem with one-shot notifications, and I
have been able to think of advantages.  So I am a strong +1 for this.

NOTIFY method
=============

I am strongly against new methods.  For one, they're about as un-REST as you can
get.  For another, they make adoption a long, slow, painful process.  Any design
that requires new methods will be adopted at tenth the pace of one that doesn't.
If the HTTP Events spec ends up requiring new methods, I will almost certainly
fork and make a version that enables implementations to avoid new methods.

WD-proxy uses an orthogonal header for the request:
proxy-option= "notify" | "loging" | log

This is a really good solution.  Any other approach requires the request to
contain both a request method and a watched resource method.  That's r-i-r, and
whenever I see r-i-r I see a problematic solution.  ...R-i-r is something like
an infinity -- whenever a design leads you to an infinity you should question
your approach.  It's not that RIR is evil, just that it's best avoided until
somebody does a careful analysis/cookbook for making it work.

> So just finished an afternoon reread of Ari Luotonen's book,
> hadn't looked at it in a couple of years;

which book, Jeff?

> also some material
> online.  I've *almost* convinced myself that HttpEvents as we are
> currently discussing them are mostly extraneous.  I'm going to
> say some things about my understanding of the current very rough
> but gradually converging consensus, then lay out the strawman for
> why this approach is unnecessary.  It's a straw man, whack away.

*whack* *whack*  :)

IMO WD-proxy is good but not quite there.  Let's finish the job --
http://www.janeylee.com/oldhome/mmbattle.au !!!!!

- Lucas







-----------------------------------------------------------------------------------
Post ID:597
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-02 17:49:20
Subject:Re: [rest-discuss] HttpEvents as currently contemplated are extraneous?
Message:


Paul Prescod wrote:

> You should separate listener management and subscription management. The
> latter is in scope because it is part of the relationship between
> publisher and subscriber. The former is not.

Fair enough.

> First, it isn't sufficient to say: "Their spec doesn't scale but ours
> doesn't either."

I'm not sure why not. ;-)  Point being, there are still some serious things
to think about with both -wrt- scaling.   IMO, in order to get scale we're
going to have to do one of two things, one trivial, one hard.  The trivial
solution is to leave it up to the origin server to stop accepting requests
for state notification at whatever level that server thinks is its scaling
limit and / or manage generation of notifications at an appropriate rate.
The hard solution is to figure out how to fan out that notification from the
origin server through an arbitrary number of intermediaries.

> Second, I think that a subscription based spec is more amenable to
> optimization. If the publisher pushes enough information to the client
> that the client is "happy" then there is no need for a GET which avoids
> a GET-flood. I would expect this to be the common case.

Quite possibly, but it seems this is both an optimization and, it would seem,
compatible with the basic idea.  (The basic idea is that rather than
long-lived subscriptions that have to be managed you instead use traditional
cache age / freshness heuristics and an at-most-once or one-shot invalidation
notification.)

Second, it's important to note that the mechanism for scaling and balance is
*better understood* in a GET + one-shot invalidation scenario than in a pure
push scenario.  The origin server can avoid GET storms by simply interleaving
invalidation notifications with servicing the correspondig GETs, no

> Consider implementing a chat program using only GETs and cache
> invalidation. You would double the latency, bandwidth usage etc.

The more I think about it, the more convinced I am that this type of app is
most suited for a long-running GET rather than either fine-grained events
with state or cache invalidation.

jb








-----------------------------------------------------------------------------------
Post ID:598
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-02 18:09:38
Subject:Re: [rest-discuss] HttpEvents as currently contemplated are extraneous?
Message:


Lucas Gonze wrote:

> A proxy oriented approach has been a ghost in the backround of these
> conversations all along.  I have stayed away from it because whenever I try to
> model the actual interactions using proxies I find an awkward fit in using
> proxies to do active work.  The syntax of a request to a proxy is slightly
> different than the syntax of a request to a normal host.

BTW, if it wasn't clear, I wasn't actually suggesting that using an actual
intermediary in this capacity.  Rather, I was suggesting that something like
WD-Proxy's notification scheme be generalized so that the notification receiver is
topology-independent;  every Web application can in some sense be viewed as a
"cache" for representations elsewhere, and the problem of maintaining current state
in that cache can be aided by active cache invalidation.

> As a result the end
> application can't be a CGI script.  I don't advocate that implementations should
> only ever be CGI, but rather that it must be possible for implementations to be
> CGI.  I advocate this because of the huge boost to adoption that CGI enables --
> the backdoor is often the only door for new technology.

Hmmm.  Does it really matter?  After all, all we're doing is sending a message back
to the client that says "come and get it again."  There's no reason "it" can't be a
CGI. Is there?  Clearly, we can't cache POST results, but...  (btw, thinking about
this using the proxy / cache control terminology does confuse the issue.  You're not
really proxying if you make the request yourself, obviously, and you're not really
caching something if you get it, look at it / use it for something, then toss it.)

> One-shots
> =========
>
> I haven't been able to think of a problem with one-shot notifications, and I
> have been able to think of advantages.  So I am a strong +1 for this.

This IMO is the real meat of the deal.  I think it's HUGELY advantageous.

> NOTIFY method
> =============
>
> I am strongly against new methods.  For one, they're about as un-REST as you can
> get.  For another, they make adoption a long, slow, painful process.  Any design
> that requires new methods will be adopted at tenth the pace of one that doesn't.
> If the HTTP Events spec ends up requiring new methods, I will almost certainly
> fork and make a version that enables implementations to avoid new methods.

In general I agree.  There are some "pros," though.  I thought you'd like this, as
it does allow client implementations to support a *very* minimal protocol --- they
only need to accept NOTIFY on port 80.  IMO, that's cleaner than overloading
standard HTTP method (GET) and using an older and much laxer version of the HTTP
spec.

> WD-proxy uses an orthogonal header for the request:
> proxy-option= "notify" | "loging" | log
>
> This is a really good solution.

I think you need to read the spec, I don't think it does what you think. ;-)

> > So just finished an afternoon reread of Ari Luotonen's book,
> > hadn't looked at it in a couple of years;
>
> which book, Jeff?

Ari was head of server development at CERN back in the day, then ran proxy
development at Netscape.  His book "Web Proxy Servers" [1] is one of the classics;
it was released in about '98.  A lot of the information is now out of date, but it's
still worth a read.  Note that it doesn't talk about WD-Proxy, but it does have a
great explanation of the various age / freshness tradeoffs and algorithms.

jb

[1] http://www.amazon.com/exec/obidos/ASIN/0136806120/







-----------------------------------------------------------------------------------
Post ID:599
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-02 21:30:42
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

> ----- Original Message ----- 
> From: "S. Alexander Jacobson" <alex@...>
> > 
> 
> > PS My gut also says that NOTIFY really means
> > something quite distinct from POST.  In
> > particular, POST says something about a resource
> > is to be changed in some way.  NOTIFY signals that
> > the change has already happened.
> 
> I agree.

I don't.  The resource identified by the callback URI can be whatever
the subscriber wants it to be.  If it's a semaphore, then PUT or POST
is fine.  If it's a mailbox, then POST is good.  I dare you to try and
choose a resource that's used to receive notifications that can't
receive them with PUT or POST.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:600
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-02 22:41:35
Subject:Re: [rest-discuss] HttpEvents as currently contemplated are extraneous?
Message:

I think we are converging on your (1), state-
change-notification/cache-invalidation.  I also
am beginning to think that this whole discussion
is extraneous; that people who want
notification should just use persistent GET.

The main argument against persistent GET for
notification is that clients and servers are
forced to hold open potentially large numbers of
TCP connections (and this is expensive).

However:
1. There is no evidence that open TCP connections
really consume that many more resources than
subscriptions.  The only difference is that
OSs typically don't allow TPC connections to be
stored on disk, but I don't think that is
something we need be concerned with.  (I could
imagine unused connections being swapped to
virtual memory (or people can just buy more
memory).

2. Holding open a persistent GET consumes less
bandwidth than establishing two HTTP connections
and sending NOTIFY in one reuest and a repeat of
the actual content in the other.

3. Persistent GET is much more in the spirit of
HTTP than asynchronous notifications.

I think, unless you can make a good argument
against Persistent GET, there is no real need
for the HttpEvents spec.

That being said, it might be useful to establish a
standard format for this Persistent GET for cache
invalidation or for replication or for security
monitoring, but I don't see any value in
HttpEvents that persistent GET does not
better provide.

-Alex-




On Fri, 1 Feb 2002, Jeff Bone wrote:

>
> So just finished an afternoon reread of Ari Luotonen's book,
> hadn't looked at it in a couple of years;  also some material
> online.  I've *almost* convinced myself that HttpEvents as we are
> currently discussing them are mostly extraneous.  I'm going to
> say some things about my understanding of the current very rough
> but gradually converging consensus, then lay out the strawman for
> why this approach is unnecessary.  It's a straw man, whack away.
>
> CURRENT CONSENSUS:  An HttpEvents protocol could be any one of or
> combination of things.  It might be (1) simply a state-change
> notification protocol, (2) a push-based state replication
> protocol, or (3) a subscription / listener management protocol.
> It appears that we are generally converging on (1), viewing (2)
> as either an optimization or application-specific or both, and
> (3) as interesting but somewhat out-of-scope for this spec.  (We
> are talking about reifying subscribers and subscriptions, but
> pushing out "listener management" etc.)
>
> Is that about right?
>
> If so, then we may be spinning our wheels somewhat; various folks
> did a fair bit of work on NOTIFY back in the early days [1] in
> the context of proxy cache notification and in the course of the
> HTTP-NG discussions.  Not sure what the current state of NOTIFY
> is;  did it ever go anywhere?  I apologize if there's an obvious
> answer to this, as my own "cache" of HTTP caching-related
> information is a bit stale.  No mention of NOTIFY / this draft in
> Ari's 1998 book, and very little I can find via Google.
>
> BUT...
>
> [1] describes a protocol extension (with a "new" method, NOTIFY)
> that solves (1) in a very HTTPish way.  It doesn't reify
> subscriptions, but it doesn't have to --- it appears that
> subscriptions are at-most-once commitments to notify the
> subscriber that the state of a resource has changed, for the
> purpose of cache invalidation.  Renewal of the subscription
> appears to happen incrementally --- the subscription "expires"
> after the first notification, and is "renewed" on the subsequent
> GET (if any) that happens to refresh the cache after the
> notification is received.
>
> The more I think about this, the more elegant it seems.
>
> Here's how this protocol could be used to accomplish (1):
>
> CLIENT -> SERVER
> ----------------------
> GET /foo HTTP/1.1
> Accept: text/html
> Proxy-Features: my.host.com; notify
>
> (Note that we're "pretending" to be our own proxy server cache.
> We're requesting notification of state change on the resource if
> it's available.)
>
> SERVER -> CLIENT
> ---------------------
> 201 OK
> Cache-Control: notify
> Content-Type: text/html
>
> ...text...
>
> (The SERVER responds and says, among other things, that it is
> willing to notify (via the Cache-Control directive) the CLIENT
> at-most-once (?) that the resource has changed by possibly
> emitting a NOTIFY for that resource to the CLIENT at some later
> date.)
>
> Later on, when /foo changes, the SERVER initiates a connection
> back to CLIENT (the machine specified in Proxy-Features:, i.e.
> my.host.com) and sends notification that the state change
> occurred / the cached copy (if any) has expired:
>
> SERVER -> CLIENT
> ---------------------
> NOTIFY /foo HTTP/1.1
>
> (Presumably the fully-qualified URI is somehow reconstructed from
> TCP connection data.  This is gross and unworkable, so I would
> assume that instead NOTIFY is required to provide a
> fully-qualified URI.)
>
> The client CLIENT proceed to refresh its cache via a GET.  At
> this point, the SERVER is presumably allowed to stop sending
> further notifications;  in order to receive the next
> notification, the client parameterizes the GET so that it looks
> just like the first one.  This cycle repeats, ad infinitum, as
> long as the CLIENT is interested in being updated about state
> changes on SERVER/foo:
>
> CLIENT -> SERVER
> ----------------------
> GET /foo HTTP/1.1
> Accept: text/html
> Proxy-Features: my.host.com; notify
>
> ...lather, rinse, repeat...
>
> DISCUSSION
> --------------
>
> PROS:  This seems generally workable.  It avoids issues with
> management of subscriptions, etc. by its at-most-once
> notification semantics.  (It's at-most-once in that notifications
> aren't guaranteed;  the origin server may provide data to feed
> cache age and freshness calculations, and the client / proxy must
> use its own heuristics to determine whether to trust a cached
> object in the absense of a notification.)  The net effect is the
> same as (1) in that clients receive state change notifications
> for particular objects.  *** It also partially addresses Lucas'
> concern about state-leakage, in much the same manner that Lucas
> suggested;  a notification client need only support the NOTIFY
> method.  Responses to NOTIFY aren't described, but presumably a
> reasonable set of responses could be specified so that extra
> state isn't leaked in response to a NOTIFY. ***  It also, as Alex
> notes, avoids complications with overloading the semantics of
> i.e. POST.
>
> CONS:  As noted in [1], any point-to-point notification protocol
> suffers when there are a large number of parties interested in
> receiving notifications;  the draft explicitly states that
> "clients should not attempt to use this facility as a matter of
> course" for that reason.  IMO, we're no better or worse off in
> this regard with either [1] or HttpEvents as contemplated.  There
> are some problems with this draft, such as the lack of fully
> qualifying the URI in the NOTIFY message --- how does the
> notification client know what the notification relates to?  Also,
> the terminology is very proxy specific.  It doesn't reify the
> notion of a subscription, but given a one-shot semantics I'm not
> sure this is necessary or even desirable. (!) :-/
>
> TANGENTIAL ISSUES
> ------------------------
>
> Most of the notification application scenarios I've been
> contemplating are actually made simpler by simply recasting them
> in terms of proxy cache invalidation and assuming something like
> the above.  This does *not* specify any state replication /
> update by piggybacking the NOTIFY, nor does it address the issue
> of fan-out.  It also doesn't address the issue of proxy fan-out,
> where a *request* to an intermediary needs to be fanned out to
> multiple origin servers, but that's a completely different topic
> and scenario.
>
>
>
>
> [1]  http://www.w3.org/TR/WD-proxy
>
>
>
>
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax









-----------------------------------------------------------------------------------
Post ID:601
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-02 23:08:45
Subject:RE: [rest-discuss] HttpEvents as currently contemplated are extraneous?
Message:

per Alex:
> The main argument against persistent GET for
> notification is that clients and servers are
> forced to hold open potentially large numbers of
> TCP connections (and this is expensive).

...

> I think, unless you can make a good argument
> against Persistent GET, there is no real need
> for the HttpEvents spec.

Edges are able to receive email events from a very large number of people --
persistent GET with all of them is not doable on any machine ever built, much
less a desktop machine.  It would amount to an NxN matrix of open connections
between every possible sender/recipient pair.

Ok, ok, I realize that you were talking about persistent GET between edge nodes
and server-class sponsor machines.  :)  a couple problems with this approach:
* Many people own perfectly capable desktop machines with good connectivity.
For them to pay someone else to sponsor their connections is a waste.
* The servers at the center of a persistent-GET topography would still need
notifications.  The persistent GET at the last mile wouldn't have anything to
persistently GET otherwise.

That said, I agree that persistent GET is the one solution for nodes behind
firewalls.  ...both persistent GET and http notifications are needed.

> That being said, it might be useful to establish a
> standard format for this Persistent GET for cache
> invalidation or for replication or for security
> monitoring,

This would be a useful project, assuming that KnowNow's format isn't already
there, and even if KN is already there it would still be productive to send
their stuff through the standards process.

- Lucas











-----------------------------------------------------------------------------------
Post ID:602
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 00:00:24
Subject:RE: [rest-discuss] HttpEvents as currently contemplated are extraneous?
Message:

I think that persistent GET, http notifications, and http updates are
complementary projects.  Hopefully people working on these can find *cough*
synergies.








-----------------------------------------------------------------------------------
Post ID:603
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 00:10:03
Subject:RE: [rest-discuss] HttpEvents as currently contemplated are extraneous?
Message:

On Sat, 2 Feb 2002, Lucas Gonze wrote:
> Edges are able to receive email events from a very large number of people --
> persistent GET with all of them is not doable on any machine ever built, much
> less a desktop machine.  It would amount to an NxN matrix of open connections
> between every possible sender/recipient pair.

Just to be clear, we are talking about
subscriptions not email.

Recipients need only recieve events from the
places to which they subscribe.

Servers need only handle as many connections as
they have subsciptions.

Recipients dont' subscribe to all servers
and servers don't have subscriptions from all
possible recipients.

So persistent GET does NOT result in an NxM
connection matrix.

> * Many people own perfectly capable desktop machines with good connectivity.
> For them to pay someone else to sponsor their connections is a waste.

Why would they pay someone else?  Why not just
open connections to the relevent servers whenever
they connect?  Edge class machines probably won't
have too many subscriptions in any case.

> * The servers at the center of a persistent-GET topography would still need
> notifications.  The persistent GET at the last mile wouldn't have anything to
> persistently GET otherwise.

Why?  The server exposes a URL that represents
the stream of notification messages.

> That said, I agree that persistent GET is the one solution for nodes behind
> firewalls.  ...both persistent GET and http notifications are needed.

Again, I don't see why.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:604
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 00:12:33
Subject:RE: [rest-discuss] HttpEvents as currently contemplated are extraneous?
Message:

I don't think there is a coherent generic http
update spec.

As I said, I don't see the justification for
http notification.

The only thing that makes sense is various
protocols that run over persistent GET.

-Alex-

On Sat, 2 Feb 2002, Lucas Gonze wrote:

> I think that persistent GET, http notifications, and http updates are
> complementary projects.  Hopefully people working on these can find *cough*
> synergies.
>
>
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:605
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 00:22:11
Subject:WD-proxy
Message:

> BTW, if it wasn't clear, I wasn't actually suggesting that using an actual
> intermediary in this capacity.  Rather, I was suggesting that something like
> WD-Proxy's notification scheme be generalized so that the
> notification receiver is
> topology-independent;

Got it.  That's an important distinction.

> Hmmm.  Does it really matter?  After all, all we're doing is sending
> a message back
> to the client that says "come and get it again."  There's no reason
> "it" can't be a
> CGI. Is there?

-- Just to clarify, I was thinking about the source side of things rather than
the sink side.

> > One-shots
> > =========
> >
> > I haven't been able to think of a problem with one-shot notifications, and I
> > have been able to think of advantages.  So I am a strong +1 for this.
>
> This IMO is the real meat of the deal.  I think it's HUGELY advantageous.

Is anybody on the list against one-shot notifications?  Are there disadvantages
not seen here?  Speak now or hold your peace.

I think that multiple-shot notifications are a sloppy way of introducing more
information into the channel, so they're really a form of updates.  For example
you might use multiple shot notifications on an email account to allow the
client to count the number of unread messages.  That's useful, but flawed enough
that I'd leave equivalent functionality to any http-updates project that may
happen.  Keep the scope of hEvents minimal enough to do a good job, and
hopefully lay the groundwork for related projects like persistent GET and
http-updates.


> In general I agree.  There are some "pros," though.  I thought you'd
> like this, as
> it does allow client implementations to support a *very* minimal
> protocol --- they
> only need to accept NOTIFY on port 80.  IMO, that's cleaner than overloading
> standard HTTP method (GET) and using an older and much laxer version
> of the HTTP
> spec.

Uh, pretty much _anything_ is cleaner than that.  Actually, I've been thinking
about PSP as two separate things munged together - a "mole" communications
pattern and idempotent notifications.  The mole pattern is that one party, a
requester, has almost total control over the communications stream.  The mole
pattern has to use idempotent notifications, but idempotent notifications don't
have to use the mole pattern.

> > which book, Jeff?
>
> Ari was head of server development at CERN back in the day, then ran proxy
> development at Netscape.  His book "Web Proxy Servers" [1] is one of
> the classics;
> it was released in about '98.  A lot of the information is now out of
> date, but it's
> still worth a read.  Note that it doesn't talk about WD-Proxy, but it
> does have a
> great explanation of the various age / freshness tradeoffs and algorithms.
>

Oh, yeah, I remember that I was excited when it came out but slacked on actually
getting it....







-----------------------------------------------------------------------------------
Post ID:606
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 00:32:10
Subject:RE: [rest-discuss] HttpEvents as currently contemplated are extraneous?
Message:

> I don't think there is a coherent generic http
> update spec.

Yeah, I was just thinking out loud about long term directions.  There's no doubt
in my mind that full-scale callbacks using HTTP for state replication are
needed -- stuff like Mike D's "DELETED" flag and Paul's original "DIFF" callback
argument.  Idempotent notifications are way too limited in scope to do
everything needed.  They do one thing well, but that's all.







-----------------------------------------------------------------------------------
Post ID:607
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-03 01:58:15
Subject:Re: [rest-discuss] HttpEvents as currently contemplated are extraneous?
Message:

Another issue is that there is no "persistent GET".  HTTP 1.1 assumes
persistent connections by default, but that's not the same as assuming a
streaming response returning notifications of state updates.  You still
need a way for the user to request these updates.

KnowNow does this because all their URIs are topics that behave in a
particular way.  But that's not the case for an arbitrary URI.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:608
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 04:02:53
Subject:RE: [rest-discuss] Expiration
Message:

Per Jeff's suggestion that notifications be one-shot firings that get renewed
when the requester phones in to pick up the resource, much of the expiration
language can go away.  However there may still be a need to state the period of
time in which a requester wants to receive that one notification.  For example,
an expiration date in the request and/or response.

Since this is a minor issue I don't want to get bogged down in it.  Here are the
options:
1) no expiration date
2) expiration specified by requester and either accepted or denied by the
responder.
3) hoped-for expiration sent in request and actual expiration sent in response.

I lean towards #1 but don't have strong feelings.  #3 is really not bad either.

There is a secondary issue, even more trivial than the first, which is what the
status code should be in the case of #2 above when the responder denies a
request based on expiration field value in the request.  I propose a new status
code, 418 "Requested expiration unacceptable."  I can't think of any damage this
would cause, and extension codes are acceptable within the RFC.  The reason to
have a new status code is to allow clients to diagnose and repair the error.

The best reason to support #1 is that expiration is irrelevant nit picking at
this early stage, and just introduces complication.

In the interest of finishing with this not very interesting feature, up or down
votes for any of the above would be appreciated.








-----------------------------------------------------------------------------------
Post ID:609
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-03 07:17:36
Subject:One-shot notifications
Message:

I do like the fact that one-shot notifications simplify subscription
management out of existence. I haven't thought through all of the
issues, but
 I'm worried about scalability and robustness.

 1. it must be possible to be able to piggy-back resources (and/or
deltas?) in notifications

 2. it must be possible to re-subscribe in the response to a
notification

 3. the last point implies that the server must tell the client in the
notification that it is "pre-authorized" for re-subscription.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:610
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-03 07:18:07
Subject:NOTIFY
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> > I believe this to be the case.  Whether or not a particular resource supports a particular
> > method should be an authorization concern, not an interface concern.
> 
> How do you explain the differences between:

These three are authorization issues (with the last being the most
precise):

> 401 Unauthorized
> 403 Forbidden
> 405 Method Not Allowed

These are implementation issues:

> 501 Not Implemented
> 503 Service Unavailable
> 
> It certainly seems like the HTTP spec contemplates
> new non-universal methods.

The point isn't that the methods should be universal but that they be
logically *generic*, not *specific* to a particular type of resource.
You can PUT web pages, purchase orders, user IDs, shopping carts, and
any other logical kind of thing. You can GET them. You can DELETE them.
And you can extend them with POST. (as usual the definition of POST is
more fuzzy than the others)

If we make a new method NOTIFY, then it should also apply to web pages,
purchase orders, user IDs, shopping carts, etc. Does that make sense?
Maybe.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:611
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 05:24:19
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Sat, 2 Feb 2002, Mark Baker wrote:
> I don't.  The resource identified by the callback URI can be whatever
> the subscriber wants it to be.  If it's a semaphore, then PUT or POST
> is fine.  If it's a mailbox, then POST is good.  I dare you to try and
> choose a resource that's used to receive notifications that can't
> receive them with PUT or POST.

As I said this is really a gut level issue, but I
think at very least you cannot use PUT.
PUT is supposedly idempotent. That means that the
result of two PUTs is the same as the result of
one PUT.

I don't think that is true of notifications.
In particular, do two notifications mean that the
original object changed once or that it changed
twice?  So the semantics of PUT are definitely
wrong for notification.

You obviously can use POST.  But that is because
POST has no meaning at all.  It is used for
queries (terroristornot.com), it is used for
updates, it is even used to delete sometimes.
Often POST actually results in the creation of
new resources (e.g. adding stuff to a shopping
basket).

The choice of POST or NOTIFY boil down to how
you distinguish between changing the behavior of
a listener and interacting with it.
There are three choices:
1. Use POST and define special content like a
mime-header or body.  This interferes with
allowing arbitrary local management of listeners.
2. Use NOTIFY
3. Use a different URL for notification and
listener management -- this is very non RESTy.

All that being said, I don't, at this point, see a
need for anything other than persistant GET.  So
this is all sort of moot.

-Alex-


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax









-----------------------------------------------------------------------------------
Post ID:612
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 05:48:04
Subject:GET Events Protocol (was HttpEvents as currently contemplated are extraneous)
Message:

On Sat, 2 Feb 2002, Mark Baker wrote:
> Another issue is that there is no "persistent GET".  HTTP 1.1 assumes
> persistent connections by default, but that's not the same as assuming a
> streaming response returning notifications of state updates.  You still
> need a way for the user to request these updates.

Thats fine, I think.  If you offer notification,
you create URLs which represent the stream of
changes to some other URL (or collection of URLs).
The recipient then gets a chunk encoded stream of
update messages.

> KnowNow does this because all their URIs are topics that behave in a
> particular way.  But that's not the case for an arbitrary URI.

Basically the "topic" is the set of changes to a
URL.

Here is what I think the GET Events Protocol
looks like:

1. The client PUTs a list of URLs on which it
wants notification to some location.  (The client
may want to GET this list later and make changes).

2. The server replies CREATED and sends back a
location header with a notification URL at which
the client can recieve the notifications it just
requested.

3. The client GETs this notification URL.

4. The server sends a mime multipart
   with each part being either:
   * the new contents of each URL together with a
     content-location header telling the client
     the URL from which this data originates
   -or-
   * a message of content-type:
     message/external-body; access-type="URL"
     and the URL that changed.
   -or-
   * a message of content-type application/x-diff
   (The content is some representation of just
    the diff that the recipient can use to
    recreate the original)

-Alex-



___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:613
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 05:49:47
Subject:RE: [rest-discuss] Expiration
Message:

You don't need expiration if you use GET.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:614
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 05:50:52
Subject:RE: [rest-discuss] Re: Summarization on notifications?
Message:

> As I said this is really a gut level issue, but I
> think at very least you cannot use PUT.
> PUT is supposedly idempotent. That means that the
> result of two PUTs is the same as the result of
> one PUT.
>
> I don't think that is true of notifications.
> In particular, do two notifications mean that the
> original object changed once or that it changed
> twice?  So the semantics of PUT are definitely
> wrong for notification.

The notification doesn't say whether the resource changed once or twice.  It
only means that the watched resource has a new state since the subscription was
created.

This is exactly the difference between updates and notifications.  An update is
for synchronization -- it tells you about the new state.  A notification is for
invalidation -- it tells you there is a new state.








-----------------------------------------------------------------------------------
Post ID:615
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 05:54:14
Subject:Re: [rest-discuss] NOTIFY
Message:

On Sat, 2 Feb 2002, Paul Prescod wrote:
> The point isn't that the methods should be universal but that they be
> logically *generic*, not *specific* to a particular type of resource.
> You can PUT web pages, purchase orders, user IDs, shopping carts, and
> any other logical kind of thing. You can GET them. You can DELETE them.
> And you can extend them with POST. (as usual the definition of POST is
> more fuzzy than the others)

Ok. The *generic* semantics of NOTIFY is to tell
the server that the resource is now out-of-date.
This is generic to all resources.  Whether the
server knows or cares to resolve the situation is
an entirely separate question.

This is very different from POST which tells the
server that the target URL should change in some
manner.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:616
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-03 05:57:54
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

> I don't think that is true of notifications.
> In particular, do two notifications mean that the
> original object changed once or that it changed
> twice?  So the semantics of PUT are definitely
> wrong for notification.

So treat it as a semaphore; a resource that represents my interest in
the resource.  If it's "0", then I don't care.  If it's "1", then I do
care, and I'll go off and do my thing, then set it back to "0".  That's
all PUT.

> You obviously can use POST.  But that is because
> POST has no meaning at all.  It is used for
> queries (terroristornot.com), it is used for
> updates, it is even used to delete sometimes.
> Often POST actually results in the creation of
> new resources (e.g. adding stuff to a shopping
> basket).

I'm not singling you out here Alex, because others have said it, but
POST has a *very* precise meaning.  It's not fuzzy at all.  All that's
fuzzy is the implementation details of what it means for the POSTed
thing to be processed.  But that's implementation, not interface.
The interface is quite clear.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:617
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 05:58:32
Subject:RE: [rest-discuss] Re: Summarization on notifications?
Message:

On Sun, 3 Feb 2002, Lucas Gonze wrote:
> The notification doesn't say whether the resource changed once or twice.  It
> only means that the watched resource has a new state since the subscription was
> created.

Actually I now think it says even less.  It says
only that the resource is now out-of-date.  The
server may or may not know how to resolve the
situation (e.g. it may retrieve the URL or it may
tell someone else to deal with it)

Either way telling the server that a resource is
out-of-date is very different from using POST
or PUT to change it.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:618
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 06:02:02
Subject:RE: [rest-discuss] Re: Summarization on notifications?
Message:

> On Sun, 3 Feb 2002, Lucas Gonze wrote:
> > The notification doesn't say whether the resource changed once or twice.  It
> > only means that the watched resource has a new state since the
> subscription was
> > created.
>
> Actually I now think it says even less.  It says
> only that the resource is now out-of-date.  The
> server may or may not know how to resolve the
> situation (e.g. it may retrieve the URL or it may
> tell someone else to deal with it)
>
> Either way telling the server that a resource is
> out-of-date is very different from using POST
> or PUT to change it.

That is exactly right.  A notification is not a way of pushing resources from
source to sink.  Anything that is about pushing resources from source to sink is
an update.











-----------------------------------------------------------------------------------
Post ID:619
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 06:11:07
Subject:RE: [rest-discuss] One-shot notifications
Message:

> I do like the fact that one-shot notifications simplify subscription
> management out of existence. I haven't thought through all of the
> issues, but
>  I'm worried about scalability and robustness.
>
>  1. it must be possible to be able to piggy-back resources (and/or
> deltas?) in notifications

Need more info here to know what you mean.  In general, if the notification
contains anything but a TRUE value, it's an update.  If the notification is used
to push changed resources, including via deltas, then it is an update.

I am very much for dealing with the need for updates, but not now.  It's an
entire layer of complexity.

>
>  2. it must be possible to re-subscribe in the response to a
> notification

agreed.

>
>  3. the last point implies that the server must tell the client in the
> notification that it is "pre-authorized" for re-subscription.

It seems safe to assume that the sink is pre-authorized to resubscribe often
enough to consider it the default.  Plus it doesn't really cause damage to have
a re-subscribe fail.  So it is parsimonious to leave authorization to the usual
HTTP means, i.e. by having the source return 401 (Unauthorized) when the need
arises to deny a sub request.











-----------------------------------------------------------------------------------
Post ID:620
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-03 07:10:50
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

Mark Baker wrote:

> I'm not singling you out here Alex, because others have said it, but
> POST has a *very* precise meaning.  It's not fuzzy at all.  All that's
> fuzzy is the implementation details of what it means for the POSTed
> thing to be processed.  But that's implementation, not interface.
> The interface is quite clear.

This is actually one of the main conceptual innovations of Roy's REST view of
the world --- it's a bit of "defining away the problem," but the
implementation / interface distinction is clean and useful.

Think of it this way, Alex:  on UNIX, we have files that are bit bags and
files that represent active entities such as devices.  We write to each of
them via the same interface, and the interface semantics are the same.  What
happens as a result of that write differs depending on the particular "file."

jb








-----------------------------------------------------------------------------------
Post ID:621
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-03 21:39:50
Subject:Re: [rest-discuss] One-shot notifications
Message:

Lucas Gonze wrote:
> 
> ...
> >
> >  1. it must be possible to be able to piggy-back resources (and/or
> > deltas?) in notifications
> 
> Need more info here to know what you mean.  In general, if the notification
> contains anything but a TRUE value, it's an update.  If the notification is used
> to push changed resources, including via deltas, then it is an update.

I'm trying to make a distinction here between the semantic content of
the message and the literal content. The semantic content is "something
changed." The literal content is often "oh, and by the way, you could do
a GET to fetch it but in order to reduce network load I've inlined the
value here for you. If you would rather ignore the inlined value, go
ahead and do the GET. It's all the same to me."

>...
> >  3. the last point implies that the server must tell the client in the
> > notification that it is "pre-authorized" for re-subscription.
> 
> It seems safe to assume that the sink is pre-authorized to resubscribe often
> enough to consider it the default.  

Sure, the default. But you're just reversing the question. Then the
publisher must be able to tell the subscriber that it is NOT
pre-authorized.

> ... Plus it doesn't really cause damage to have
> a re-subscribe fail.  

I strongly disagree. If I believe that I'm subscribed to a stock ticker
but I'm not really, heads will roll. Resubscription is important!

> ... So it is parsimonious to leave authorization to the usual
> HTTP means, i.e. by having the source return 401 (Unauthorized) when the need
> arises to deny a sub request.

I don't follow. The NOTIFY message has the publisher as the requester
and the client as the receiver. The response to the NOTIFY may have a
header saying: "Please re-subscribe me." Now the server has no
opportunity to report an error because the re-subscription "request" was
in a "response". That's why the server should pre-authorize.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:622
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 18:59:51
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Sun, 3 Feb 2002, Mark Baker wrote:
> I'm not singling you out here Alex, because others have said it, but
> POST has a *very* precise meaning.  It's not fuzzy at all.  All that's
> fuzzy is the implementation details of what it means for the POSTed
> thing to be processed.  But that's implementation, not interface.
> The interface is quite clear.

I was not really trying to attack the meaning of
POST.  My basic point is that using PUT or POST
for notify requires a prior arrangement that the
URL being PUT/POSTed refers to the URL being
invalidated.

However NOTIFY requires no prior arrangement and
no subscription.  It is just a communication from
the client to the server telling the server that
the page is out of date (and that it may want to
do something about it).

If you want to request notification from a server
that is a totally separate protocol.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:623
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 19:02:37
Subject:RE: [rest-discuss] Re: Summarization on notifications?
Message:

On Sun, 3 Feb 2002, Lucas Gonze wrote:
> > Either way telling the server that a resource is
> > out-of-date is very different from using POST
> > or PUT to change it.
>
> That is exactly right.  A notification is not a way of pushing resources from
> source to sink.  Anything that is about pushing resources from source to sink is
> an update.

It also means that we can completely separate
subscription from notification.  NOTIFY is simply
a method telling a server that a resource is out
of date.  The server may or may not know or care
to resolve the situation.

A client might also request that a server NOTIFY
another SERVER under various conditions (a
subscription), but that is a separate protocol.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:624
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 19:10:33
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Sun, 3 Feb 2002, Jeff Bone wrote:
> Think of it this way, Alex:  on UNIX, we have files that are bit bags and
> files that represent active entities such as devices.  We write to each of
> them via the same interface, and the interface semantics are the same.  What
> happens as a result of that write differs depending on the particular "file."

Ok. If we are going to analogize to UNIX.  NOTIFY
is like Make.

If I know that a specific executable is out of
date (or think it might be), I do Make file.
The Make system knows how to check dependencies
and will update the file if necessary.

But the better analogy is that NOTIFY is like
having a Refresh button that works on
arbitrary servers rather than just Browser caches.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:625
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 19:27:06
Subject:Re: [rest-discuss] One-shot notifications
Message:

I don't understand the purpose of the whole
notification scheme.  It seems to have much
complexity and little benefit over the GET Events
protocol I described in (1).

-ALex-

(1) http://groups.yahoo.com/group/rest-discuss/message/612
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax









-----------------------------------------------------------------------------------
Post ID:626
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 19:39:08
Subject:RE: [rest-discuss] One-shot notifications
Message:

It is not complex, it is subtle.  Implementation is trivial.

> 
> I don't understand the purpose of the whole
> notification scheme.  It seems to have much
> complexity and little benefit over the GET Events
> protocol I described in (1).
> 
> -ALex-







-----------------------------------------------------------------------------------
Post ID:627
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 19:45:03
Subject:RE: [rest-discuss] One-shot notifications
Message:

Either way.  It is more expensive than GET events.
With one shot notifications, you continually have
a back request for another subscription.

With GET Events, when you don't want events any
more, you simply close the connection.

-Alex-

On Sun, 3 Feb 2002, Lucas Gonze wrote:

> It is not complex, it is subtle.  Implementation is trivial.
>
> >
> > I don't understand the purpose of the whole
> > notification scheme.  It seems to have much
> > complexity and little benefit over the GET Events
> > protocol I described in (1).
> >
> > -ALex-
>
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:628
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 19:56:44
Subject:RE: [rest-discuss] One-shot notifications
Message:

Yes, the need for back requests in one shot notifications means that they are
too inefficient for some applications.  Just like HTTP/XML/text
encodings/non-kernel applications/etc are too inefficient for some applications.


> Either way.  It is more expensive than GET events.
> With one shot notifications, you continually have
> a back request for another subscription.
>
> With GET Events, when you don't want events any
> more, you simply close the connection.
>
> -Alex-







-----------------------------------------------------------------------------------
Post ID:629
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-03 19:58:28
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:


"S. Alexander Jacobson" wrote:

> On Sun, 3 Feb 2002, Jeff Bone wrote:
> > Think of it this way, Alex:  on UNIX, we have files that are bit bags and
> > files that represent active entities such as devices.  We write to each of
> > them via the same interface, and the interface semantics are the same.  What
> > happens as a result of that write differs depending on the particular "file."
>
> Ok. If we are going to analogize to UNIX.  NOTIFY
> is like Make.
>
> If I know that a specific executable is out of
> date (or think it might be), I do Make file.
> The Make system knows how to check dependencies
> and will update the file if necessary.
>
> But the better analogy is that NOTIFY is like
> having a Refresh button that works on
> arbitrary servers rather than just Browser caches.

Silly rabbit.  NOTIFY is "touch."

jb








-----------------------------------------------------------------------------------
Post ID:630
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 20:08:22
Subject:RE: [rest-discuss] One-shot notifications
Message:

At least with HTTP/XML, you get some bonus in
deployability/flexibility.  With one shot
notifications, you don't.  Worse, with One-shot,
you need a new HTTP method!

The semantics of GET Events are cleaner.  It
is more deployable.  It is more scalable.  And, it
is more consistent with the way the web already
works.

-Alex-

On Sun, 3 Feb 2002, Lucas Gonze wrote:

> Yes, the need for back requests in one shot notifications means that they are
> too inefficient for some applications.  Just like HTTP/XML/text
> encodings/non-kernel applications/etc are too inefficient for some applications.
>
>
> > Either way.  It is more expensive than GET events.
> > With one shot notifications, you continually have
> > a back request for another subscription.
> >
> > With GET Events, when you don't want events any
> > more, you simply close the connection.
> >
> > -Alex-
>
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:631
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 20:14:06
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Sun, 3 Feb 2002, Jeff Bone wrote:
> Silly rabbit.  NOTIFY is "touch."

No because NOTIFY may result in a change in the
thing being notified.  Touch simply causes the
date to change.

E.g. Suppose I go to a web site and think that
a binary is out of date with respect to the
source. I NOTIFY on the URL of the binary and the
server may retrieve the source and recompile IF
the source is more recent than the binary.

The source may be coerced to being more recent
than the binary by touching it.  Touch is
equivalent to using GET/PUT to affect
if-modified-since requests.

NOTIFY tells a server that it might want to make
IMS requests.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:632
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 20:14:44
Subject:RE: [rest-discuss] One-shot notifications
Message:

> At least with HTTP/XML, you get some bonus in
> deployability/flexibility.  With one shot
> notifications, you don't.  Worse, with One-shot,
> you need a new HTTP method!

You do not need a new method.  PUT is perfect.







-----------------------------------------------------------------------------------
Post ID:633
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 20:23:10
Subject:RE: [rest-discuss] One-shot notifications
Message:

PUT is incorrect.
It also requires both endpoints to be HTTP
servers.   GET Events requires only one endpoint
to be a server.

-Alex-

On Sun, 3 Feb 2002, Lucas Gonze wrote:

> > At least with HTTP/XML, you get some bonus in
> > deployability/flexibility.  With one shot
> > notifications, you don't.  Worse, with One-shot,
> > you need a new HTTP method!
>
> You do not need a new method.  PUT is perfect.
>
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:634
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-03 20:20:34
Subject:Different apps have different needs
Message:


"S. Alexander Jacobson" wrote:

> At least with HTTP/XML, you get some bonus in
> deployability/flexibility.  With one shot
> notifications, you don't.  Worse, with One-shot,
> you need a new HTTP method!
>
> The semantics of GET Events are cleaner.  It
> is more deployable.  It is more scalable.  And, it
> is more consistent with the way the web already
> works.

Okay, so here's the conclusion I'm coming to --- all of the various options we've been
discussing are appropriate in different application contexts.  None of them is
universal --- as Paul points out, viewing a chat room as a caching problem is probably
not the right answer, but OTOH presence is *very much* a caching problem.  For a chat
room, you most likely need a "centralized" resource that reifies the room and manages
mux/demux/ordering of arriving messages.  For presence, a resource models a particular
person's status and cache invalidation is appropriate, update an optimization.  For
IM, it's probably the case that a simple POST is appropriate.  (Rollover from IM to
chat is then cleanly handled by a 3xx redirect in response to a POST, with a header
indicating that a long-lived GET on the indicated resource should be established.)
For syndication, cache invalidation is the right option, and update via a pushed state
representation an important optimization.  For Web-based distributed storage, again
cache invalidation is probably the right option.  For stock quote streams, long-lived
GET is probably the right option.  Etc., etc., etc.

Long-lived GET is appropriate in two contexts:  first, where the problem you're
actually solving is the asymmetry of connectivity on the Web, and then long-lived GET
only solves half the problem, and that rather poorly.  Second, when the resource model
of interest changes frequently and ordering of those updates is important.

The problem, though, is that (particularly in the second case) the mechanism for
framing and delivering events over a long-running GET is (a) not specified by HTTP,
really --- there are no existing suitable mechanisms for passing *multiple* responses
to a single request, though pipelining could potentially be abused somehow, and (b)
even if there were, the problem seems very application-specific;  knowing what
individual update messages or events mean, etc. may not be generalizable.  To the
extent that it is generalizable, KN or similar probably provides the right general
pattern.

Just some thoughts...  mulling over a whole can of worms that I'd been mostly ignoring
for the last few years... ;-)

jb










-----------------------------------------------------------------------------------
Post ID:635
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-03 20:37:55
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:


"S. Alexander Jacobson" wrote:

> On Sun, 3 Feb 2002, Jeff Bone wrote:
> > Silly rabbit.  NOTIFY is "touch."
>
> No because NOTIFY may result in a change in the
> thing being notified.  Touch simply causes the
> date to change.

And that's specifically what WD-Proxy's NOTIFY does --- though in fact
it's sort of the reverse of touch.  Proxy A has a cached version of
/bar from origin server www.foo.com.  When /bar changes, the origin
server www.foo.com sends a message to Proxy A:

www.foo.com -> Proxy A
-----------------------------
NOTIFY http://www.foo.com/bar HTTP/1.1

thereby invalidating your copy.  ("You" being Proxy A.)  Admittedly it
doesn't actually change the modification time of your copy;  rather, it
lets you know that the actual resource on the origin server has been
modified since your original GET request.

> E.g. Suppose I go to a web site and think that
> a binary is out of date with respect to the
> source. I NOTIFY on the URL of the binary and the
> server may retrieve the source and recompile IF
> the source is more recent than the binary.

I think you misundertand the NOTIFY pattern;  re-read the WD-Proxy
spec.  You don't NOTIFY a resource on an origin server, you GET that
resource with appropriate headers and then the origin server generates
a NOTIFY to you, "touching" your cached representation to tell you it's
been modified on the origin server.

At any rate, the semantics of NOTIFY are entirely related to relative
modification times, similar to "touch," not anything nearly as complex
as make's dependencies and refreshing.

jb










-----------------------------------------------------------------------------------
Post ID:636
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 20:36:24
Subject:RE: [rest-discuss] One-shot notifications
Message:

paul said:
> I'm trying to make a distinction here between the semantic content of
> the message and the literal content. The semantic content is "something
> changed." The literal content is often "oh, and by the way, you could do
> a GET to fetch it but in order to reduce network load I've inlined the
> value here for you. If you would rather ignore the inlined value, go
> ahead and do the GET. It's all the same to me."

IMO this is a good thing, but not related to notifications.  The thing you are
describing is updates.  I am _for_ dealing with updates, but as a separate
project.


> > >  3. the last point implies that the server must tell the client in the
> > > notification that it is "pre-authorized" for re-subscription.
> >
> > It seems safe to assume that the sink is pre-authorized to resubscribe often
> > enough to consider it the default.
>
> Sure, the default. But you're just reversing the question. Then the
> publisher must be able to tell the subscriber that it is NOT
> pre-authorized.
>
> > ... Plus it doesn't really cause damage to have
> > a re-subscribe fail.
>
> I strongly disagree. If I believe that I'm subscribed to a stock ticker
> but I'm not really, heads will roll. Resubscription is important!

I don't mean fail silently.  If the re-subscribe fails, the server should say
so.

1) A sink receives a notification that state on the server is different since
the last time it requested a copy.
2) In the period between receiving the notification and requesting the new state
subsequent notifications are meaningless, hence resubscribe is meaningless.
3) Eventually the sink performs a request for the new state.  As part of the
request the sink resubscribes.  (A combined operation will be hard to model in
HTTP, but this message is not the place to articulate the problems.)
4) If the resub in the request fails, the server returns a status code to say
so.  So there's no possibility of losing ticks.

I think there is a failure to communicate here.  I believe that you are thinking
that first the source reports an event; later another event happens that the
server needs to report; but there is not a subscription at that moment because
the subscription expired after the first notification.  However that situation
cannot arise in the idempotent notification model.  INM notifications are all
identical.  There is no difference in the semantic content of the first and Nth
notifications.  A subscription _does_ expire after the notification is received
by the sink, but it doesn't matter, because all of the content that doesn't
cause notifications to be fired gets picked up anyway when the sink requests the
new state.

A stock ticker isn't a usecase for idempotent notifications, FWIW.  Timing is
everything with a ticker, so it should use an update approach.  Avoiding time
lags caused by the period between POP polling loops is a more focused usecase.
Google might register for notifications in order to be able to both keep its
cache more up-to-date and expend fewer resources on spidering runs.  A user
might register for blog updates that come in too sporadically to poll for.  A
C++ UI might might communicate with a Java engine by registering for
"computation complete" notifications.

- Lucas







-----------------------------------------------------------------------------------
Post ID:637
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-03 20:46:11
Subject:Re: [rest-discuss] One-shot notifications
Message:


"S. Alexander Jacobson" wrote:

> PUT is incorrect.
> It also requires both endpoints to be HTTP
> servers.   GET Events requires only one endpoint
> to be a server.

This is an aspect of the asymmetry problem, particularly the asymmetrical
hardwiring of "client" and "server" roles.

In the context of what we're discussing, we've deemed it safe to assume that
notifications happen between resources, with the implication that both ends
have a resource namespace and respond to (at least some) HTTP requests ---
everything is a server.  How those requests actually get from end to end ---
i.e., connection directionality, etc. --- are out of scope, but there are
various options, cf. [1]  In general, the formula for dealing with this
requires an external and open "rendezvous" server coupled with a tunnel that
allows a requests to flow downstream and responses upstream over a long-lived
GET connection to a resource on the rendezvous server.

jb

[1] http://internet.conveyor.com/RESTwiki/moin.cgi/SwitchboardPattern








-----------------------------------------------------------------------------------
Post ID:638
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-03 20:50:01
Subject:Re: [rest-discuss] One-shot notifications
Message:


Lucas Gonze wrote:

> 3) Eventually the sink performs a request for the new state.  As part of the
> request the sink resubscribes.  (A combined operation will be hard to model in
> HTTP, but this message is not the place to articulate the problems.)

Can you expand on this?  IMO, it seems trivial to me --- the sink merely requests
notification and indicates the sink resource in-band with the GET of the new state,
ala WD-Proxy.

> 4) If the resub in the request fails, the server returns a status code to say
> so.  So there's no possibility of losing ticks.

This may be a bit trickier --- you want to return both the appropriate response to
the GET *and* information relating to the notification commitment or lack thereof.
But again, IMO, WD-Proxy provides a reasonable starting point.


> I think there is a failure to communicate here.  I believe that you are thinking
> that first the source reports an event; later another event happens that the
> server needs to report; but there is not a subscription at that moment because
> the subscription expired after the first notification.  However that situation
> cannot arise in the idempotent notification model.  INM notifications are all
> identical.  There is no difference in the semantic content of the first and Nth
> notifications.  A subscription _does_ expire after the notification is received
> by the sink, but it doesn't matter, because all of the content that doesn't
> cause notifications to be fired gets picked up anyway when the sink requests the
> new state.

This is exactly right.  It's also the primary difference between the pure
notification model and the update model.

jb








-----------------------------------------------------------------------------------
Post ID:639
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-04 00:17:49
Subject:Re: [rest-discuss] GET Events Protocol (was HttpEvents as currently contemplated areextraneous)
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> Thats fine, I think.  If you offer notification,
> you create URLs which represent the stream of
> changes to some other URL (or collection of URLs).
> The recipient then gets a chunk encoded stream of
> update messages.

This is a weird abuse of HTTP. Chunks are supposed to be used to make
data flow more efficient, not to indicate changes in state across time.
An intermediary might choose to group chunks to merge them or re-chunk
for performance reasons.

Data formats are about the structure of bytes in a stream.

Protocols are about the timing of when data moves across a pipe. You're
abusing a data format (mime/multipart) to invent a new protocol. REST
philosophy (like Mao Zedung-thought) says you shouldn't have to do that.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:640
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 21:26:54
Subject:RE: [rest-discuss] One-shot notifications
Message:

> > 3) Eventually the sink performs a request for the new state.  As part of the
> > request the sink resubscribes.  (A combined operation will be hard
> to model in
> > HTTP, but this message is not the place to articulate the problems.)
>
> Can you expand on this?  IMO, it seems trivial to me --- the sink
> merely requests
> notification and indicates the sink resource in-band with the GET of
> the new state,
> ala WD-Proxy.

Your response to point #4 is the same thing that I meant.  Quoting you to you:
"you want to return both the appropriate response to the GET *and* information
relating to the notification commitment or lack thereof."

You need to both pick up the new state of the watched resource and post to the
subscription resource.  Since these address separate resources, encapsulating
them in a single request is request-in-request.

The natural solution is to require that two requests be performed, one to
request the resource and one to renew your sub.  Performing two requests (one to
the watched resource, one to the subscription resource) may be an unacceptable
efficiency issue.  Given that the size of a subscription request is low and that
the connection can be kept alive, this isn't a real efficiency blow.

A more pressing problem is that there's a race condition between the time you
pick up the new state of the resource and the time your renewal is processed.
If the resource changes between those times then you'll lose intervening states.
...my instinct is to say that there needs to be a way of locking these two
transactions together.  ...but perhaps there is a simple solution -- to say that
every subscription may specify a baseline state.  If the current state of the
resource at the time the request is received differs from the baseline state, a
notification is immediately fired.  All subscriptions would be:

1) Requester requests current state of watched resource.
2) Requester requests subscription.  Subscription headers include the hash of
the last known state.
3) Source compares last-known hash with current hash and, if there is a
difference, fires a notification.

The race condition is not unique to renewals.  New subscriptions would also
suffer from it, so the above algorithm should be the same across all
interactions.

I supposed a default value of the hash that means "I don't care about the race
condition, just use your current state as a baseline" would do good things for
hello world implementations...













-----------------------------------------------------------------------------------
Post ID:641
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 21:41:56
Subject:Re: Different apps have different needs
Message:

> Long-lived GET is appropriate in two contexts:  first, where the problem you're
> actually solving is the asymmetry of connectivity on the Web, and then long-lived GET
> only solves half the problem, and that rather poorly.

HTTP fundamentally differentiates between clients
and servers.  It specifically does not require
clients to implement server functionality.

A client should not have to implement server like
functionality if it is just receiving
requested state from a server.

Assymetry is part of the HTTP model.  Enjoy it!

> Second, when the resource model
> of interest changes frequently and ordering of those updates is important.
> The problem, though, is that (particularly in the second case) the mechanism for
> framing and delivering events over a long-running GET is (a) not specified by HTTP,
> really ---

I agree with you.  My general claim is indeed that
this is a problem to be solved at the content-type
level rather than at the HTTP protocol level.

And, moreover, the combination of
multipart/mixed with message/external-body has
exactly the semantics that notification
requires.

There is no deep need to reinvent the wheel.

> there are no existing suitable mechanisms for  passing *multiple* responses
> to a single request, though pipelining could potentially be abused somehow,

I am not advocating passing multiple responses.  I
am advocating passing a single multipart/mixed
response (that may be sent chunk encoded).

> and (b)
> even if there were, the problem seems very application-specific;  knowing what
> individual update messages or events mean, etc. may not be generalizable.  To the
> extent that it is generalizable, KN or similar probably provides the right general
> pattern.

I don't know the details of the KN protocol, but
the application of getting notifications of change
on some set of URLs is best handled by MIME.

You need to get the MIME zen. :-)

-Alex-


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:642
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 21:42:31
Subject:RE: Different apps have different needs
Message:

> HTTP fundamentally differentiates between clients
> and servers.  It specifically does not require
> clients to implement server functionality.
...
> Assymetry is part of the HTTP model.  Enjoy it!


I agree.  I am excited to work on changing that but also uneasy about it.  








-----------------------------------------------------------------------------------
Post ID:643
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 21:45:15
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Sun, 3 Feb 2002, Jeff Bone wrote:
> > E.g. Suppose I go to a web site and think that
> > a binary is out of date with respect to the
> > source. I NOTIFY on the URL of the binary and the
> > server may retrieve the source and recompile IF
> > the source is more recent than the binary.
>
> I think you misundertand the NOTIFY pattern;  re-read the WD-Proxy
> spec.  You don't NOTIFY a resource on an origin server, you GET that
> resource with appropriate headers and then the origin server generates
> a NOTIFY to you, "touching" your cached representation to tell you it's
> been modified on the origin server.

My use of NOTIFY had nothing to do with the
WD-Proxy spec.  Though it is good to know that we
are in some agreement.  My point is that NOTIFY is
more general than just explicit proxies.  It
applies to any HTTP resource.

The fact that the WD-Proxy spec. describes a
NOTIFY that is specific to proxies is irrelevant
to my argument.

-Alex-


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:644
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 21:48:13
Subject:Re: [rest-discuss] One-shot notifications
Message:

I think it is an abuse of HTTP (or conflict with
REST) to require clients to be servers, just to
recieve a resource on some HTTP server.

Semantically, the client is requesting a list of
modifications or modification times of some
set of URLs from the server.  The server is then
providing it.

Why does this require two servers?

-Alex-

On Sun, 3 Feb 2002, Jeff Bone wrote:

>
>
> "S. Alexander Jacobson" wrote:
>
> > PUT is incorrect.
> > It also requires both endpoints to be HTTP
> > servers.   GET Events requires only one endpoint
> > to be a server.
>
> This is an aspect of the asymmetry problem, particularly the asymmetrical
> hardwiring of "client" and "server" roles.
>
> In the context of what we're discussing, we've deemed it safe to assume that
> notifications happen between resources, with the implication that both ends
> have a resource namespace and respond to (at least some) HTTP requests ---
> everything is a server.  How those requests actually get from end to end ---
> i.e., connection directionality, etc. --- are out of scope, but there are
> various options, cf. [1]  In general, the formula for dealing with this
> requires an external and open "rendezvous" server coupled with a tunnel that
> allows a requests to flow downstream and responses upstream over a long-lived
> GET connection to a resource on the rendezvous server.
>
> jb
>
> [1] http://internet.conveyor.com/RESTwiki/moin.cgi/SwitchboardPattern
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:645
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-03 21:50:26
Subject:Re: [rest-discuss] GET Events Protocol (was HttpEvents as currently contemplated areextraneous)
Message:

I can't believe I am hearing you all say this is a
wierd abuse of HTTP given that you were advocating
exactly this solution to a large set of problems
when I joined this list.

Either HTTP is the universal protocol or its not.
Pick one!

Note, if HTTP intermediaries decide to group
chunks in awkward ways, that is not a problem with
HTTP.  It is a problem with the intermediaries
implementation.

-Alex-

On Sun, 3 Feb 2002, Paul Prescod wrote:

> "S. Alexander Jacobson" wrote:
> >
> >...
> >
> > Thats fine, I think.  If you offer notification,
> > you create URLs which represent the stream of
> > changes to some other URL (or collection of URLs).
> > The recipient then gets a chunk encoded stream of
> > update messages.
>
> This is a weird abuse of HTTP. Chunks are supposed to be used to make
> data flow more efficient, not to indicate changes in state across time.
> An intermediary might choose to group chunks to merge them or re-chunk
> for performance reasons.
>
> Data formats are about the structure of bytes in a stream.
>
> Protocols are about the timing of when data moves across a pipe. You're
> abusing a data format (mime/multipart) to invent a new protocol. REST
> philosophy (like Mao Zedung-thought) says you shouldn't have to do that.
>
>  Paul Prescod
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:646
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-04 00:50:32
Subject:Re: [rest-discuss] One-shot notifications
Message:

Lucas Gonze wrote:
> 
>...
> 
> IMO this is a good thing, but not related to notifications.  The thing you are
> describing is updates.  I am _for_ dealing with updates, but as a separate
> project.

Fine. But for performance reasons we need to leave hooks into *this*
project that will allow us to inline useful information later. 

If the performance characteristics of the protocol make it unusable for
anything other than cache invalidation then it won't have met any of my
goals.

In almost every application I can think of (other than pure cache
invalidation), the common pattern is:

GET
NOTIFY
GET
NOTIFY

So you are going to trigger TCP connection/teardown twice for each
notification. Developers will hate that. If you know of a bunch of
applications for a "pure" notification model then I'd like to hear about
them. But almost anything that goes across organizational boundaries
will want a full update because you can't trust the other party to not
delete the data before you get to it.

> I don't mean fail silently.  If the re-subscribe fails, the server should say
> so.
> 
> 1) A sink receives a notification that state on the server is different since
> the last time it requested a copy.
> 2) In the period between receiving the notification and requesting the new state
> subsequent notifications are meaningless, hence resubscribe is meaningless.

I guess that's our problem. I'm thinking ahead to inline representations
and re-subscribe in responses. In that case, the inline representation
is the equivalent of a GET.

Here's another (somewhat less efficient) idea: the response to a NOTIFY
could return a Location: that says where to PUT the changed data.
Because all of the connections go from publisher to subscriber, the same
TCP connection could be used.

I kind of like that becuase the notification could say: "the document is
5MB. You may or may not want to fetch it unless you know you really need
it."

> 3) Eventually the sink performs a request for the new state.  As part of the
> request the sink resubscribes.  (A combined operation will be hard to model in
> HTTP, but this message is not the place to articulate the problems.)

What's wrong with the header approach from WD-NOTIFY?

>...
> A stock ticker isn't a usecase for idempotent notifications, FWIW.  Timing is
> everything with a ticker, so it should use an update approach. 

Well it is essentially impossible to guarantee latency on the public
Internet anyhow. So I don't see a big difference between a notification
model and an update model. Even without resource inlining, we're talking
about an extra second or two. For all you know, the message is already
five minutes late because of network congestion!

I do think that notifications should be efficient enough for interactive
(but not hard-realtime) use.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:647
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 21:54:40
Subject:RE: [rest-discuss] GET Events Protocol (was HttpEvents as currently contemplated areextraneous)
Message:

You can't use chunks as message delimeters because proxies may (must?) strip out
chunk encoding before the data is passed to the client.

> Note, if HTTP intermediaries decide to group
> chunks in awkward ways, that is not a problem with
> HTTP.  It is a problem with the intermediaries
> implementation.
>
> -Alex-







-----------------------------------------------------------------------------------
Post ID:648
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-04 01:01:43
Subject:Re: [rest-discuss] GET Events Protocol (was HttpEvents as currentlycontemplated areextraneous)
Message:

"S. Alexander Jacobson" wrote:
> 
> I can't believe I am hearing you all say this is a
> wierd abuse of HTTP given that you were advocating
> exactly this solution to a large set of problems
> when I joined this list.

I've never advocated using chunked HTTP for anything like that.

> Either HTTP is the universal protocol or its not.

HTTP is the universal protocol. You can use it as it was designed to be
used without tricking it. Any of us could implement an HTTP-based
notification scheme in a couple of hours. *BUT* the reason that what we
are doing is difficult is because we are trying to define an HTTP
notification scheme *for* HTTP. i.e. we want to get our heads inside
HTTP and design a notification model as it would have been designed by
Roy, Henrik, Tim, Philip etc. at the time HTTP was being designed. This
is much harder than figuring out a way to use HTTP for a particular
application.

>...
> Note, if HTTP intermediaries decide to group
> chunks in awkward ways, that is not a problem with
> HTTP.  It is a problem with the intermediaries
> implementation.

Infosar as the HTTP implementation says to treat the chunks as *one
logical stream* it is perfectly legit for an intermediary to re-chunk
however it wants. It also might blow away the connection when it feels
like it has timed out. 

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:649
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-03 22:14:43
Subject:RE: [rest-discuss] One-shot notifications
Message:

per Paul:
> Fine. But for performance reasons we need to leave hooks into *this*
> project that will allow us to inline useful information later.

IMO charter for the notifications design is partly to lay the groundwork for an
update project to follow, which means in practice that anything that prevents
later update extensions has a high burden of proof.  EG We should avoid
specifying what's in the notification entity body, because that's the likely
location of update data, but we should also not give a half-assed definition of
what's in the update entity body, because that may make things harder on the
update project.

> I guess that's our problem. I'm thinking ahead to inline representations
> and re-subscribe in responses. In that case, the inline representation
> is the equivalent of a GET.

Yeah, and I think that's a good thing.


> Here's another (somewhat less efficient) idea: the response to a NOTIFY
> could return a Location: that says where to PUT the changed data.
> Because all of the connections go from publisher to subscriber, the same
> TCP connection could be used.
>
> I kind of like that becuase the notification could say: "the document is
> 5MB. You may or may not want to fetch it unless you know you really need
> it."

I like this idea, though I would wait on a dedicated project to work through all
the implications before committing to it.


> > 3) Eventually the sink performs a request for the new state.  As part of the
> > request the sink resubscribes.  (A combined operation will be hard
> to model in
> > HTTP, but this message is not the place to articulate the problems.)
>
> What's wrong with the header approach from WD-NOTIFY?

don't know it yet.  :)

busy workdays for me lately, sorry to be slack in keeping up with reading.


> > A stock ticker isn't a usecase for idempotent notifications, FWIW.
> Timing is
> > everything with a ticker, so it should use an update approach.
>
> Well it is essentially impossible to guarantee latency on the public
> Internet anyhow. So I don't see a big difference between a notification
> model and an update model. Even without resource inlining, we're talking
> about an extra second or two. For all you know, the message is already
> five minutes late because of network congestion!

Sure!  And given that you can actually pick up all transient states (by
subscribing to a broad /resource/all_states resource instead of a child
/resource/current_state resource) notifications should be able to provide quite
a lot of functionality.

>
> I do think that notifications should be efficient enough for interactive
> (but not hard-realtime) use.

Agreed.







-----------------------------------------------------------------------------------
Post ID:650
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-04 01:17:57
Subject:Re: [rest-discuss] One-shot notifications
Message:

"S. Alexander Jacobson" wrote:
> 
> I think it is an abuse of HTTP (or conflict with
> REST) to require clients to be servers, just to
> recieve a resource on some HTTP server.

HTTP says that all connections are made from clients to servers. You
could argue that requiring subscribers to be servers is a bad idea for
security reasons or whatever, but it isn't in conflict with HTTP!

You're using a different definition of client and server than HTTP does.
If a Linux box is the initiator of a particular HTTP transaction then it
is the client.

If we really decide that the "right thing" is a TCP connection from
subscriber to publisher then we would have to invent a non-HTTP
protocol. I can see various practical limits including:

 * limits on numbers of TCP connctions on particular machines
 * timeouts
 * firewalls
 * security admins freaking out about the number of open connections

Think about Google subscribing to notifications from every news site in
the world. I can't imagine it keeping TCP connections open to tens of
thousands of them at a time. You're going to run into some serious OS
limitations.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:651
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-04 02:23:49
Subject:Re: [rest-discuss] One-shot notifications
Message:

Lucas Gonze wrote:
> 
> per Paul:
> > Fine. But for performance reasons we need to leave hooks into *this*
> > project that will allow us to inline useful information later.
> 
> IMO charter for the notifications design is partly to lay the groundwork for an
> update project to follow, which means in practice that anything that prevents
> later update extensions has a high burden of proof.  EG We should avoid
> specifying what's in the notification entity body, because that's the likely
> location of update data, but we should also not give a half-assed definition of
> what's in the update entity body, because that may make things harder on the
> update project.

Here's a proposal for both the notify and update parts.

 1. the client signs up for notification by doing a GET or HEAD with a
special header.

 2. the server does a POST or NOTIFY (argue that one out later) to the
client informing it that the resource is available. It MUST pre-announce
whether an immediate re-subscribe would succeed.

 2. the client responds, optionally asking:
  a) to be re-susbcribed (any flags or options the same)
  b) for a representation of the resource to be PUT to a URI specified
in a Location: header

 3. the server does the requested PUT and re-SUB

If we have broad agreement on these, I could write it up.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:652
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-03 22:33:29
Subject:Re: [rest-discuss] Why is HTTP special?
Message:

Mark Baker wrote:
> 
>...
> 
> This is like saying that Ethernet is general purpose.  It's true, but
> not too useful.  RPC is a lower layer than HTTP because it defines no
> application semantics, leaving them for the "API" to define.

I'm scared of the term "application" because we also build applications
on top of HTTP. Plus, RPC has its own set of semantics involving
parameters, return codes, methods, etc. The word semantics is also a
mine-field. I'm one of a vocal few people who claim that XML has
semantics (angle-brackets are syntax, attributed-trees are semantics). 

> Linda, like HTTP and FTP and NNTP, defines the methods.  So you've
> got an application layer contract - a coordination language -
> between endpoints a priori.

Is SMTP a coordination language? Do we have a definition that can be
made precise?

>...
> > Definitions aside, the point remains: in terms of generality, HTTP has
> > more in common with SOAP than with SMTP. It is not just about moving
> > HTML pages from servers to clients.
> 
> I'd say it's the other way around.  SMTP "DATA" has a precise
> meaning, not unlike POST.  

I know you claim that POST's meaning is precise. ;)

>...
> > HTTP is similar. HTTP allows you to read from the storage with GET,
> > write to it with PUT and the addresses are URIs. Because disk space in
> > the real world is limited, HTTP also has DELETE. And because multiple
> > people will be using the system at once, there is a need for a method
> > that will create guaranteed-new "storage locations".
> 
> I'd say that POST was the movement of the tape.  PUT creates new
> locations.

We disagree on the meaning of POST. What a surprise. ;)

If we are strict about the idea that URIs are opaque then the client
doing the PUT can't really know what URI to use to create a new
resource. POST can be used to provide a new URI.

> > FTP is the closest protocol to HTTP conceptually. But really the gap
> 
> I think NNTP is probably closest.  It has POST (that's where HTTP's
> POST came from), a basic get (ARTICLE), and a very specific type of
> put (for setting read messages).

FTP has a more general GET (i.e. it has a concept of hierarchy and
filenames) and PUT.

> > important, though, FTP's semantics do not allow the server to be an
> > active participant in the computation. HTTP very precisely defines how
> > the server can do complicated computations by itself. It is not just a
> > holder of bits -- it can embody a complex service!
> 
> You mean the app here I guess.  You should distinguish between the
> web server and the web app.

Okay.

> > efficiency and modeling simplicity. For instance WebDAV has a LOCK
> > method which could be modeled as a POST of a LOCk object. In theory the
> 
> PUT actually, since it is defined absolutely.

Okay.

>...
> 
> > I say "quasi-universal" because there are limits. Just as XML isn't
> > really great for binary media, HTTP isn't really great for streaming
> > real-time media. So for those applications you should use something
> > else.
> 
> (though perhaps with HTTP's application semantics)

Okay.

> > There is no doubt that HTTP has its limitations. For one thing there is
> > not much software out there that knows how to deal with HTTP in a
> > peer-to-peer or asychronous fashion.
> 
> I don't know what that means.

Define client as a device with potentially transient connectivity,
directly controlled by an end-user.
Define server as a device with persistent connectivity not controlled by
an end-user.

There is not much software out there that uses HTTP to have servers
contact clients, or servers to contact servers using HTTP. This is
important because it means that firewalls are not appropriately
configured for that sort of usage. Thus, KnowNow single-byte hacks.

 Paul Prescod








-----------------------------------------------------------------------------------
Post ID:653
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-04 01:58:42
Subject:Re: [rest-discuss] Why is HTTP special?
Message:

> > This is like saying that Ethernet is general purpose.  It's true, but
> > not too useful.  RPC is a lower layer than HTTP because it defines no
> > application semantics, leaving them for the "API" to define.
> 
> I'm scared of the term "application" because we also build applications
> on top of HTTP.

Technically, we don't.  I know the common use of the term is just that,
but in actuality, we are simply adding more resources to an existing
app, the Web.

> Plus, RPC has its own set of semantics involving
> parameters, return codes, methods, etc. The word semantics is also a
> mine-field. I'm one of a vocal few people who claim that XML has
> semantics (angle-brackets are syntax, attributed-trees are semantics). 

Sure, and I agree with you about XML having semantics (Jon Bosak has
said as much).  But "application semantics" has a much more precise
meaning, though not commonly known.

> > Linda, like HTTP and FTP and NNTP, defines the methods.  So you've
> > got an application layer contract - a coordination language -
> > between endpoints a priori.
> 
> Is SMTP a coordination language?

Yes.

> Do we have a definition that can be
> made precise?

I'm sure we could whip one together without much trouble.  As I say on
the Wiki, I believe that all application protocols are coordination
languages.

> We disagree on the meaning of POST. What a surprise. ;)
> 
> If we are strict about the idea that URIs are opaque then the client
> doing the PUT can't really know what URI to use to create a new
> resource. POST can be used to provide a new URI.

Right, that's the point.

The whole idea with PUT is that the client specifies the name, likely
because it had previously done a GET and so knows what the name already
is.  But any container can choose to reject a PUT with a name it doesn't
like, so that's why it's still opaque (it determines the meaning of
the name).  I suppose that somewhere in there is a PUT based form
solution where the form suggests a URI.

POST means "accept as a subordinate", which means that the client is
specifically punting all responsibility for the document to the
container, including naming it, as you say.

> > > FTP is the closest protocol to HTTP conceptually. But really the gap
> > 
> > I think NNTP is probably closest.  It has POST (that's where HTTP's
> > POST came from), a basic get (ARTICLE), and a very specific type of
> > put (for setting read messages).
> 
> FTP has a more general GET (i.e. it has a concept of hierarchy and
> filenames) and PUT.

News groups and articles are hierarchically named too.  Each group is a
container that contains multiple articles, articles can be posted to
multiple groups, etc.. (it goes beyond HTTP here, and gets into
KnowNow-land with message ids and topics).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:654
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-04 04:22:12
Subject:RE: [rest-discuss] One-shot notifications
Message:

On Sun, 3 Feb 2002, Lucas Gonze wrote:
> A stock ticker isn't a usecase for idempotent notifications, FWIW.

However it is a use case for GET Events.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:655
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-04 04:34:27
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

On Sun, 3 Feb 2002, Jeff Bone wrote:
> And that's specifically what WD-Proxy's NOTIFY does

I just read the WD-Proxy spec.  It doesn't make
sense.  Methods should be delivered to endpoints,
not proxies!

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:656
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-04 04:43:28
Subject:Re: [rest-discuss] GET Events Protocol (was HttpEvents as currently contemplated areextraneous)
Message:

On Sun, 3 Feb 2002, Paul Prescod wrote:
> Protocols are about the timing of when data moves across a pipe. You're
> abusing a data format (mime/multipart) to invent a new protocol. REST
> philosophy (like Mao Zedung-thought) says you shouldn't have to do that.

Go ahead and re-read the discussion on this list
when I first joined justifying REST. Many of the
answers revolved around either persistent GET or
long GET with multiple plaudits for KnowNow.

Is KnowNow abusing HTTP?

Really I think if you want to make this argument,
you should take it up with Jeff, Mike, and Mark.
They were all arguing about why HTTP is great
protocol for chat, using persistent GET.
Actually, I think you might have been arguing this
as well.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:657
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-04 04:54:33
Subject:RE: [rest-discuss] One-shot notifications
Message:

On Sun, 3 Feb 2002, Lucas Gonze wrote:
> A more pressing problem is that there's a race condition between the time you
> pick up the new state of the resource and the time your renewal is processed.

Again, using GET Events does not have this problem.

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:658
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-04 04:55:22
Subject:Re: [rest-discuss] RE: Different apps have different needs
Message:

On Sun, 3 Feb 2002, Lucas Gonze wrote:
> > HTTP fundamentally differentiates between clients
> > and servers.  It specifically does not require
> > clients to implement server functionality.
> ...
> > Assymetry is part of the HTTP model.  Enjoy it!
>
>
> I agree.  I am excited to work on changing that but also uneasy about it.

Why change it?

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:659
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-04 04:57:09
Subject:RE: [rest-discuss] GET Events Protocol (was HttpEvents as currently contemplated areextraneous)
Message:

How does KnowNow work?
In any case, I don't think these GET requests are
cachable so intermediaries should act
transparently.

-Alex-

On Sun, 3 Feb 2002, Lucas Gonze wrote:

> You can't use chunks as message delimeters because proxies may (must?) strip out
> chunk encoding before the data is passed to the client.
>
> > Note, if HTTP intermediaries decide to group
> > chunks in awkward ways, that is not a problem with
> > HTTP.  It is a problem with the intermediaries
> > implementation.
> >
> > -Alex-
>
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:660
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-04 05:01:14
Subject:Re: [rest-discuss] GET Events Protocol (was HttpEvents as currentlycontemplated areextraneous)
Message:

On Sun, 3 Feb 2002, Paul Prescod wrote:
> > I can't believe I am hearing you all say this is a
> > wierd abuse of HTTP given that you were advocating
> > exactly this solution to a large set of problems
> > when I joined this list.
>
> I've never advocated using chunked HTTP for anything like that.

What does KnowNow do?

> > Either HTTP is the universal protocol or its not.
>
> HTTP is the universal protocol. You can use it as it was designed to be
> used without tricking it. Any of us could implement an HTTP-based
> notification scheme in a couple of hours.

Again, please re-read the discussion from before.

> >...
> > Note, if HTTP intermediaries decide to group
> > chunks in awkward ways, that is not a problem with
> > HTTP.  It is a problem with the intermediaries
> > implementation.
>
> Infosar as the HTTP implementation says to treat the chunks as *one
> logical stream* it is perfectly legit for an intermediary to re-chunk
> however it wants. It also might blow away the connection when it feels
> like it has timed out.

Re-chunking does not affect the protocols
performance (except perhaps in a good way).  If it
blows away the connection, the client can just
reconnect it.  This is certainly lighter weight
and more sane than repeatedly connecting just to
request subscriptions.

But, again, I refer you to the discussion of
implementing chat and knownow in the discussion we
had when I arrived.

Mark and Jeff, where are you on this issue?

-Alex-
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:661
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-04 05:10:21
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>


> > ----- Original Message -----
> > From: "S. Alexander Jacobson" <alex@...>
> > >
> >
> > > PS My gut also says that NOTIFY really means
> > > something quite distinct from POST.  In
> > > particular, POST says something about a resource
> > > is to be changed in some way.  NOTIFY signals that
> > > the change has already happened.
> >
> > I agree.
>
> I don't.  The resource identified by the callback URI can be whatever
> the subscriber wants it to be.  If it's a semaphore, then PUT or POST
> is fine.  If it's a mailbox, then POST is good.  I dare you to try and
> choose a resource that's used to receive notifications that can't
> receive them with PUT or POST.

It's not the method name that is important to me, it is the meaning - that a
notification is about a change that already happened.









-----------------------------------------------------------------------------------
Post ID:662
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-04 05:07:24
Subject:Re: [rest-discuss] One-shot notifications
Message:

On Sun, 3 Feb 2002, Paul Prescod wrote:
> HTTP says that all connections are made from clients to servers. You
> could argue that requiring subscribers to be servers is a bad idea for
> security reasons or whatever, but it isn't in conflict with HTTP!

No, the conflict is philosophical.  HTTP says that
a client makes a request for information and the
server delivers it.  Defining a new protocol that
works by requesting information and getting it
delivered over another connection later is not in
the spirit of HTTP.

> If we really decide that the "right thing" is a TCP connection from
> subscriber to publisher then we would have to invent a non-HTTP
> protocol. I can see various practical limits including:
>
>  * limits on numbers of TCP connctions on particular machines
>  * timeouts
>  * firewalls
>  * security admins freaking out about the number of open connections

Again, I refer you to the discussion from before.
Limits on the numbers of TCP connections is
entirely artificial.  Mike and Jeff both referred
to implementations with 50k connections per
machine.

Timeouts are handled by periodic reconnects.
Firewalls are BETTER handled by using GET.

Security admins freaking is just part of life.
The typical client is not going to have that many
connections open.  Since users are already using
IM I am not sure this is really an issue.

> Think about Google subscribing to notifications from every news site in
> the world. I can't imagine it keeping TCP connections open to tens of
> thousands of them at a time. You're going to run into some serious OS
> limitations.

These OS limitations are entirely spurious.  There
is no reason why socket information cannot be
stored in virtual memory (on disk).  I don't think
your scaling argument is good here.

More to the point, I don't think you can make a
solid argument that the load from notification
back and forth is really higher than maintaining
open GET connections.  I think GET Events is
actually much MORE scalable than notification!

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:663
Sender:"S. Alexander Jacobson" <shop2it@...>
Post Date/Time:2002-02-04 05:32:31
Subject:goodbye
Message:

I am realizing that I am spending too much
time on this list without getting enough
done.  I've learned a lot, but I need to move on.

If you are interested in helping to formalize
GET Events, please send me mail.

Either way, have fun.

-Alex-

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:664
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-04 05:41:09
Subject:Re: [rest-discuss] GET Events Protocol (was HttpEvents as currentlycontemplated areextraneous)
Message:

"S. Alexander Jacobson" wrote:
> 
>...
> 
> Go ahead and re-read the discussion on this list
> when I first joined justifying REST. Many of the
> answers revolved around either persistent GET or
> long GET with multiple plaudits for KnowNow.

KnowNow uses a good hack to get around firewalls. We may need to define
a hack like that for getting around firewalls too. But first you define
the protocol properly and then you figure out what you need to hack.

> Is KnowNow abusing HTTP?

Yes! Any solution that involves one-byte stay-alive messages is a hack!

But my understanding (and observation) is that *within* the hacked
socket KnowNow uses regular HTTP messages, not chunked MIME data. I want
to emulate what they do within the hack, not the hack.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:665
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-04 06:58:24
Subject:Re: [rest-discuss] GET Events Protocol (was HttpEvents as currentlycontemplated areextraneous)
Message:

On Mon, 4 Feb 2002, Paul Prescod wrote:
> > Is KnowNow abusing HTTP?
>
> Yes! Any solution that involves one-byte stay-alive messages is a hack!

But the hack is to route around disfunction in
HTTP implemenations, rather than to route around
limits in HTTP, right? I mean why are they sending
one-byte stay-alive messages?

> But my understanding (and observation) is that *within* the hacked
> socket KnowNow uses regular HTTP messages, not chunked MIME data. I want
> to emulate what they do within the hack, not the hack.

More particularly, how are they sending one byte
stay alive messages that also HTTP?  HTTP seems to
require at least a method and a status code, both
of which are at least 3 bytes...

-Alex-


___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:666
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-04 15:11:31
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

> It's not the method name that is important to me, it is the meaning - that a
> notification is about a change that already happened.

A PUT and/or POST in response to a WATCH can be made to mean exactly
that.  It's not a typical PUT or POST, since the invoker of the WATCH
method provides a callback resource that it knows will be used this
way.  So there's additional context that isn't there in a blind PUT or
POST (though the context is private to the WATCH invoker).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:667
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-04 19:28:47
Subject:Re: [rest-discuss] One-shot notifications
Message:


"S. Alexander Jacobson" wrote:

>
> Why does this require two servers?

Because if you're doing notification between resources...  drumroll...  you've got
to have a server to host those resources.

Bye, Alex.

jb








-----------------------------------------------------------------------------------
Post ID:668
Sender:"S. Alexander Jacobson" <alex@...>
Post Date/Time:2002-02-04 21:41:43
Subject:Re: [rest-discuss] One-shot notifications
Message:

On Mon, 4 Feb 2002, Jeff Bone wrote:
> > Why does this require two servers?
>
> Because if you're doing notification between resources...  drumroll...  you've got
> to have a server to host those resources.

Only if they are both resources.  If the outcome
of notification is to send an page or email, I
don't think that involves 2 resources.

As you have said repeatedly, an email address is
not a resource....

I am curious why you have changed your mind on
this issue.  You were definitely involved in
convincing me that long GET was a good way to go
for this type of application.

You appear to have changed your mind.  Why?

-Alex-

PS I am replying to email sent to me.
___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax








-----------------------------------------------------------------------------------
Post ID:669
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-02-05 00:19:36
Subject:Annotea
Message:

The W3C's Annotea [1] seems to be a good example of a RESTful Web
application.

Cheers,

[1] http://www.w3.org/2001/Annotea/User/Protocol.html

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:670
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-02-05 00:29:42
Subject:Re: [rest-discuss] Re: Summarization on notifications?
Message:

It could be; however, for some applications, that's too limiting.
More to the point, it's difficult to arrange your resources so that
these relationships are meaningful in multiple contexts; e.g., P3P
and access control (insert your own, more notification-specific,
examples here).

I discussed this a bit in Urispace [1]. I'd approach the problem
differently now.

Cheers,

[1] http://www.w3.org/TR/urispace.html



On Fri, Feb 01, 2002 at 05:11:29PM -0800, S. Mike Dierken wrote:
> 
> ----- Original Message -----
> From: "Mark Nottingham" <mnot@...>
> 
> 
> >
> > A list of URIs is too limiting - it may not be practical or possible
> > to enumerate them all...
> That's just from Pauls example. However, is it a 'web collection' is the
> things inside aren't first-class resources (uri addressable)?
> 
> >
> >
> >
> > On Fri, Feb 01, 2002 at 09:19:25AM -0800, S. Mike Dierken wrote:
> > >
> > > ----- Original Message -----
> > > From: "Paul Prescod" <paul@...>
> > >
> > > >
> > > > I've clarified my thoughts on how to handle notifications for
> > > > collections. Collections are just documents that happen to contain
> URIs
> > > > to other documents. Just hang a WATCH on that document.
> > > Woohoo! Yes, by george, you've got it! As a Groves dude, this should be
> > > pretty straightforward for you to work out the details of.
> > > And the resource (aka 'collection') may have metadata separate from the
> list
> > > of URIs - how do distinguish between the two? That's where the
> 'add/remove'
> > > comes from - they are 'updates' to the 'default collection' property.
> But
> > > that is all really too complex for now - I can build it in the app layer
> > > with the low level primitives.
> > >
> > >
> > >

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:671
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-05 01:37:01
Subject:RE: [rest-discuss] HttpEvents as currently contemplated are extraneous?
Message:

> Here's how this protocol could be used to accomplish (1):
>
> CLIENT -> SERVER
> ----------------------
> GET /foo HTTP/1.1
> Accept: text/html
> Proxy-Features: my.host.com; notify

I wonder if use of the notify flag should be considered a backdoor way to set
state on the server during a GET?  Does it matter if this operation is combining
a GET of the watched resource with a PUT to a subscription resource?  Are there
serious difficulties with figuring out whether the response status code applies
to the watched resource or the subscription resource?

For example, if the response is "unauthorized", how to figure out if it applies
to the watched resource or the subscription resource?








-----------------------------------------------------------------------------------
Post ID:672
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-06 07:02:11
Subject:Re: [rest-discuss] HttpEvents as currently contemplated are extraneous?
Message:


Lucas Gonze wrote:

> > Here's how this protocol could be used to accomplish (1):
> >
> > CLIENT -> SERVER
> > ----------------------
> > GET /foo HTTP/1.1
> > Accept: text/html
> > Proxy-Features: my.host.com; notify
>
> I wonder if use of the notify flag should be considered a backdoor way to set
> state on the server during a GET?  Does it matter if this operation is combining
> a GET of the watched resource with a PUT to a subscription resource?  Are there
> serious difficulties with figuring out whether the response status code applies
> to the watched resource or the subscription resource?

Hmmm...  I don't think this is terribly problematic.  One thing HTTP definitely
*doesn't* provide is an assurance that the overall state of resource space *only*
changes through the actions of the HTTP methods.  Given this, I don't think it's
necessary to view the above as a GET + PUT, even if it has some effect on a second,
unnamed (subscription) resource.

> For example, if the response is "unauthorized", how to figure out if it applies
> to the watched resource or the subscription resource?

Bear in mind that the notify is only a request for a subscription, if one exists.
The subsequent response will indicate whether or not such a subscription is either
available, authorized, granted...  not sure it's really manditory to distinguish
between those conditions.  Either the subscription is available and was granted, or
its not.  Dunno that more need be done.

What do you think?

jb








-----------------------------------------------------------------------------------
Post ID:673
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-06 19:07:19
Subject:Basic thoughts about put/post
Message:

So,
I was doing some coding the other day (it happens) and thought of a way to
clarify (for myself anyways) the distinction between put and post. Say I've
got a hashmap (dictionary, hashtable, etc.) with names and values.

value = server.get("name");
server.put("name",value);
server.post("name",value);

The put and post looks similar but the difference is

server.put(name,value)
{
    data[name] = value;
}

server.post(name,value)
{
    old = data[name];
    newValue = old + value;    // where "+" is arbitrarily complex
    data[name] = newValue;
}

So 'post' is (to me) a lot like 'append' (at least for some situations).
Although the '+' operation could ignore the old value and the post() would
act like put(), an intermediary (cache) won't know this and can't emulate
the '+' operation - hence optimizing the situation by publicly declaring
what the '+' operation is via the method name - put=a pure replacement.



Mike "stating the obvious" Dierken










-----------------------------------------------------------------------------------
Post ID:674
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-06 22:55:13
Subject:GET and notifications
Message:

I don't think it is appropriate for us to have GET have the side-effect
of registering a notification. What if a cache intercepts the method?
What if a server just doesn't understand the header at all? It won't
announce that.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:675
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-07 00:13:01
Subject:Re: [rest-discuss] GET and notifications
Message:

All good points.  Here are some off-the-top (hopefully not over-the-top ;-)
thoughts about these issues...

(1)  Side-effects.  I'm not 100% convinced its correct to view the
notification request behavior as a side-effect.  It doesn't actually impact
the content returned beyond adding a header and *later* producing an effect
that wouldn't exist otherwise;  a proxy doesn't necessarily have visibility
to the latter, so it's not clear that it's side-effecting from the proxy's
point-of-view.  Determination of idempotency -wrt- heavers vs. content is a
bit ambiguous.

(2) Note that WD-Proxy was originally intended to allow proxies to request
invalidation notifications from origin servers.  Given that the requesting
party identifies themselves inline with distinct headers, this is a bit of a
grey area.  Also note that, while inlining multiple requests is clearly
handled, there's no mechanism for allowing proxies to request upstream
proxies to generate invalidations based on their own receipt of
notifications, i.e. not clear whether / how to handle notification fan-out.
These are all valid areas for further discussion.

(3) It should be possible to force the request through the proxy from the
subscriber end of things through the use of other proxy directive headers in
combination...  right?

It does make me a bit uneasy, but I'm not sure why or how to weight the pros
and cons.

$0.02,

jb




Paul Prescod wrote:

> I don't think it is appropriate for us to have GET have the side-effect
> of registering a notification. What if a cache intercepts the method?
> What if a server just doesn't understand the header at all? It won't
> announce that.
>
>  Paul Prescod
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:676
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-07 13:01:02
Subject:RE: [rest-discuss] GET and notifications
Message:

I am hopelessy undecided on this -- there are excellent reasons on both sides.
My plan is to write up sample transactions in both styles and compare how well
they work in practice.


> It does make me a bit uneasy, but I'm not sure why or how to weight the pros
> and cons.
...
> jb
...
> Paul Prescod wrote:
...
> > I don't think it is appropriate for us to have GET have the side-effect
> > of registering a notification. What if a cache intercepts the method?
> > What if a server just doesn't understand the header at all? It won't
> > announce that.







-----------------------------------------------------------------------------------
Post ID:677
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-07 15:02:48
Subject:Re: [rest-discuss] GET and notifications
Message:

Paul wrote;
> I don't think it is appropriate for us to have GET have the side-effect
> of registering a notification. What if a cache intercepts the method?

GET doesn't have side-effects in that case.  The resource doesn't change
state, plus any other stateful action are undone when the GET finishes.

> What if a server just doesn't understand the header at all? It won't
> announce that.

The "Subscriber" header?  Nope, it won't announce it, but that's part of
the Subscription/Subscriber contract.  Why would somebody POST a message
with a Subscriber body to a URI that didn't advertise its ability to
accept it (and have it mean "subscribe")?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:678
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-07 15:47:36
Subject:Re: [rest-discuss] GET and notifications
Message:

Jeff Bone wrote:
> 
> All good points.  Here are some off-the-top (hopefully not over-the-top ;-)
> thoughts about these issues...
> 
> (1)  Side-effects.  I'm not 100% convinced its correct to view the
> notification request behavior as a side-effect.  It doesn't actually impact
> the content returned beyond adding a header and *later* producing an effect
> that wouldn't exist otherwise; 

The server needs to change state to remember the request. That sounds
like a side-effect to me.

>...
> (3) It should be possible to force the request through the proxy from the
> subscriber end of things through the use of other proxy directive headers in
> combination...  right?

I suppose so.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:679
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-07 15:49:47
Subject:Re: [rest-discuss] GET and notifications
Message:

Mark Baker wrote:
> 
> > I don't think it is appropriate for us to have GET have the side-effect
> > of registering a notification. What if a cache intercepts the method?
> 
> GET doesn't have side-effects in that case.  The resource doesn't change
> state, plus any other stateful action are undone when the GET finishes.

I don't follow you. If a GET tells a server to remember to contact me
later then how is that not a side-effect. It is a change of server-side
state (though not a change of the resource's state).

> > What if a server just doesn't understand the header at all? It won't
> > announce that.
> 
> The "Subscriber" header?  Nope, it won't announce it, but that's part of
> the Subscription/Subscriber contract.  Why would somebody POST a message
> with a Subscriber body to a URI that didn't advertise its ability to
> accept it (and have it mean "subscribe")?

First: you shouldn't have to know a priori whether a resource is
subscribable. You should be able to ask it.

Second: having a resource do a completely different type of action based
on the contents of the entity body sounds like RPC to me!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:680
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-07 16:09:02
Subject:Re: [rest-discuss] GET and notifications
Message:

> Mark Baker wrote:
> > 
> > > I don't think it is appropriate for us to have GET have the side-effect
> > > of registering a notification. What if a cache intercepts the method?
> > 
> > GET doesn't have side-effects in that case.  The resource doesn't change
> > state, plus any other stateful action are undone when the GET finishes.
> 
> I don't follow you. If a GET tells a server to remember to contact me
> later then how is that not a side-effect. It is a change of server-side
> state (though not a change of the resource's state).

Ooh, ow, who's using GET that way?

I've only ever suggested using a GET that lasts for a long time.

> > > What if a server just doesn't understand the header at all? It won't
> > > announce that.
> > 
> > The "Subscriber" header?  Nope, it won't announce it, but that's part of
> > the Subscription/Subscriber contract.  Why would somebody POST a message
> > with a Subscriber body to a URI that didn't advertise its ability to
> > accept it (and have it mean "subscribe")?
> 
> First: you shouldn't have to know a priori whether a resource is
> subscribable. You should be able to ask it.

That's what the Subscriptions header asserts, no?  It says, "Hi, I
support being subscribed to, and here's the URI that is a container
for all of my subscriptions".

> Second: having a resource do a completely different type of action based
> on the contents of the entity body sounds like RPC to me!

Hmm, that's not what I was suggesting.

POST means "accept".  If I POST something with a Subscriber header and
get a 200 back, I know that is was accepted, not that is processed as
a subscription.  It may just have been stored as a file, who knows.
How I know that my POST means "subscribe" is because it was asserted
that the URI I was posting to was a container for subscriptions.  That's
what I thought the Subscriptions header was for.  No?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:681
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-07 16:17:16
Subject:Re: [rest-discuss] GET and notifications
Message:

Mark Baker wrote:
> 
>...
> 
> Ooh, ow, who's using GET that way?

Jeff Bone. http://groups.yahoo.com/group/rest-discuss/message/591

> I've only ever suggested using a GET that lasts for a long time.

That's why we're miscommunicating. ;)

> That's what the Subscriptions header asserts, no?  It says, "Hi, I
> support being subscribed to, and here's the URI that is a container
> for all of my subscriptions".

Yeah. You're talking about a totally different proposal than the one I
was critiquing.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:682
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-02-07 16:31:08
Subject:Re: [rest-discuss] GET and notifications
Message:

Just to be clear about what it is we're talking about:

We have more or less achieved a loose consensus on what should happen at
the sink side.  Now we're figuring out what interactions with the source
should look like.  There are two general approaches on the table.

Approach 1 is to have the GET of the watched resource contain a "notify"
flag in the headers.  This is getting the watched resource and leaving a
callback request at the same time.

Approach 2 is to have two separate transactions, one to GET the watched
resource and the other to POST to the subscription resource.








-----------------------------------------------------------------------------------
Post ID:683
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-07 16:37:26
Subject:Re: [rest-discuss] GET and notifications
Message:

Lucas Gonze wrote:
> 
> Just to be clear about what it is we're talking about:
> 
> We have more or less achieved a loose consensus on what should happen at
> the sink side.  

Very loose....I don't think we're agreed on PUT versus POST versus
NOTIFY. Plus the decision of whether subscriptions are persistent has
implications for the sync.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:684
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-07 16:49:46
Subject:Re: [rest-discuss] GET and notifications
Message:

Ok, just so I'm clear; approach 1 is evil, approach 2 is goodness. 8-)

Sorry, I haven't been keeping up with all your work.

> Just to be clear about what it is we're talking about:
> 
> We have more or less achieved a loose consensus on what should happen at
> the sink side.  Now we're figuring out what interactions with the source
> should look like.  There are two general approaches on the table.
> 
> Approach 1 is to have the GET of the watched resource contain a "notify"
> flag in the headers.  This is getting the watched resource and leaving a
> callback request at the same time.
> 
> Approach 2 is to have two separate transactions, one to GET the watched
> resource and the other to POST to the subscription resource.
> 

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:685
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-02-07 16:57:11
Subject:Re: [rest-discuss] GET and notifications
Message:

Yes, I didn't mean to pre-empt further discussion, just to say that the
there appears to be consensus on algorithm.

> Very loose....I don't think we're agreed on PUT versus POST versus
> NOTIFY. Plus the decision of whether subscriptions are persistent has
> implications for the sync.
>
>  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:686
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-07 18:21:05
Subject:Re: [rest-discuss] GET and notifications
Message:


Paul Prescod wrote:

> Jeff Bone wrote:
> >
> > All good points.  Here are some off-the-top (hopefully not over-the-top ;-)
> > thoughts about these issues...
> >
> > (1)  Side-effects.  I'm not 100% convinced its correct to view the
> > notification request behavior as a side-effect.  It doesn't actually impact
> > the content returned beyond adding a header and *later* producing an effect
> > that wouldn't exist otherwise;
>
> The server needs to change state to remember the request. That sounds
> like a side-effect to me.

Sure, sure, but there's side effects and then there's side effects.  I.e., on some
strictly literal level it's wrong to call even GET "idempotent" since resources
are actually time-varying streams of different, mutable representations, and GET
can indeed (as with counters, etc.) have some kinds of effects.

Think of the subscription in sort of the same sense as incrementing a page hit
counter.

jb








-----------------------------------------------------------------------------------
Post ID:687
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-07 18:23:17
Subject:Re: [rest-discuss] GET and notifications
Message:


Paul Prescod wrote:

> Mark Baker wrote:
> >
> >...
> >
> > Ooh, ow, who's using GET that way?
>
> Jeff Bone. http://groups.yahoo.com/group/rest-discuss/message/591

With the admission that this was offered as a straw man for discussion, and
is just a rehash of the old WD-Proxy NOTIFY stuff.

jb








-----------------------------------------------------------------------------------
Post ID:688
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-07 18:25:03
Subject:Re: [rest-discuss] GET and notifications
Message:


Paul Prescod wrote:

> Lucas Gonze wrote:
> >
> > Just to be clear about what it is we're talking about:
> >
> > We have more or less achieved a loose consensus on what should happen at
> > the sink side.
>
> Very loose....I don't think we're agreed on PUT versus POST versus
> NOTIFY. Plus the decision of whether subscriptions are persistent has
> implications for the sync.

Also note --- the WD-Proxy model supports NOTIFY on resources that aren't
actually hosted on the node that receives the notify.  I.e., even though I'm
"bar.com," if I subscribe to "foo.com/baz" then I'll get a NOTIFY
http://foo.com/baz when that resource changes.

jb









-----------------------------------------------------------------------------------
Post ID:689
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-07 18:27:12
Subject:Re: [rest-discuss] GET and notifications
Message:


Mark Baker wrote:

> Ok, just so I'm clear; approach 1 is evil, approach 2 is goodness. 8-)

Don't be quite so hasty, Mark...  after starting things out by pushing for
reification of the subscription as a resource, I re-stumbled across the
WD-Proxy stuff and discovered that there's actually some goodness lurking in
there.  Go take a look.  There's some evil as well, but some reasonably good
things worth thinking about (like 1-shot notifications, etc.)

jb









-----------------------------------------------------------------------------------
Post ID:690
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-08 02:36:48
Subject:RE: [rest-discuss] GET and notifications
Message:

I started pseudocoding both proposed designs for the interactions with the
server/source and instantly found serious problems with both.

"Model-2req" (coinage here for reasons of convenience) is the one where there
are two requests, a POST to a subscription resource and a GET to a watched
resource.  The problem with this is that it implies a transaction.  In my former
proposal on the subject I suggested that there be a GET, the GET results would
be hashed by the client in some well known way, and the hash would be
transmitted with the followup POST as a "baseline state."  The subscription
resource would decide when to fire a notification by computing its own hash of
the watched resource and compare it to the hash sent by the client.  However the
hash has to be up to the server, since GET headers often imply a view of the
object.  (By "view" I mean a transformation that is orthogonal to the underlying
content of the object.  For example the GET may have "Accept: XML-2.0", while
the base resource exists in a neutral form like a unix mbox file.)

"Model-1req" is the one where there is a single request/response that augments a
GET with a header that implies a watch.  The problem with this is that it
requires the owner of the resource to be the watcher.  That precludes all third
party watchers, whether on another host or on the same one.  If the watched
resource is a script then it has to be edited to support the notify request.  If
it is a file then the web server has to be edited with something like
mod_notify.  So deployment becomes an obstacle.

There is a solution to the problem with Model-2req.  I propose that the
subscription POST and resource GET be completely separated and the hash be
eliminated.  The subscription POST would become effective immediately.  POSTing
to it would mean "Do what you need to do to know that this resource has changed,
whether it's computing a hash or creating a database trigger."  The POST would
have to precede the GET -- otherwise there would be a race condition between the
GET and POST, and states between the time of the GET and POST could be lost.

I will post a sample set of Model-2req transactions in a separate followup
message.

- Lucas







-----------------------------------------------------------------------------------
Post ID:691
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-08 02:52:05
Subject:Model-2req design
Message:

"Model-2req" is the one where there are two requests, a POST to a subscription
resource and a GET to a watched resource.  I previously suggested that there be
a GET, the GET results would be hashed by the client in some well known way, and
the hash would be transmitted with the followup POST as a "baseline state."
However it is hard to lock the GET and POST together, because it is hard to make
a hash that the client and server can both compute independently.  If there has
to be a hash computed by the client, then the POST can't precede the GET.  If
the hash has to be computed by the server, then the GET has to return it, and
that means the watched resource has to be modified to compute and output the
hash.

The following sample set of Model-2req transactions is intended to correct these
problems.

I propose that the POST precede the GET and the hash be eliminated.  The
subscription POST would become effective immediately on reception.  POSTing to
it would mean "Do what you need to do to know that this resource has changed,
whether it's computing a hash or creating a database trigger."  Though it is
assumed that the sink will followup the POST with the GET, it is not necessary
from the perspective of the subscription resource.

Eliminating the hash opens the nice optimization that the POST request and GET
request can sometimes be precomputed and stuffed into a single packet without
waiting for the POST results to make the round trip.  As a result the efficiency
problems of having two separate round trips can sometimes be eliminated.

A sample set of Model-2req transactions:

[HEAD]

CLIENT -> SERVER
----------------------
POST [notifications Request-URI] HTTP/1.1
[TBD: stuff to say what the callback URI is]
[TBD: stuff to say what the watched resource is]
...

SERVER -> CLIENT
----------------------
200 OK
...

CLIENT -> SERVER
----------------------
GET [watched resource Request-URI] HTTP/1.1
...

SERVER -> CLIENT
----------------------
200 OK
...

[time passes]

SOURCE -> SINK
----------------------
PUT [callback Request-URI] HTTP/1.1
...

[goto HEAD]

- Lucas







-----------------------------------------------------------------------------------
Post ID:692
Sender:"as10m" <as10m@...>
Post Date/Time:2002-02-08 03:35:05
Subject:bi-directional HTTP over uni-directional standard HTTP
Message:

hi,

did anybody considered using HTTP connection as biderectional channel 
that contains *two* virtual connections:
1. standard HTTP: client request -> server response
2. opposite direction: server initiates request -> client responses
this should work just great with keep-alive for p2p situations ...

it is easy to do as HTTP distinguishes between what is request "GET 
...  HTTP1/..." and response "HTTP code message" so client can 
identify server request just based on first lisne (starts with "HTTP" 
=> response, otherwise try to interpet as request from server).

i searched web but could not find anybody doing or even considering it 
 ...

appreciate comments (and URLs)

thanks,

alek







-----------------------------------------------------------------------------------
Post ID:693
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-08 03:48:02
Subject:Re: [rest-discuss] bi-directional HTTP over uni-directional standard HTTP
Message:

Cf.  http://conveyor.com/RESTwiki/moin.cgi/SwitchboardPattern

I think that tunneling in this fashion coupled with rendezvous services is
essentially the only way to deal with asymmetrical connectivity.

jb

as10m wrote:

> hi,
>
> did anybody considered using HTTP connection as biderectional channel
> that contains *two* virtual connections:
> 1. standard HTTP: client request -> server response
> 2. opposite direction: server initiates request -> client responses
> this should work just great with keep-alive for p2p situations ...
>
> it is easy to do as HTTP distinguishes between what is request "GET
> ...  HTTP1/..." and response "HTTP code message" so client can
> identify server request just based on first lisne (starts with "HTTP"
> => response, otherwise try to interpet as request from server).
>
> i searched web but could not find anybody doing or even considering it
>  ...
>
> appreciate comments (and URLs)
>
> thanks,
>
> alek
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:694
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-08 04:55:29
Subject:Another Gestalt Moment by Captain Obvious
Message:

It occurs to me that part of the problem in reasoning about the
behavior of the Web is that the methods of HTTP are actually
methods on two different kinds of things --- resources and
representations --- and yet URI munges the two concepts together
in a rather confusing way.  And the concepts are very different:
resources are / can be state machines that generate a
time-varying stream of representations (or at least they are a
time-varying stream of representations, i.e. for static content
that evolves over time) while representations are themselves
immutable and potentially mobile data.  The net effect is that it
is difficult to name, sort out, and reason about the semantics of
representations vs. resources.

POST, PUT, DELETE, etc. operate directly on *resources* named by
URI.  When I perform one of these operations, it interacts
directly with the resource in question and yields an appropriate
response / representation of the resource.

GET, however, is more ambiguous.  In general, it operates on
*representations* of a named resource.  This may or may not imply
an interaction with said resource.  In general, GET
http://foo.com/bar means "get the first valid representation of
the resource at foo.com/bar that's lurking in the proxy chain
from here to the origin server for that resource."  I.e., GET is
really an operation that's conceptually about retrieving
representations rather than interacting with the resource in
question.

The rather fuzzy treatment of resources vs. representations is
what leads to a lot of the bletcherousness -wrt- how we handle
caching, and a lot of the cognitive dissonance that we experience
whenever we bring intermediaries into the picture.  There's power
in the fuzziness, but in general we don't have a very principled
way to deal with all of those representations that we have
floating around in caches in various places.  (We've got plenty
of tools in the various headers and so forth, but the semantics
are loose.)

This is really a sort of half-formed thought, but the distinction
seemed rather interesting.

jb








-----------------------------------------------------------------------------------
Post ID:695
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-08 05:17:10
Subject:Re: [rest-discuss] Another Gestalt Moment by Captain Obvious
Message:

> representations --- and yet URI munges the two concepts together
> in a rather confusing way.

It can be confusing until you recognize that representations can also
be resources.  That's what happens when you PUT.  But luckily this is
already accounted for in HTTP, since the Content-Location header
provides a means to identify representations as resources.

>  And the concepts are very different:
> resources are / can be state machines that generate a
> time-varying stream of representations (or at least they are a
> time-varying stream of representations, i.e. for static content
> that evolves over time) while representations are themselves
> immutable and potentially mobile data.  The net effect is that it
> is difficult to name, sort out, and reason about the semantics of
> representations vs. resources.

They are each just things with identity.  That's how I think about it.
I haven't had any trouble with that.

> POST, PUT, DELETE, etc. operate directly on *resources* named by
> URI.  When I perform one of these operations, it interacts
> directly with the resource in question and yields an appropriate
> response / representation of the resource.
> 
> GET, however, is more ambiguous.  In general, it operates on
> *representations* of a named resource.  This may or may not imply
> an interaction with said resource.  In general, GET
> http://foo.com/bar means "get the first valid representation of
> the resource at foo.com/bar that's lurking in the proxy chain
> from here to the origin server for that resource."  I.e., GET is
> really an operation that's conceptually about retrieving
> representations rather than interacting with the resource in
> question.

GET is special because it doesn't change state and therefore can have
its function distributed about the network.  Think of it this way; the
"main resource" extends its tentacles to all caches on the Web, but
controls them in a sense by how it specifies cache behaviour.  If it
knows it's going to change frequently, it will use short Expires times
to tell the caches that they have to phone home more often.  But this
policy is most definitely an attribute of the resource, not of a
representation.

Another way to think about this, is that there's a difference between
"the resource" (say, me), my representations (picture, HTML page,
vCard), and the software that manages all of that.  AFAIK, there's no
name for the software.  But I think you may be confusing the resource
with that software, by your suggestion that GET doesn't operate on
the resource.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:696
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-08 10:41:05
Subject:Re: [rest-discuss] GET and notifications
Message:

Lucas Gonze wrote:
> 
>...
> 
> "Model-2req" (coinage here for reasons of convenience) is the one where there
> are two requests, a POST to a subscription resource and a GET to a watched
> resource.  The problem with this is that it implies a transaction. 

I don't think I'll be able to understand the rest until I understand
this sentence. Could you elaborate? Or was the rest of the paragraph
elaboration?

> ...  In my former
> proposal on the subject I suggested that there be a GET, the GET results would
> be hashed by the client in some well known way, and the hash would be
> transmitted with the followup POST as a "baseline state." 

Remind me of why this is necessary? Also, is there a motivation for not
using etags or timestamps or did you just not think of that?

> .... The subscription
> resource would decide when to fire a notification by computing its own hash of
> the watched resource and compare it to the hash sent by the client. 

That's not how I see it. The subscription resource knows when the
resource changes. By definition all clients are out of date. Why keep a
per-client hash?

> ... However the
> hash has to be up to the server, since GET headers often imply a view of the
> object.  (By "view" I mean a transformation that is orthogonal to the underlying
> content of the object.  For example the GET may have "Accept: XML-2.0", while
> the base resource exists in a neutral form like a unix mbox file.)

XML is specific and mbox is neutral? Okay, whatever. ;)

Anyhow, the terminology that we've been using is representation (for
your "view") versus resource (for your "object").

I don't understand how any of this is necessary yet, though....

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:697
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-08 10:45:23
Subject:Re: [rest-discuss] GET and notifications
Message:

Jeff Bone wrote:
> 
>...
> 
> Sure, sure, but there's side effects and then there's side effects.  I.e., on some
> strictly literal level it's wrong to call even GET "idempotent" since resources
> are actually time-varying streams of different, mutable representations, and GET
> can indeed (as with counters, etc.) have some kinds of effects.
> 
> Think of the subscription in sort of the same sense as incrementing a page hit
> counter.

I knew you were going to say that. But the client supposedly doesn't
care ("much") about a page counter. A notification is extremely
important to the client. So it is a relevant side effect IMO.

I also think that Lucas makes a good point about third-party watchers.
An explicit subsription model supports that.

On the other hand, we could probably steal the idea of one-shot
notifications. There may be virtue in elevating that whole subscription
expiry crap to the application level. With each notification you attempt
to re-subscribe and if it ever fails, it fails. The application should
know why that might happen. Then Lucas doesn't get bogged down into
trying to design a query language for the union of temporal and
numerical expiries.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:698
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-08 12:33:14
Subject:RE: [rest-discuss] GET and notifications
Message:

Paul said:
> On the other hand, we could probably steal the idea of one-shot
> notifications. There may be virtue in elevating that whole subscription
> expiry crap to the application level. With each notification you attempt
> to re-subscribe and if it ever fails, it fails. The application should
> know why that might happen.

Agreed.  1-shot notifications eliminate a whole bag of problems.  They're pure
chocolatey goodness.

> Then Lucas doesn't get bogged down into
> trying to design a query language for the union of temporal and
> numerical expiries.

:)

It's just like singing in the shower always sounds good to the singer.







-----------------------------------------------------------------------------------
Post ID:699
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-08 13:21:15
Subject:RE: [rest-discuss] Model-2req design
Message:

me:
> > "Model-2req" (coinage here for reasons of convenience) is the one
> where there
> > are two requests, a POST to a subscription resource and a GET to a watched
> > resource.  The problem with this is that it implies a transaction.
>
Paul:
> I don't think I'll be able to understand the rest until I understand
> this sentence. Could you elaborate?

Ok.

The POST to the subscription resource has to have a base state to measure
against.  The base state is the last known state which should not cause a
notification to be fired.  It might be a version number, a date, a byte count,
an SHA-1 hash, whatever.  It might not even be an explicit state -- the base
state for a database trigger is just whatever the current state is.

In my post yesterday,
http://groups.yahoo.com/group/rest-discuss/message/691
I proposed that the notification resource should find out the base state on its
own, as part of handling the request for notifications.

In my previous post,
http://groups.yahoo.com/group/rest-discuss/message/640
I proposed that the base state be the one that the GET returned.  In that case
the GET and POST were a logical unit operating on the same base state.  On that
level they had to be in synch, and so could be considered a transaction.

> > ...  In my former
> > proposal on the subject I suggested that there be a GET, the GET
> results would
> > be hashed by the client in some well known way, and the hash would be
> > transmitted with the followup POST as a "baseline state."
>
> Remind me of why this is necessary? Also, is there a motivation for not
> using etags or timestamps or did you just not think of that?

Per etags and timestamps -- they fall into the general category of hash
functions that identify states.  I didn't really talk about which hash function
was optimal.  Since the whole idea of hashing may now be gone, this doesn't
matter.  The important thing is that the server needs to compute the hash,
because the client only has access to a representation.  For example the
timestamp that matters is the one the server returns.

>
> > .... The subscription
> > resource would decide when to fire a notification by computing its
> own hash of
> > the watched resource and compare it to the hash sent by the client.
>
> That's not how I see it. The subscription resource knows when the
> resource changes. By definition all clients are out of date. Why keep a
> per-client hash?

Not!  :)

I argued for a per-client hash before, and in this rev argued against it.  We
are in synch on that.

> Anyhow, the terminology that we've been using is representation (for
> your "view") versus resource (for your "object").

thx.


> I don't understand how any of this is necessary yet, though....

It's just an attempt at modeling the source interactions in detail.
...pseudo-coding them to figure out what works and what doesn't.

- Lucas







-----------------------------------------------------------------------------------
Post ID:700
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-08 14:49:30
Subject:Re: [rest-discuss] Another Gestalt Moment by Captain Obvious
Message:


Mark Baker wrote:

> > representations --- and yet URI munges the two concepts together
> > in a rather confusing way.
>
> It can be confusing until you recognize that representations can also
> be resources.  That's what happens when you PUT.  But luckily this is
> already accounted for in HTTP, since the Content-Location header
> provides a means to identify representations as resources.

I'm not sure I buy that.  It seems to me that PUT identifies a resource by
URI and provides a representation in the request body, and that
representation isn't actually a resource until the resource *at* the
indicated URI sets its state.

Another way to put it:  the only things that live at origin servers are
resources.  Everything else --- cached, in transit, etc. --- is a
representation.

> They are each just things with identity.

Yes, but they don't have unique identities --- we use the same URI to talk
about both in different contexts.  The only way these are disambiguated is
by a blend of the semantics of the particular HTTP method we're using and
the semantics of various HTTP headers in combination.

> Another way to think about this, is that there's a difference between
> "the resource" (say, me), my representations (picture, HTML page,
> vCard), and the software that manages all of that.  AFAIK, there's no
> name for the software.  But I think you may be confusing the resource
> with that software, by your suggestion that GET doesn't operate on
> the resource.

Okay, well, it's tough to talk about the software entity itself if it's
not named. ;-)  Yes, I'm referring to that as the resource, with full
understanding that the resource *stands for something.*

jb








-----------------------------------------------------------------------------------
Post ID:701
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-09 04:02:01
Subject:Batch deletes
Message:

How do you do an efficient delete of many resources by property, not
value, in the REST model? Do you have to do a POST? For
instance, if I want to delete all messages by Jeff Bone in my FoRK
mailing archive. ;)

DELETE http://www.mysite.com/FoRK/by-author/Jeff+bone

But that would only delete the *one resource* (the query), right? Not
the set of
them? 

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:702
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-09 20:33:54
Subject:Re: [rest-discuss] Batch deletes
Message:

> How do you do an efficient delete of many resources by property, not
> value, in the REST model? Do you have to do a POST? For
> instance, if I want to delete all messages by Jeff Bone in my FoRK
> mailing archive. ;)
> 
> DELETE http://www.mysite.com/FoRK/by-author/Jeff+bone
> 
> But that would only delete the *one resource* (the query), right? Not
> the set of
> them? 

Right.  You could do something like WebDav Depth to have a DELETE on
a container mean delete the subordinate resources.  But then you'd
need M-DELETE.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:703
Sender:"as10m" <as10m@...>
Post Date/Time:2002-02-10 06:59:14
Subject:Re: bi-directional HTTP over uni-directional standard HTTP
Message:

hi,

the system you described - switchborad and long lived GET may work 
but not addressed is question how such GET request would be handled
by firewall proxy that could chose to cache it ...

however my quesiton was about much simpler approach: using TCP 
connection to carry HTTP requests and responses in *both* directions 
(and as such it is extension of HTTP).

has anybody did this and have any experience? for example would it be 
tolerated by HTTP 1.1 proxy - what is it going when receives HTTP 
request instead of response - or maybe it can be somehow wrapped in 
multiple responses?

thanks,

alek

--- In rest-discuss@y..., Jeff Bone <jbone@j...> wrote:
> 
> Cf.  http://conveyor.com/RESTwiki/moin.cgi/SwitchboardPattern
> 
> I think that tunneling in this fashion coupled with rendezvous 
services is
> essentially the only way to deal with asymmetrical connectivity.
> 
> jb
> 
> as10m wrote:
> 
> > hi,
> >
> > did anybody considered using HTTP connection as biderectional 
channel
> > that contains *two* virtual connections:
> > 1. standard HTTP: client request -> server response
> > 2. opposite direction: server initiates request -> client 
responses
> > this should work just great with keep-alive for p2p situations ...
> >
> > it is easy to do as HTTP distinguishes between what is request 
"GET
> > ...  HTTP1/..." and response "HTTP code message" so client can
> > identify server request just based on first lisne (starts with 
"HTTP"
> > => response, otherwise try to interpet as request from server).
> >
> > i searched web but could not find anybody doing or even 
considering it
> >  ...
> >
> > appreciate comments (and URLs)
> >
> > thanks,
> >
> > alek
> >
> >
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@y...
> >
> >
> >
> > Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:704
Sender:"Lucas Gonze" <lucas@...>
Post Date/Time:2002-02-10 17:36:14
Subject:required headers in the notification message
Message:

About the notification message definition:
"A notification message must have the following headers:
Watched-URI: (URI of the watched resource)
Subscription-URI: URI of the subscription object"

I believe that the Watched-URI and Subscription-URI are not properly a required
part of the notification message.  In the idempotent notification model the
Subscriber URI contains the entire content of the callback.  There are several
reasons.

1) It is not properly a subscriber URI but a notification URI.  This follows
from the fact that the sink receives notifications via PUT.  If you PUT multiple
notifications to the same URI, and they contain data related to different
subscriptions, they will wipe one another out.

2) If the subscription URI in the notification is used as the callback address
for renewing/deleting/pending the subscription, or if the Watched-URI is used as
the callback address for picking up further events, then an attacker can rewrite
these headers to contain the target URI of a distributed denial of service
attack.  To prevent rewriting, the notification message would have to be either
signed or encrypted, and if the sink has to handle signed or encrypted messages,
it can't be a plain vanilla HTTP server.  So the sink MUST NOT use either the
Watched-URI or Subscription-URI as the callback address for
renewing/deleting/pending the subscription.

3) If the Watched-URI and Subscription-URI in a notification message are used by
the sink to identify the resource in question, an attacker can eavesdrop to
discover any meaningful data within those URIs.  For example the
Subscription-URI may hold enough information to modify a subscription.  If the
Subscription-URI had been obtained within the context of an HTTPS connection,
including it within an uncrypted notification message would disclose a secret.

As a general comment on security of the design, the meaning of a notification
URI is a secret shared only by the sink and source.  That meaning is
pre-arranged during requests to the subscription URI.  If that rule is
consistently followed then only one resource -- the subscription URI -- needs to
be HTTPS.

I don't mean to block off whatever the utility of the notification headers is,
though.  Explanations of the intended use of those headers would help in finding
an alternative way to meet the need...

- Lucas







-----------------------------------------------------------------------------------
Post ID:705
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-10 23:11:49
Subject:Two-phase commit in HTTP?
Message:

Obviously one does not want to lock resources on the public internet
based on a client's promise to finish a transaction that they may never
get around to finishing. Nevertheless, I can see no harm in allowing a
client to submit several requests that they would like to be executed
atomically when and if the commit message does come through. If the
message doesn't, then you just throw away the requests after a timeout.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:706
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-11 01:59:21
Subject:RFC: Part 2
Message:

The first part is at xml.com. I'd like comments on the second part to be
published later this week. Thanks in advance!
====
REST, Resource Modeling and the Real World

In the last article I described a new model for Web Services
construction. It is called REpresentational State Transfer and applies
the principles of the Web to transaction-oriented services, rather than
publishing-oriented sites. When we apply the strategy in the real world,
we do so using Web technologies such as URIs, HTTP and XML. Unlike the
current generation of Web Services technologies, however, we make those
three technologies central rather than peripheral. We rethink our web
service interface in terms of URIs, HTTP and XML. It is this rethinking
that takes our web services beyond the capabilities of the first
generation. 

In this article I want to discuss the applicability of several industry
buzzwords such as reliability, workflow, orchestration, security,
asynchrony, auditing and so forth. Intuitively, it seems that the Web
technologies are not sophisticated enough to handle the requirements for
large-scale inter-business commerce. Those who think of HTTP as a
simple, unidirectional GET and POST protocol will be especially
surprised to learn how sophisticated it can be. 

Quick Review

REST is a model for distributed computing. It is the one used by the
world's biggest distributed computing application, the Web. When applied
to web services technologies, it usually depends on a triumvirate of
technologies designed to be extremely extensible: XML, URIs and HTTP.
XML's extensibility should be obvious to this most, but the other two
may not be. 

Similarly there are an infinite possible of possible URIs. But, more
important, they can apply to an infinite number of logical entities
called "Resources". URIs are just their addresses. Some REST advocates
call the process of bringing your applications into this model Resource
Modeling. This process is not yet as formal as object oriented modeling
or entity-relation modeling but it is related to those. The strength and
flexibility of REST comes from the creative use of URIs. 

HTTP's extensibility stems primarily from the ability to distribute any
payload with predefined or new headers using predefined or (on occasion)
new methods. What makes HTTP really special among all protocols,
however, is its implicit understanding of URIs and resources. URIs are
the defining characteristic of the Web: the glue that makes it work and
scale. HTTP as a protocol keeps them front and center by defining all
methods as operations on URI-addressed resources. 

Auditing and Securing REST Web Services

The most decisive difference between web services and previous
distributed computing problems is that web services must be designed to
work across organizational boundaries. Of course, this is also one of
the defining characteristics of the Web. This difference has serious
implications with respect to security, auditing and performance. At the
core of the Web's solution to these problems is the same construct that
is at the core of the Web's solution to everything: URIs. By modeling
the right combination of resources, addressed through URIs, we can build
extremely secure systems. 

In the previous article I discussed how it is possible to use ACLs to
secure services which use URIs as their organizational model.
Administrators can apply ACLs to the service itself and to every
document that passes through the service, because each of them would
have a URI. As two business partners work their way through a process,
each step would be represented by a new document with an attached ACL.
Other partners (or auditors) could be given access to this document
later merely by manipulating the ACLs. Another model for security is
called capabilities. This less popular model is more flexible than ACLs
and is nevertheless compatible with second-generation Web Services. 

In the REST model, both business partners would have a shared view of
the URI-space representing the process. Rather than sending each other
business documents through an email-style pipe, they would put them on
mutually visible websites with shared URIs and passwords. These could be
easily checked for discrepancies. Third parties can be brought into the
process (perhaps for auditing) merely by pointing them at one or both of
the URIs. Standard HTTPS and HTTP authentication and authorization would
be sufficient to keep intruders from also being able to look at the
documents. 

Of course HTTP-based Web Services can go through firewalls easily. But
that is the only point of similarity with RPC tunnels through HTTP such
as XML-RPC or SOAP-RPC over HTTP. When you use HTTP over a firewall, you
are being very explicit about what is going on. Your system
administrator can look at her logs to determine what services are
running and who is accessing them. She can disable PUT or POST to make
certain parts of the service read-only. She can use standard filtering
and hacker detection tools. When you use HTTP you and the system
administrator are on the same team. 

Conversely, when you tunnel XML-RPC or SOAP through a firewall, you are
deliberately subverting her work and reducing the efficacy of her tools.
Because you are hiding your real actions in the XML body, you make it
much harder for her to use standard filtering tools. This greatly
expands the opportunity for new security holes! 

Service Context

People building web services often complain that the "tricky bit" of web
services is maintaining shared context. For instance, context might
include: 

Where are we in this business process? 
What transactions have we done in the past? 
Are there any resources that I promise to hold for you? 
Are there any notifications I promise to deliver to you later? 
What permissions do you have? 

There are three main ways that two partners can share context. One is to
send the entire context with every message. This is obviously not very
scalable. As the relationship deepens the context will grow larger and
larger. Another option is to merely require each partner to keep context
privately and presume that the other partner has the same idea of
context. As you can imagine, this is quite unreliable. A network hiccup
or programming bug could make the contexts diverge. The mechanism used
on the Web today is to assign URIs to the context. For instance on
Expedia there is a "My Itinerary" URI for each individual. Within that,
every purchase you have recently made has its own URI. While you are
purchasing a new ticket, each step in the process is represented by
another URI. 

The same principle applies to business-to-business processes. Of course
there will be some differences. Typically the canonical format for
context in a business process with be XML. HTML will be generated as a
view on that XML. But do not underestimate the importance of that
human-readable view! Business partners will probably be careful to store
a copy of the context in case of network outage, programming bug or
outright fraud.

This is precisely what the HTTP and the REST model were designed to
allow. Remember that REST stands for REpresentational State Transfer.
The HTTP client transfers the state (the context) from the server to the
client using a representation like XML or HTML (depending on its needs).
Context information can be linked together with XLink or RDF. Each bit
of it can be individually secured using ACLs or capabilities. This
mechanism for handling context seems so obvious to me as to be near
inevitable. 

Orchestration

Every method that can be invoked on a resource or service is a possible
connector between the client and the service. If there are a hundred
methods then there are a hundred connectors. If every service has a
hundred different methods then your connections become very complex -
essentially point-to-point integrations rather than reusable patterns. 

There are various systems in the computing world that have proven the
power of having just a few methods rather than many. For instance, every
true Unix hacker knows that the command line is incredibly powerful
because it is possible to pipe data from one process to another using
the redirection "methods", ">", ">>", "<". The other Unix command line
tools act as standardized filters and transformers connected by these
methods. 

Similarly, if you think of a SQL table as a resource, the methods SQL
makes available are only SELECT, UPDATE, INSERT and DELETE. The rest of
SQL is a set of transformers and filters that allow you to combine these
methods into services. .NET My Services has Query, Insert, Replace,
Update and Delete. As I showed in the last article, UDDI has get_*,
delete_* and save_*. This pattern is ubiquitous. 

HTTP has GET, PUT, POST and DELETE. Anything that can be done with SOAP
RPC or any other RPC can be done with those four methods. In fact, it is
precisely because HTTP has few methods that HTTP clients and servers can
grow and be extended independently without confusing each other. Rather
than invent new methods they find ways to represent new concepts in data
structures (increasingly XML data structures) and headers. 

Now that we've boiled down our system to these basic methods, it turns
out that we have the beginnings of a web service coordination,
orchestration and assembly language. I could imagine defining a new web
service as easily as: 

i = GET http://www.stockquotes.com/xmlquotes?IBM 
m = GET http://www.stockquotes.com/xmlquotes?MSFT 
if i > m:
    WITH AUTHENTICATION $myuserid $mypassword 
    POST http://www.etrade.com/stocks/IBM  
else: 
    POST http://www.etrade.com/stocks/MSFT  
 
Or maybe we don't need a new language. Perhaps we could incorporate
these principles into existing scripting languages. The point is that
unifying the method vocabulary of the web provides tremendous
opportunities for simplifying interactions. Nobody learning a new web
service would ever have to learn the semantics of the various methods
again. Web services can be combined through simple Unix-style pipes: GET
this, GET that, transform, PUT there. 

Of course there is no free lunch. Using someone else's web service
requires you to understand their data structures (XML vocabulary and
links between documents). But this is true whether we use REST or SOAP
RPC. RPC APIs merely hide the problem behind an extra layer of
non-standardization. First you must figure out the method names
available. Then you must still figure out the data structures that may
be used as parameters. And then behind those data structures is the
implicit data model of the web service. UDDI has an implicit relational
data model. .NET My Services has a concept of a "virtual document". The
whole thing would be simpler if the implicit data model was directly
exposed as XML documents available as URI-addressed resources through
HTTP. This in no way dictates the underlying implementation but it is
based upon a shared, web-wide data model that allows for easy
coordination! 

Once you begin to orchestrate multiple web services, transaction
processing becomes much harder. HTTP does not have a magical solution to
this problem but neither do specifications such as SOAP or ebXML. The
solutions proposed by the OASIS Business Transactions working group are
currently protocol agnostic and should work fine with HTTP, once a
binding is formalized. A more complete analysis of their integration
with REST would be an interesting project, but it has not been done yet.

Asynchrony

People often complain that HTTP is not asynchronous. Unfortunately they
often mean different things by that term. Most often they compare it to
SMTP as an example of an asynchronous protocol. But you could make the
case that both are synchronous or asynchronous depending on how you
define those terms. Both are synchronous in that you cannot send a
message without waiting for a reply from the server. If an SMTP server
application is badly written, it can hold a connection open for hours,
just as a badly written HTTP web service might. Similarly, both can be
considered asynchronous in the sense that servers (HTTP or SMTP) never
know when they will get a request from a client. Requests are not
coordinated in advance. If one HTTP server makes a request to another
then it is exactly as synchronous or asynchronous as one SMTP server
making a request to another. 

Email is asynchronous not primarily because of SMTP itself, but the
collection of software that does store-and-forward, failure notification
and replies. In an XML web services world, much of this must be
rewritten to deal with URIs so as to manage shared context. For
instance, every message that passes through a web service should
probably be given a persistent HTTP URI for auditing purposes.
Similarly, the reply-to header should refer to an HTTP resource, not an
email address. Although early web services will of course build on
whatever software is already available, the vast majority of it will be
written from scratch. I feel that it would make little sense to spend
the effort adapting a non-Web integrated protocol like SMTP to the Web
rather than merely using HTTP. 

Still, it would require extensions to HTTP to offer all of the features
of SMTP (in addition to HTTP's own unique features). Primarily, HTTP
needs a concept of "callback" or "notification". Although this has been
done many times in many places, there is no single standardized way to
do this. Software dealing with notifications is not as reusable as other
HTTP-based software modules. There is work under progress to correct
this situation, under the name "HTTPEvents". Second, HTTP needs concepts
of explicit and implicit store and forward relays, transformational
intermediaries and return paths. These may be borrowed from SOAP headers
and SOAP Routing. In fact, some REST proponents believe that this is the
only part of SOAP that is strongly compatible with the Web and HTTP. 

In summary, various kinds of asynchrony are certainly possible in HTTP.
Many commercial applications have been built using HTTP in a
peer-to-peer, asynchronous fashion, by companies as large as Microsoft
to as small as KnowNow. But there is active effort standardizing the
approach taken on the REST list. 

Reliability

Networks are inherently unreliable and the Internet is an extreme case
of this. You must build network-based software to cope with failure no
matter what protocol you are using. Nevertheless, a combination of
software and protocols can make message delivery more reliable than it
would otherwise be. What most people ask for is that a message be
delivered if at all possible, and be delivered at most once. If it is
not possible to deliver then it should be reported to the application. 

Writing reliable-delivery software with HTTP is relatively easy. Thanks
to the guarantees of TCP, you can always know for sure if you received
an appropriate response. If you did not, then in many cases it is safe
to repeat the message send, due to the principle of idempotency. In
other cases it takes a slight permutation of the service to make it one
that builds upon idempotency. Although this is not rocket science, a
full description does take more than a couple of paragraphs. 

The bottom line is that software written on top of HTTP can make all of
the same guarantees that expensive message queuing software can. Once
you have done that, the only difference is that the message queuing
software builds reliability around a proprietary protocol that cannot
(typically) be used between business partners! If you would like to use
the message queuing software within your single organization then you
can easily tunnel HTTP on top of it and get the best of both worlds. 

Case Studies

Despite its advantages, HTTP-based, URI-centric resource modeling is not
a common way of thinking about networking issues and REST-based web
services are not very common. On the other hand, useful, scalable,
public RPC-based web services are also quite difficult to find. The most
obvious examples of HTTP-based web services are actual web sites. Any
site that presents a purchasing process as a series of web pages can
trivially be changed to do the same thing with XML. People who go
through this process get all of the benefits of REST web services and
none of the expense of re-implementing their business logic around a
SOAP-RPC model. 

Two businesses that have created (admittedly simple) REST web services
are Google and O'Reilly. Google offers to its subscribers the ability to
have search results published as XML rather than HTML. This makes it
easy to build various sorts of sophisticated programs on top of Google
without worrying about shifting HTML formats. Unfortunately the public
version of Google no longer supports the XML feature. Presumably there
was some danger it would undermine the banner-based business model!
Nevertheless, REST was a natural fit for Google. Essentially all they
had to do was change their HTML generating code to XML and they had a
Web Service instead of a Web Site. 

The Meerkat Example

O'Reilly's Meerkat is one of a very few useful, public web services.
Unlike the majority of the services described on XMethods, Meerkat is
used by thousands of sites every single day. 

Meerkat uses the three foundation technologies of second-generation web
services. It uses a standardized XML vocabulary: RSS. Meerkat would
never have become as powerful and scalable if it had invented its own
vocabulary. It absolutely depends on the fact that it can integrate
information from hundreds of sites that use the RSS vocabulary and the
HTTP protocol. 

In addition to using HTTP and RSS, Meerkat uses URIs as its addressing
scheme. It has a very sophisticated URI-based "API" described here:
http://www.oreillynet.com/pub/a/rss/2000/05/09/meerkat_api.html 

Meerkat's content is also available through an XML-RPC API described in
http://www.xml.com/pub/a/2001/07/18/excerpt/xml-rpc.html. Before the
REST philosophy was popularized it was not clear that Meerkat's
HTTP/XML-based interface was already a complete web service! It would be
an interesting project to compare and contrast these two interfaces in a
formal essay. 

One interesting point, however, is that all of Meerkat's content
aggregation is done through HTTP, not XML-RPC or SOAP. It would be
ludicrous to suggest that every content publisher in the world should
not only support XML-RPC and SOAP but also some particular set of
methods. This would be the situation if instead of inventing the RSS
vocabulary the world had standardized the "RSS web service interface." 

To be fair, HTTP's advantages would have been less pronounced if
Meerkat's interaction with these sites had required two-way
communication instead of a simple one-way information fetch.
Nevertheless, there is nothing particularly difficult about using HTTP
in a two-way fashion. It is a virtue of HTTP that it is much easier than
other models for one-way ("data publishing") services and not much
harder to use for bi-directional, transactional services. 

Meerkat shows that when many sites share an XML vocabulary, a protocol
and a URI namespace, new services arise organically. It is arguably the
first equivalent in the Web Services world to a large-scale, distributed
service like Yahoo. Meerkat's success suggests strongly that the most
important enabler of large-scale, distributed web services will be
common XML vocabularies. 

REST limitations

There is no free lunch. REST is not a panacea. The biggest problem most
will have with REST is that it requires you to rethink your problem in
terms of manipulations of addressable resources instead of method calls
to a component. Of course you may actually implement it on the server
side however you want. But the API you communicate to your clients
should be in terms of HTTP manipulations on XML documents addressed by
URIs, not in terms of method calls with parameters. 

Your customers may well prefer a component-based interface to a REST
interface. Programmers are more used to APIs and APIs are better
integrated into existing programming languages. For client-side
programmers, REST is somewhat of a departure although for server-side
programmers it is not much different than what they have been doing for
the last several years. 

The client side may get easier in the future. It may be possible to use
WSDL to map URIs to logical operations that can in turn be mapped to
method calls in a programming language. Although this is described in
the WSDL specification, implementations of this feature are few and far
between. Even so, RPC will likely always be easier than REST. If a
particular problem can be solved with RPC and future extensibility is
not an issue then you should certainly use the simpler approach. 

HTTP is also not appropriate in some circumstances. Because HTTP runs on
top of TCP, it can have high latency. HTTP is designed primarily for the
kind of coarse-grained interactions that are used on the public
internet, not the kind of fine-grained ones that might be appropriate on
a single desktop, within a department or even in certain enterprise
situations. Once again, if DCOM or CORBA solves your fine-grained
problem then there is no reason to move to REST. In my opinion, REST
will dominate primarily in the world of partner-facing, external Web
Services. 

Why REST is the next Generation

Let's say that ACME Inc sets up a major web service (like UDDI) using
the SOAP RPC philosophy. BARTEL Inc. sets up a competing web service
using the HTTP philosophy. Customers will gravitate to the REST-based
one because it will be simpler on almost every measurable axis: message
size, message complexity, number of concepts (URI versus a dozen other
naming schemes) and compatibility with their existing systems. The
service can be automatically and instantly accessible from any device
that can do HTTP and XML. The Context Problem will be much more
tractable. Management will appreciate the service's ease of maintenance,
testing and security. 

But REST will really win out over the long term when the two services
try to evolve. The REST-based service uses the most flexible naming and
addressing scheme ever invented. It can instantly incorporate a
peer-to-peer model by allowing references to data on PCs. When they
invent a way to make data on cell phones URI-addressable, every cell
phone will be able to integrate data with the service. 

The rhetoric around web services describes them as "like the web, but
for machine to machine communications". They are said to be a mechanism
for publishing processes as the Web published data. REST turns the
rhetoric into reality. With REST you really do think of Web Services as
a means of publishing information, components and processes. And you
really do use the technologies and architecture that make the Web so
effective.






-----------------------------------------------------------------------------------
Post ID:707
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-11 03:42:30
Subject:Re: [rest-discuss] RFC: Part 2
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>


> The first part is at xml.com. I'd like comments on the second part to be
> published later this week. Thanks in advance!
> ====
> REST, Resource Modeling and the Real World
>
> In the last article I described a new model for Web Services
> construction. It is called REpresentational State Transfer and applies
> the principles of the Web to transaction-oriented services, rather than
> publishing-oriented sites. When we apply the strategy in the real world,
> we do so using Web technologies such as URIs, HTTP and XML. Unlike the
> current generation of Web Services technologies, however, we make those
> three technologies central rather than peripheral. We rethink our web
> service interface in terms of URIs, HTTP and XML. It is this rethinking
> that takes our web services beyond the capabilities of the first
> generation.
>
> In this article I want to discuss the applicability of several industry
> buzzwords such as reliability, workflow, orchestration, security,
> asynchrony, auditing and so forth. Intuitively, it seems that the Web
> technologies are not sophisticated enough to handle the requirements for
> large-scale inter-business commerce. Those who think of HTTP as a
> simple, unidirectional GET and POST protocol will be especially
> surprised to learn how sophisticated it can be.
>
> Quick Review
>
> REST is a model for distributed computing. It is the one used by the
> world's biggest distributed computing application, the Web. When applied
> to web services technologies, it usually depends on a triumvirate of
[mike] 'triumvirate' - quite the ten-dollar word, how about 'trio'

> technologies designed to be extremely extensible: XML, URIs and HTTP.
> XML's extensibility should be obvious to this most, but the other two
> may not be.
>
> Similarly there are an infinite possible of possible URIs.
[mike] Similarly to what?

> But, more
> important, they can apply to an infinite number of logical entities
> called "Resources". URIs are just their addresses.
[mike] it'd be neat to have a 'sidebar' talking about 'names .vs. addresses'

> Some REST advocates
> call the process of bringing your applications into this model Resource
> Modeling. This process is not yet as formal as object oriented modeling
> or entity-relation modeling but it is related to those. The strength and
> flexibility of REST comes from the creative use of URIs.
[mike] 'creative' implies un-designed, how about 'consistent' or 'strong' or
'intelligent' or something positive.

>
> HTTP's extensibility stems primarily from the ability to distribute any
> payload with predefined or new headers using predefined or (on occasion)
> new methods. What makes HTTP really special among all protocols,
> however, is its implicit understanding of URIs and resources.
[mike] is it 'implicit understanding' or 'central focus'/whatever?

> URIs are
> the defining characteristic of the Web: the glue that makes it work and
> scale. HTTP as a protocol keeps them front and center by defining all
> methods as operations on URI-addressed resources.
>
> Auditing and Securing REST Web Services
>
> The most decisive difference between web services and previous
> distributed computing problems is that web services must be designed to
> work across organizational boundaries. Of course, this is also one of
> the defining characteristics of the Web. This difference has serious
> implications with respect to security, auditing and performance. At the
> core of the Web's solution to these problems is the same construct that
> is at the core of the Web's solution to everything: URIs. By modeling
> the right combination of resources, addressed through URIs, we can build
> extremely secure systems.
>
> In the previous article I discussed how it is possible to use ACLs to
> secure services which use URIs as their organizational model.
> Administrators can apply ACLs to the service itself and to every
> document that passes through the service, because each of them would
> have a URI. As two business partners work their way through a process,
> each step would be represented by a new document with an attached ACL.
> Other partners (or auditors) could be given access to this document
> later merely by manipulating the ACLs. Another model for security is
> called capabilities. This less popular model is more flexible than ACLs
[mike] popular -> prevalent (it isn't as widely known, so 'popularity' isn't
quite correct - KragenS might be able to provide more detail on how it ties
in with ReST)

> and is nevertheless compatible with second-generation Web Services.
>
> In the REST model, both business partners would have a shared view of
> the URI-space representing the process. Rather than sending each other
> business documents through an email-style pipe, they would put them on
> mutually visible websites with shared URIs and passwords. These could be
> easily checked for discrepancies. Third parties can be brought into the
> process (perhaps for auditing) merely by pointing them at one or both of
> the URIs. Standard HTTPS and HTTP authentication and authorization would
> be sufficient to keep intruders from also being able to look at the
> documents.
>
> Of course HTTP-based Web Services can go through firewalls easily. But
> that is the only point of similarity with RPC tunnels through HTTP such
[mike] 'rpc tunnels through http' -> 'rpc tunneling through http' ('tunnel'
is both verb and noun, would be nice to clarify)

> as XML-RPC or SOAP-RPC over HTTP. When you use HTTP over a firewall, you
> are being very explicit about what is going on. Your system
> administrator can look at her logs to determine what services are
[mike] 'her' -> 'the' (overly p.c. is distracting for me...)

> running and who is accessing them. She can disable PUT or POST to make
> certain parts of the service read-only. She can use standard filtering
> and hacker detection tools. When you use HTTP you and the system
> administrator are on the same team.
>
> Conversely, when you tunnel XML-RPC or SOAP through a firewall, you are
> deliberately subverting her work and reducing the efficacy of her tools.
> Because you are hiding your real actions in the XML body, you make it
> much harder for her to use standard filtering tools. This greatly
> expands the opportunity for new security holes!
>
> Service Context
>
> People building web services often complain that the "tricky bit" of web
> services is maintaining shared context. For instance, context might
> include:
>
> Where are we in this business process?
> What transactions have we done in the past?
> Are there any resources that I promise to hold for you?
> Are there any notifications I promise to deliver to you later?
> What permissions do you have?
>
> There are three main ways that two partners can share context. One is to
> send the entire context with every message. This is obviously not very
> scalable. As the relationship deepens the context will grow larger and
> larger. Another option is to merely require each partner to keep context
> privately and presume that the other partner has the same idea of
> context. As you can imagine, this is quite unreliable. A network hiccup
> or programming bug could make the contexts diverge. The mechanism used
> on the Web today is to assign URIs to the context. For instance on
> Expedia there is a "My Itinerary" URI for each individual. Within that,
> every purchase you have recently made has its own URI. While you are
> purchasing a new ticket, each step in the process is represented by
> another URI.
>
> The same principle applies to business-to-business processes. Of course
> there will be some differences. Typically the canonical format for
> context in a business process with be XML. HTML will be generated as a
> view on that XML. But do not underestimate the importance of that
> human-readable view! Business partners will probably be careful to store
> a copy of the context in case of network outage, programming bug or
> outright fraud.
>
> This is precisely what the HTTP and the REST model were designed to
> allow. Remember that REST stands for REpresentational State Transfer.
> The HTTP client transfers the state (the context) from the server to the
> client using a representation like XML or HTML (depending on its needs).
> Context information can be linked together with XLink or RDF.
[mike] A bit esoteric a bit quick for the typical crowd - may need to start
slow with just mentioning 'urls' and 'href' attributes, and get into
XLink/XPointer/etc later (I don't know how RDF is a linking enabler..)

> Each bit
> of it can be individually secured using ACLs or capabilities. This
> mechanism for handling context seems so obvious to me as to be near
> inevitable.
>
> Orchestration
>
> Every method that can be invoked on a resource or service is a possible
> connector between the client and the service. If there are a hundred
> methods then there are a hundred connectors. If every service has a
> hundred different methods then your connections become very complex -
> essentially point-to-point integrations rather than reusable patterns.
>
> There are various systems in the computing world that have proven the
> power of having just a few methods rather than many. For instance, every
> true Unix hacker knows that the command line is incredibly powerful
> because it is possible to pipe data from one process to another using
> the redirection "methods", ">", ">>", "<". The other Unix command line
> tools act as standardized filters and transformers connected by these
> methods.
>
> Similarly, if you think of a SQL table as a resource, the methods SQL
> makes available are only SELECT, UPDATE, INSERT and DELETE. The rest of
> SQL is a set of transformers and filters that allow you to combine these
> methods into services. .NET My Services has Query, Insert, Replace,
> Update and Delete. As I showed in the last article, UDDI has get_*,
> delete_* and save_*. This pattern is ubiquitous.
[mike] 'this pattern is ...' -> 'this pattern of a small number of methods
on a large amount of data is ...' (can't hurt to re-iterate the point of
rest)

>
> HTTP has GET, PUT, POST and DELETE. Anything that can be done with SOAP
> RPC or any other RPC can be done with those four methods. In fact, it is
> precisely because HTTP has few methods that HTTP clients and servers can
> grow and be extended independently without confusing each other. Rather
> than invent new methods they find ways to represent new concepts in data
> structures (increasingly XML data structures) and headers.
>
> Now that we've boiled down our system to these basic methods, it turns
> out that we have the beginnings of a web service coordination,
> orchestration and assembly language. I could imagine defining a new web
> service as easily as:
>
> i = GET http://www.stockquotes.com/xmlquotes?IBM
> m = GET http://www.stockquotes.com/xmlquotes?MSFT
> if i > m:
>     WITH AUTHENTICATION $myuserid $mypassword
>     POST http://www.etrade.com/stocks/IBM
> else:
>     POST http://www.etrade.com/stocks/MSFT
>
> Or maybe we don't need a new language. Perhaps we could incorporate
> these principles into existing scripting languages. The point is that
> unifying the method vocabulary of the web provides tremendous
> opportunities for simplifying interactions. Nobody learning a new web
> service would ever have to learn the semantics of the various methods
> again. Web services can be combined through simple Unix-style pipes: GET
> this, GET that, transform, PUT there.
>
> Of course there is no free lunch. Using someone else's web service
> requires you to understand their data structures (XML vocabulary and
> links between documents). But this is true whether we use REST or SOAP
> RPC. RPC APIs merely hide the problem behind an extra layer of
> non-standardization. First you must figure out the method names
> available. Then you must still figure out the data structures that may
> be used as parameters. And then behind those data structures is the
> implicit data model of the web service. UDDI has an implicit relational
> data model. .NET My Services has a concept of a "virtual document".
[mike] 'virtual document'? really? I gotta check that out...

> The
> whole thing would be simpler if the implicit data model was directly
> exposed as XML documents available as URI-addressed resources through
> HTTP. This in no way dictates the underlying implementation but it is
> based upon a shared, web-wide data model that allows for easy
> coordination!
>
> Once you begin to orchestrate multiple web services, transaction
> processing becomes much harder. HTTP does not have a magical solution to
> this problem but neither do specifications such as SOAP or ebXML. The
> solutions proposed by the OASIS Business Transactions working group are
> currently protocol agnostic and should work fine with HTTP, once a
> binding is formalized. A more complete analysis of their integration
> with REST would be an interesting project, but it has not been done yet.
>
> Asynchrony
>
> People often complain that HTTP is not asynchronous. Unfortunately they
> often mean different things by that term. Most often they compare it to
> SMTP as an example of an asynchronous protocol. But you could make the
> case that both are synchronous or asynchronous depending on how you
> define those terms. Both are synchronous in that you cannot send a
> message without waiting for a reply from the server. If an SMTP server
> application is badly written, it can hold a connection open for hours,
> just as a badly written HTTP web service might. Similarly, both can be
> considered asynchronous in the sense that servers (HTTP or SMTP) never
> know when they will get a request from a client.
[mike] 'get' -> 'receive' (get might imply proactive processing or polling)

>  Requests are not
> coordinated in advance. If one HTTP server makes a request to another
> then it is exactly as synchronous or asynchronous as one SMTP server
> making a request to another.
>
> Email is asynchronous not primarily because of SMTP itself, but the
> collection of software that does store-and-forward, failure notification
> and replies. In an XML web services world, much of this must be
> rewritten to deal with URIs so as to manage shared context. For
> instance, every message that passes through a web service should
> probably be given a persistent HTTP URI for auditing purposes.
> Similarly, the reply-to header should refer to an HTTP resource, not an
> email address. Although early web services will of course build on
> whatever software is already available, the vast majority of it will be
> written from scratch. I feel that it would make little sense to spend
> the effort adapting a non-Web integrated protocol like SMTP to the Web
> rather than merely using HTTP.
>
> Still, it would require extensions to HTTP to offer all of the features
> of SMTP (in addition to HTTP's own unique features). Primarily, HTTP
> needs a concept of "callback" or "notification". Although this has been
> done many times in many places, there is no single standardized way to
> do this. Software dealing with notifications is not as reusable as other
> HTTP-based software modules. There is work under progress to correct
> this situation, under the name "HTTPEvents". Second, HTTP needs concepts
> of explicit and implicit store and forward relays, transformational
> intermediaries and return paths. These may be borrowed from SOAP headers
> and SOAP Routing. In fact, some REST proponents believe that this is the
> only part of SOAP that is strongly compatible with the Web and HTTP.
>
> In summary, various kinds of asynchrony are certainly possible in HTTP.
> Many commercial applications have been built using HTTP in a
> peer-to-peer, asynchronous fashion, by companies as large as Microsoft
> to as small as KnowNow. But there is active effort standardizing the
> approach taken on the REST list.
>
> Reliability
>
> Networks are inherently unreliable and the Internet is an extreme case
> of this. You must build network-based software to cope with failure no
> matter what protocol you are using. Nevertheless, a combination of
> software and protocols can make message delivery more reliable than it
> would otherwise be. What most people ask for is that a message be
> delivered if at all possible, and be delivered at most once. If it is
> not possible to deliver then it should be reported to the application.
>
> Writing reliable-delivery software with HTTP is relatively easy. Thanks
> to the guarantees of TCP, you can always know for sure if you received
> an appropriate response. If you did not, then in many cases it is safe
> to repeat the message send, due to the principle of idempotency.
[mike] another sidebar with concrete examples and 'idempotency' would be
good here...

> In
> other cases it takes a slight permutation of the service to make it one
> that builds upon idempotency. Although this is not rocket science, a
> full description does take more than a couple of paragraphs.
>
> The bottom line is that software written on top of HTTP can make all of
> the same guarantees that expensive message queuing software can. Once
> you have done that, the only difference is that the message queuing
> software builds reliability around a proprietary protocol that cannot
> (typically) be used between business partners! If you would like to use
> the message queuing software within your single organization then you
> can easily tunnel HTTP on top of it and get the best of both worlds.
>
> Case Studies
>
> Despite its advantages, HTTP-based, URI-centric resource modeling is not
> a common way of thinking about networking issues and REST-based web
> services are not very common. On the other hand, useful, scalable,
> public RPC-based web services are also quite difficult to find. The most
> obvious examples of HTTP-based web services are actual web sites. Any
> site that presents a purchasing process as a series of web pages can
> trivially be changed to do the same thing with XML. People who go
> through this process get all of the benefits of REST web services and
> none of the expense of re-implementing their business logic around a
> SOAP-RPC model.
>
> Two businesses that have created (admittedly simple) REST web services
> are Google and O'Reilly. Google offers to its subscribers the ability to
> have search results published as XML rather than HTML.  This makes it
> easy to build various sorts of sophisticated programs on top of Google
> without worrying about shifting HTML formats. Unfortunately the public
> version of Google no longer supports the XML feature. Presumably there
> was some danger it would undermine the banner-based business model!
> Nevertheless, REST was a natural fit for Google. Essentially all they
> had to do was change their HTML generating code to XML and they had a
> Web Service instead of a Web Site.
>
> The Meerkat Example
>
> O'Reilly's Meerkat is one of a very few useful, public web services.
> Unlike the majority of the services described on XMethods, Meerkat is
> used by thousands of sites every single day.
>
> Meerkat uses the three foundation technologies of second-generation web
> services. It uses a standardized XML vocabulary: RSS. Meerkat would
> never have become as powerful and scalable if it had invented its own
> vocabulary. It absolutely depends on the fact that it can integrate
> information from hundreds of sites that use the RSS vocabulary and the
> HTTP protocol.
>
> In addition to using HTTP and RSS, Meerkat uses URIs as its addressing
> scheme. It has a very sophisticated URI-based "API" described here:
> http://www.oreillynet.com/pub/a/rss/2000/05/09/meerkat_api.html
>
> Meerkat's content is also available through an XML-RPC API described in
> http://www.xml.com/pub/a/2001/07/18/excerpt/xml-rpc.html. Before the
> REST philosophy was popularized it was not clear that Meerkat's
> HTTP/XML-based interface was already a complete web service! It would be
> an interesting project to compare and contrast these two interfaces in a
> formal essay.
>
> One interesting point, however, is that all of Meerkat's content
> aggregation is done through HTTP, not XML-RPC or SOAP. It would be
> ludicrous to suggest that every content publisher in the world should
> not only support XML-RPC and SOAP but also some particular set of
> methods. This would be the situation if instead of inventing the RSS
> vocabulary the world had standardized the "RSS web service interface."
>
> To be fair, HTTP's advantages would have been less pronounced if
> Meerkat's interaction with these sites had required two-way
> communication instead of a simple one-way information fetch.
> Nevertheless, there is nothing particularly difficult about using HTTP
> in a two-way fashion. It is a virtue of HTTP that it is much easier than
> other models for one-way ("data publishing") services and not much
> harder to use for bi-directional, transactional services.
>
> Meerkat shows that when many sites share an XML vocabulary, a protocol
> and a URI namespace, new services arise organically. It is arguably the
> first equivalent in the Web Services world to a large-scale, distributed
> service like Yahoo. Meerkat's success suggests strongly that the most
> important enabler of large-scale, distributed web services will be
> common XML vocabularies.
>
> REST limitations
>
> There is no free lunch. REST is not a panacea. The biggest problem most
> will have with REST is that it requires you to rethink your problem in
> terms of manipulations of addressable resources instead of method calls
> to a component. Of course you may actually implement it on the server
> side however you want. But the API you communicate to your clients
> should be in terms of HTTP manipulations on XML documents addressed by
> URIs, not in terms of method calls with parameters.
>
> Your customers may well prefer a component-based interface to a REST
> interface. Programmers are more used to APIs and APIs are better
> integrated into existing programming languages. For client-side
> programmers, REST is somewhat of a departure although for server-side
> programmers it is not much different than what they have been doing for
> the last several years.
>
> The client side may get easier in the future. It may be possible to use
> WSDL to map URIs to logical operations that can in turn be mapped to
> method calls in a programming language. Although this is described in
> the WSDL specification, implementations of this feature are few and far
> between. Even so, RPC will likely always be easier than REST. If a
> particular problem can be solved with RPC and future extensibility is
> not an issue then you should certainly use the simpler approach.
[mike] 'use' -> 'consider' (don't recommend an approach that is short term
and non-interoperable)

>
> HTTP is also not appropriate in some circumstances. Because HTTP runs on
> top of TCP, it can have high latency.
[mike] 'high' is relative, give some concrete numbers so people don't make
decisions based on the wrong assumptions

> HTTP is designed primarily for the
> kind of coarse-grained interactions that are used on the public
> internet, not the kind of fine-grained ones that might be appropriate on
> a single desktop, within a department or even in certain enterprise
> situations. Once again, if DCOM or CORBA solves your fine-grained
> problem then there is no reason to move to REST. In my opinion, REST
> will dominate primarily in the world of partner-facing, external Web
> Services.
>
> Why REST is the next Generation
>
> Let's say that ACME Inc sets up a major web service (like UDDI) using
> the SOAP RPC philosophy. BARTEL Inc. sets up a competing web service
> using the HTTP philosophy. Customers will gravitate to the REST-based
> one because it will be simpler on almost every measurable axis: message
> size, message complexity, number of concepts (URI versus a dozen other
> naming schemes) and compatibility with their existing systems. The
> service can be automatically and instantly accessible from any device
> that can do HTTP and XML. The Context Problem will be much more
> tractable. Management will appreciate the service's ease of maintenance,
> testing and security.
>
> But REST will really win out over the long term when the two services
> try to evolve. The REST-based service uses the most flexible naming and
> addressing scheme ever invented. It can instantly incorporate a
> peer-to-peer model by allowing references to data on PCs. When they
> invent a way to make data on cell phones URI-addressable, every cell
> phone will be able to integrate data with the service.
>
> The rhetoric around web services describes them as "like the web, but
> for machine to machine communications". They are said to be a mechanism
> for publishing processes as the Web published data. REST turns the
> rhetoric into reality. With REST you really do think of Web Services as
> a means of publishing information, components and processes. And you
> really do use the technologies and architecture that make the Web so
> effective.
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:708
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-11 06:43:35
Subject:Re: [rest-discuss] Two-phase commit in HTTP?
Message:

> Obviously one does not want to lock resources on the public internet
> based on a client's promise to finish a transaction that they may never
> get around to finishing. Nevertheless, I can see no harm in allowing a
> client to submit several requests that they would like to be executed
> atomically when and if the commit message does come through. If the
> message doesn't, then you just throw away the requests after a timeout.

2PC is one form of implementing transactions between disparate parties,
but it's not the only way.  So assuming you just want some notion of a
"transaction", there's a number of options.  It also depends how much
of "ACID" you need.  I recall that even in SQL92, they broke down some
of the transaction opacity that was prevalent in 89.

As I mentioned offline, I had at one time considered a CHECKPOINT/
RESTORE method pair, where you'd get an etag like thing that
represented the resource's state at some point in time.  RESTORE with
this tag would return to the resource to that state with the intention
of rolling back everything since the time it was created ... unless it
didn't want to.

I think there's lots of interesting work to be done there.  I haven't
had much interest in transactional systems for some time, but I know
lots of people do. 8-)

I figure that any general solution to this problem will have to look a
lot like a compensating transaction, where you make your best effort to
fix stuff up, but if that doesn't work, you manage it as part of your
app, in the same way you manage 5xx errors with HTTP.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:709
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-11 17:48:00
Subject:Re: [rest-discuss] RFC: Part 2
Message:

"S. Mike Dierken" wrote:
> 
> [mike] 'triumvirate' - quite the ten-dollar word, how about 'trio'

Fine.

> > technologies designed to be extremely extensible: XML, URIs and HTTP.
> > XML's extensibility should be obvious to this most, but the other two
> > may not be.
> >
> > Similarly there are an infinite possible of possible URIs.
> [mike] Similarly to what?

Similarly URIs are extensible. I'll clarify that.

> > But, more
> > important, they can apply to an infinite number of logical entities
> > called "Resources". URIs are just their addresses.
> [mike] it'd be neat to have a 'sidebar' talking about 'names .vs. addresses'

Might be a distraction.

> > Some REST advocates
> > call the process of bringing your applications into this model Resource
> > Modeling. This process is not yet as formal as object oriented modeling
> > or entity-relation modeling but it is related to those. The strength and
> > flexibility of REST comes from the creative use of URIs.
> [mike] 'creative' implies un-designed, how about 'consistent' or 'strong' or
> 'intelligent' or something positive.

"pervasive"

> > HTTP's extensibility stems primarily from the ability to distribute any
> > payload with predefined or new headers using predefined or (on occasion)
> > new methods. What makes HTTP really special among all protocols,
> > however, is its implicit understanding of URIs and resources.
> [mike] is it 'implicit understanding' or 'central focus'/whatever?

"built-in support for"

>...
> > later merely by manipulating the ACLs. Another model for security is
> > called capabilities. This less popular model is more flexible than ACLs
> [mike] popular -> prevalent (it isn't as widely known, so 'popularity' isn't
> quite correct - KragenS might be able to provide more detail on how it ties
> in with ReST)

Okay, prevalent.

>...
> > Of course HTTP-based Web Services can go through firewalls easily. But
> > that is the only point of similarity with RPC tunnels through HTTP such
> [mike] 'rpc tunnels through http' -> 'rpc tunneling through http' ('tunnel'
> is both verb and noun, would be nice to clarify)

Okay.

> > as XML-RPC or SOAP-RPC over HTTP. When you use HTTP over a firewall, you
> > are being very explicit about what is going on. Your system
> > administrator can look at her logs to determine what services are
> [mike] 'her' -> 'the' (overly p.c. is distracting for me...)

This isn't the only reference to "her". Eventually I'll need to use a
pronoun. Shame about the English language. ;) The truly PC use "hir".
Which is more distracting: "She" or "(S)he"? Yes, I know they are both
distracting...which is MORE.

http://www.vexen.co.uk/words.html#HIR

> > delete_* and save_*. This pattern is ubiquitous.
> [mike] 'this pattern is ...' -> 'this pattern of a small number of methods
> on a large amount of data is ...' (can't hurt to re-iterate the point of
> rest)

Okay.

> > know when they will get a request from a client.
> [mike] 'get' -> 'receive' (get might imply proactive processing or polling)

Okay. 

> > Writing reliable-delivery software with HTTP is relatively easy. Thanks
> > to the guarantees of TCP, you can always know for sure if you received
> > an appropriate response. If you did not, then in many cases it is safe
> > to repeat the message send, due to the principle of idempotency.
> [mike] another sidebar with concrete examples and 'idempotency' would be
> good here...

I will provide a URI.

> > not an issue then you should certainly use the simpler approach.
> [mike] 'use' -> 'consider' (don't recommend an approach that is short term
> and non-interoperable)

If that's what you need....sometimes I use XML, but others Word.
Sometimes REST but other times RPC.

> > HTTP is also not appropriate in some circumstances. Because HTTP runs on
> > top of TCP, it can have high latency.
> [mike] 'high' is relative, give some concrete numbers so people don't make
> decisions based on the wrong assumptions

Okay, I'll try to be more explicit.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:710
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-12 01:30:05
Subject:P2P
Message:

How the web be different if HTTP had been designed so that there was a
way built-in for the client to become the server and vice versa...

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:711
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-12 15:29:56
Subject:Re: [rest-discuss] P2P
Message:

> How the web be different if HTTP had been designed so that there was a
> way built-in for the client to become the server and vice versa...

Hard to say.  I don't know that firewall admins would have let a
method like "TURN" be used, but had it been used for neat stuff,
and the server-in-the-browser implementations didn't have any gaping
security holes, it may have accelerated the move to the "Two Way Web".

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:712
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-14 00:00:51
Subject:HTTPEvents Subscription time
Message:

So does anyone mind if I take this out:

"The message MAY contain a header called "Requested-Expiration". It
should be a time value that represents the time that the Subscriber
Application would like the subscription to persist."

and this:

"Expiration: The response to the Subscription MUST include a header
called "Subscription-Expiration". This indicates the time that the
subscription expires. The subscriber application MAY renew the
subscription before this time. If it does not, the publisher MAY stop
sending notifications after that time. The publisher MAY also remove the
Subscription URI."

and this:

Renewal: The subscriber MAY renew a Subscription by making another
Subscription Request. 

I will leave this in:

"Each notification response MUST include a "Continue-Subscription"
header. The value associated with this header MUST be the string "true".
If the header is not present, the publisher MUST remove the
subscription."

And subscriptions will be either one-shot or infinite, depending on how
you look at it.

==========

Should there be a way for the publisher to tell the subscriber when it
(for whatever reason) will cease giving notifications? Sort of like the
old unix sysadmin announcement: "Going offline NOW!"

One way to handle this is to have the client register another URI, the
"subscription-cancellation URI". Another is to have a special HTTP
method. Another is to just not worry about it. Applications can handle
that out of band. I think I like that last option...

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:713
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-14 15:32:21
Subject:Re: [rest-discuss] HTTPEvents Subscription time
Message:

This all works for me.

Paul Prescod wrote:

> So does anyone mind if I take this out:
>
> "The message MAY contain a header called "Requested-Expiration". It
> should be a time value that represents the time that the Subscriber
> Application would like the subscription to persist."
>
> and this:
>
> "Expiration: The response to the Subscription MUST include a header
> called "Subscription-Expiration". This indicates the time that the
> subscription expires. The subscriber application MAY renew the
> subscription before this time. If it does not, the publisher MAY stop
> sending notifications after that time. The publisher MAY also remove the
> Subscription URI."
>
> and this:
>
> Renewal: The subscriber MAY renew a Subscription by making another
> Subscription Request.
>
> I will leave this in:
>
> "Each notification response MUST include a "Continue-Subscription"
> header. The value associated with this header MUST be the string "true".
> If the header is not present, the publisher MUST remove the
> subscription."
>
> And subscriptions will be either one-shot or infinite, depending on how
> you look at it.
>
> ==========
>
> Should there be a way for the publisher to tell the subscriber when it
> (for whatever reason) will cease giving notifications? Sort of like the
> old unix sysadmin announcement: "Going offline NOW!"
>
> One way to handle this is to have the client register another URI, the
> "subscription-cancellation URI". Another is to have a special HTTP
> method. Another is to just not worry about it. Applications can handle
> that out of band. I think I like that last option...
>
>  Paul Prescod
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:714
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-14 16:14:07
Subject:Re: [rest-discuss] required headers in the notification message
Message:

Lucas Gonze wrote:
> 
> About the notification message definition:
> "A notification message must have the following headers:
> Watched-URI: (URI of the watched resource)
> Subscription-URI: URI of the subscription object"
> 
> I believe that the Watched-URI and Subscription-URI are not properly a required
> part of the notification message.  In the idempotent notification model the
> Subscriber URI contains the entire content of the callback.  There are several
> reasons.
>
> 1) It is not properly a subscriber URI but a notification URI.  This follows
> from the fact that the sink receives notifications via PUT.  If you PUT multiple
> notifications to the same URI, and they contain data related to different
> subscriptions, they will wipe one another out.

Right now the spec says:

"The HTTP method used for the notification is up to the application."

As you've urged I'm trying not to over-constrain. Mark Baker feels like
it makes sense to use PUT and POST in some circumstances. I actually
prefer NOTIFY. I don't see the harm in allowing choice. The only thing
I'll go do right now is add:

" but the method must not be GET, HEAD or any other method that is
defined to be safe (side-effect-free)."

> 2) If the subscription URI in the notification is used as the callback address
> for renewing/deleting/pending the subscription, or if the Watched-URI is used as
> the callback address for picking up further events, then an attacker can rewrite
> these headers to contain the target URI of a distributed denial of service
> attack.  To prevent rewriting, the notification message would have to be either
> signed or encrypted, and if the sink has to handle signed or encrypted messages,
> it can't be a plain vanilla HTTP server.  So the sink MUST NOT use either the
> Watched-URI or Subscription-URI as the callback address for
> renewing/deleting/pending the subscription.

I see your problem. But also look at it from the opposite point of view.
Directing clients at an alternate server (i.e. mirror) is a useful form
of load balancing.

I'm not convinced that the DOS is a real problem. In order to generate
1000000 hits on the target machine ("take that capitalist bastards!")
you'd have to generate 1000000 notifications. Why wouldn't you just
directly make the 1000000 GET connections and be done with it? Maybe for
obfuscation but the point remains that the number of hits you generate
is in the same ballpark as the number of notifications you make so it is
really hard to make a serious hit.

> 3) If the Watched-URI and Subscription-URI in a notification message are used by
> the sink to identify the resource in question, an attacker can eavesdrop to
> discover any meaningful data within those URIs.  For example the
> Subscription-URI may hold enough information to modify a subscription.  If the
> Subscription-URI had been obtained within the context of an HTTPS connection,
> including it within an uncrypted notification message would disclose a secret.

Arguably you should use real authentication rather than just hoping that
URIs don't leak out.

>...
> I don't mean to block off whatever the utility of the notification headers is,
> though.  Explanations of the intended use of those headers would help in finding
> an alternative way to meet the need...

There are three virtues. 1. a notification message gives you enough
information to know what is going on even if you didn't play games with
the subscription URI. 2. this is very useful for the email binding where
people usually don't like to invent hundreds of email addresses. 3. the
server can do a form of load-balancing so that they don't slashdot
themselves.

If we ignore the first two and say that only 3 is important then we
could remove the subscription URI and make the Watched-URI a MAY.

This could be used to solve 2:

http://developer.netscape.com/viewsource/husted_mailto/mailto.html

And I guess 1 is more of a theoretical problem. So I suggest the
following:

"
A notification message MAY have the following headers: 

Watched-URI: (URI of the watched resource) 

The Watched-URI may be any valid URI for the resource that generated the
notification. It need not be the original URI but it must refer to the
same resource. If the client wants to retrieve a representation of the
resource it SHOULD use this URI, not the original one. This will allow
publishers to do a simple form of load balancing.
"

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:715
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-02-14 17:26:58
Subject:Re: [rest-discuss] required headers in the notification message
Message:

> I'm not convinced that the DOS is a real problem. In order to generate
> 1000000 hits on the target machine ("take that capitalist bastards!")
> you'd have to generate 1000000 notifications. Why wouldn't you just
> directly make the 1000000 GET connections and be done with it? Maybe for
> obfuscation but the point remains that the number of hits you generate
> is in the same ballpark as the number of notifications you make so it is
> really hard to make a serious hit.

This is an elegant and useful bit of reasoning.

The only remaining bit of DDoS (after the above) is that the watcher can
be tricked into generating watches against DDoS targets, given that a
watch often entails a polling loop.  Is this really a problem?  You can
argue that a watcher actually reduces hits, given that it can act as an
aggregator for multiple clients' individual polling loops.  ...

Hmmm.  There's a general problem of watched resources not wanting to be
watched.  Maybe they don't have the bandwidth to sustain polling loops,
maybe they're huge files.  It seems to me that there's an existing
mechanism for handling this -- robots.txt.  Interesting.











-----------------------------------------------------------------------------------
Post ID:716
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-14 18:31:53
Subject:Re: [rest-discuss] required headers in the notification message
Message:

Lucas Gonze wrote:
> 
>...
> 
> Hmmm.  There's a general problem of watched resources not wanting to be
> watched.  Maybe they don't have the bandwidth to sustain polling loops,
> maybe they're huge files.  

Yes, you could have a situation where a third party notification
purposely or accidentally causes a major load on some server. But I am
disclined to deal with that in the spec:

 1. Already a problem on the Web. c.f. Slashdot effect. I'll bet there
are some sites (e.g. dynamically generated using TeX) where even a FoRK
posting could kill them.

 2. Server can limit connections (admittedly suboptimal "solution")

 3. Very hard to engineer maliciously on a large scale because where did
you find all of those subscription URIs? You'd have to do a hell of a
lot of sniffing and hope that the subscription URIs are static. etc.
etc.

 4. Not a real "security hole" in the sense that it doesn't expose data,
causes no harm at all to the client and it won't seriously harm a
well-written server either.

> ... It seems to me that there's an existing
> mechanism for handling this -- robots.txt.  Interesting.

robots.txt is similar but too different to be directly reused in my
opinion. The one is about crawlers. The other is about subscribers. I
don't think that they are the same...

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:717
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-02-14 19:02:47
Subject:Re: [rest-discuss] required headers in the notification message
Message:

an interesting related nugget:

eBay successfully argued in court that a spider used by a competitor to
aggregate eBay's (among other auction sites') listings was causing damage
by overloading their servers, despite the fact that eBay's listings were
accessed via GET.

Legal retardation aside, is there potential legal risk to a third party
watcher?  EG, the above aggregator could just as well have been a
notification service of the kind we are discussing here.



> > Hmmm.  There's a general problem of watched resources not wanting to be
> > watched.  Maybe they don't have the bandwidth to sustain polling
loops,o > > maybe they're huge files.
>
> Yes, you could have a situation where a third party notification
> purposely or accidentally causes a major load on some server.








-----------------------------------------------------------------------------------
Post ID:718
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-14 19:17:22
Subject:Re: [rest-discuss] required headers in the notification message
Message:

Lucas Gonze wrote:
> 
> an interesting related nugget:
> 
> eBay successfully argued in court that a spider used by a competitor to
> aggregate eBay's (among other auction sites') listings was causing damage
> by overloading their servers, despite the fact that eBay's listings were
> accessed via GET.
> 
> Legal retardation aside, is there potential legal risk to a third party
> watcher?  EG, the above aggregator could just as well have been a
> notification service of the kind we are discussing here.

Yes, a third party watcher could be considered a kind of robot that
wastes resources. But I'm not inclined to worry about it until it
becomes a problem. If legals had any say in the design of the Web it
wouldn't exist. After all, people are constantly "wasting resources"
downloading things they weren't authorized to download. If the Web was
not so damn useful the legals would have shut it down years ago.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:719
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-02-14 19:18:41
Subject:Re: [rest-discuss] required headers in the notification message
Message:

M. Prescod said:
> Yes, you could have a situation where a third party
notification
> purposely or accidentally causes a major load on some server. But I am
> disclined to deal with that in the spec:

I would leave the default as saying that all resources are watchable until
they opt-out, the same as with crawlers.  On the worldos.com site 99% of
bandwidth was spiders downloading the complete tarball, which was a pain
in the ass for my provider, who is a decent guy with not a lot of money.
I was happy to be able to use robots.txt as a courtesy to him.

Note that I'm not arguing about what you put in HttpEvents, which is none
of my business.

> robots.txt is similar but too different to be directly reused in my
> opinion. The one is about crawlers. The other is about subscribers. I
> don't think that they are the same...
>
>  Paul Prescod

Well, they're both bots that are too dumb to know the difference.







-----------------------------------------------------------------------------------
Post ID:720
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-14 19:27:36
Subject:Re: [rest-discuss] required headers in the notification message
Message:

Lucas Gonze wrote:
> 
>...
> 
> I would leave the default as saying that all resources are watchable until
> they opt-out, the same as with crawlers.  On the worldos.com site 99% of
> bandwidth was spiders downloading the complete tarball, which was a pain
> in the ass for my provider, who is a decent guy with not a lot of money.
> I was happy to be able to use robots.txt as a courtesy to him.

Agreed. But robots are stupid. You point them at one web page and they
traverse the whole damn web. On the other hand, every watched URI is
watched because someone, somewhere explicitly asked to watch it. If
someone set up a robot that FOUND URIs to watch then I would agree it
should obey the robots.txt.

> Note that I'm not arguing about what you put in HttpEvents, which is none
> of my business.

I want you to make it your business. If you see someting I don't, I want
to hear about it.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:721
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-02-14 19:29:43
Subject:Re: [rest-discuss] required headers in the notification message
Message:

> > ... It seems to me that there's an existing
> > mechanism for handling this -- robots.txt.  Interesting.
>
> robots.txt is similar but too different to be directly reused in my
> opinion. The one is about crawlers. The other is about subscribers. I
> don't think that they are the same...
>
>  Paul Prescod

It strikes me that crawlers and watchers are closely related.  A watcher
does a push notification while a crawler does a pull.  A primary usecase
of notifications is for watched resources to get changes indexed faster,
while at the same time reducing overhead for pollers.









-----------------------------------------------------------------------------------
Post ID:722
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-14 20:21:59
Subject:Re: [rest-discuss] required headers in the notification message
Message:


Paul Prescod wrote:

>  1. Already a problem on the Web. c.f. Slashdot effect. I'll bet there
> are some sites (e.g. dynamically generated using TeX)

Good lord.  Nobody's really doing that, are they? ;-)

jb









-----------------------------------------------------------------------------------
Post ID:723
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-14 20:23:28
Subject:Legality of GET burdening
Message:


Lucas Gonze wrote:

> an interesting related nugget:
>
> eBay successfully argued in court that a spider used by a competitor to
> aggregate eBay's (among other auction sites') listings was causing damage
> by overloading their servers, despite the fact that eBay's listings were
> accessed via GET.

Likewise, part of the final shutdown of Clickfeed was due to a restatement of
their terms-of-service followed by a fairly aggressive legal posture they took
along the same lines. :-/

jb








-----------------------------------------------------------------------------------
Post ID:724
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-14 20:24:26
Subject:Re: [rest-discuss] required headers in the notification message
Message:

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> >  1. Already a problem on the Web. c.f. Slashdot effect. I'll bet there
> > are some sites (e.g. dynamically generated using TeX)
> 
> Good lord.  Nobody's really doing that, are they? ;-)

Maybe not yet. But I've heard some people use JavaScript on the server
side and that's almost as bad!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:725
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-14 22:24:11
Subject:Idea: Simple Web Service Behaviour Language
Message:

Idea I've been noodling....
====
Abstract

The basic model of a REST Web Service is that services are described as
webs of documents. Typically the documents will be dynamically generated
but that is not necessarily the case. Just as with services based on
COM, CORBA or SOAP, it would be nice to have a declaration of a
service's behaviour in advance so that reliable software can be
constructed with less testing.

Insofar as a service consists of documents, especially XML documents,
XML schemas provide a partial description of the service. What they do
not describe is the transitions from one document to another. That's
what SWSBL does. It is intended to be the IDL/WSDL for HTTP web
services. Just as with IDL it may one day make sense to "bind" SWSBL
into a statically typed programming language to make the construction of
type-incorrect client software more difficult.

Model

Think of a web service as a web of document types. The "find airline
seat" document points to the "reserve seat" document through a URI. That
document points to the "purchase seat" document through a URI and so
forth. Each document has associated with it an XML Schema but also a
behaviour description (or perhaps just a fragment of a behaviour
description ). The "root" behaviour description for a service asserts
that a particular URI references a service that conforms to a particular
behaviour description. 
As you move from document to document following links, each link is
strongly and statically typed by the Behaviour Description. A failure to
conform is a runtime error, just as with non-validation against an XML
Schema or WSDL service description. 

Sometimes the client wants to send information to the server. HTTP
allows you to do this either by POSTing to a document or PUTting to a
URI provided by the server. So beyond being strongly typed, each URI
must have associated with it a set of possible methods and inputs. Think
of this as a 4-tuple: 

 * HTTP method 
 * query parameters 
 * HTTP headers 
 * body content (often XML in some vocabulary) 

SWSBL will help the service provider to define these valid inputs in
advance so that client software can be reliably constructed. 

Sometimes you have an option of PUT and/or POST and/or DELETE so we must
have multiple possible input actions associated with each URI. The input
to PUT is likely to be very different than the input to POST and DELETE
or GET have no body inputs. SWSBL will allow that. 

Once the HTTP request has been made, a response comes back. In order to
build robust, statically typed, services we want to know what valid
range of responses are legal. So for each sort of input, a range of
valid outputs may be described. These consist of HTTP response and body
content (perhaps constrained to one or more XML vocabularies). If a
statically typed programming language has data binding then one can
imagine that each "type" of input maps to a particular method and the
result of the method would be either an XML DOM or the statically typed
result of the data binding. (e.e. IPurchaseOrder instead of
IDOMDocument). To make this binding easier, input types should be named,
similar to operations in WSDL. 

The fundamental difference between this model and WSDL's is that this is
about interactions between web service components (every page is a
component) whereas WSDL is about describing a single web service
component (only one SWSBL page).






-----------------------------------------------------------------------------------
Post ID:726
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-15 00:27:19
Subject:Re: [rest-discuss] Idea: Simple Web Service Behaviour Language
Message:

I really like the idea. Discovery is a missing piece with REST and HTTP - at
least in the statically defined way you describe.
I also like that the design /starts/ with lots of documents and lots of
services, rather than just one as in wsdl.

mike

----- Original Message -----
From: "Paul Prescod" <paul@...>
To: <rest-discuss@yahoogroups.com>
Sent: Thursday, February 14, 2002 2:24 PM
Subject: [rest-discuss] Idea: Simple Web Service Behaviour Language


> Idea I've been noodling....
> ====
> Abstract
>
> The basic model of a REST Web Service is that services are described as
> webs of documents. Typically the documents will be dynamically generated
> but that is not necessarily the case. Just as with services based on
> COM, CORBA or SOAP, it would be nice to have a declaration of a
> service's behaviour in advance so that reliable software can be
> constructed with less testing.
>
> Insofar as a service consists of documents, especially XML documents,
> XML schemas provide a partial description of the service. What they do
> not describe is the transitions from one document to another. That's
> what SWSBL does. It is intended to be the IDL/WSDL for HTTP web
> services. Just as with IDL it may one day make sense to "bind" SWSBL
> into a statically typed programming language to make the construction of
> type-incorrect client software more difficult.
>
> Model
>
> Think of a web service as a web of document types. The "find airline
> seat" document points to the "reserve seat" document through a URI. That
> document points to the "purchase seat" document through a URI and so
> forth. Each document has associated with it an XML Schema but also a
> behaviour description (or perhaps just a fragment of a behaviour
> description ). The "root" behaviour description for a service asserts
> that a particular URI references a service that conforms to a particular
> behaviour description.
> As you move from document to document following links, each link is
> strongly and statically typed by the Behaviour Description. A failure to
> conform is a runtime error, just as with non-validation against an XML
> Schema or WSDL service description.
>
> Sometimes the client wants to send information to the server. HTTP
> allows you to do this either by POSTing to a document or PUTting to a
> URI provided by the server. So beyond being strongly typed, each URI
> must have associated with it a set of possible methods and inputs. Think
> of this as a 4-tuple:
>
>  * HTTP method
>  * query parameters
>  * HTTP headers
>  * body content (often XML in some vocabulary)
>
> SWSBL will help the service provider to define these valid inputs in
> advance so that client software can be reliably constructed.
>
> Sometimes you have an option of PUT and/or POST and/or DELETE so we must
> have multiple possible input actions associated with each URI. The input
> to PUT is likely to be very different than the input to POST and DELETE
> or GET have no body inputs. SWSBL will allow that.
>
> Once the HTTP request has been made, a response comes back. In order to
> build robust, statically typed, services we want to know what valid
> range of responses are legal. So for each sort of input, a range of
> valid outputs may be described. These consist of HTTP response and body
> content (perhaps constrained to one or more XML vocabularies). If a
> statically typed programming language has data binding then one can
> imagine that each "type" of input maps to a particular method and the
> result of the method would be either an XML DOM or the statically typed
> result of the data binding. (e.e. IPurchaseOrder instead of
> IDOMDocument). To make this binding easier, input types should be named,
> similar to operations in WSDL.
>
> The fundamental difference between this model and WSDL's is that this is
> about interactions between web service components (every page is a
> component) whereas WSDL is about describing a single web service
> component (only one SWSBL page).
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:727
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-15 00:51:47
Subject:Re: [rest-discuss] Idea: Simple Web Service Behaviour Language
Message:


Paul Prescod wrote:

> Sometimes the client wants to send information to the server. HTTP
> allows you to do this either by POSTing to a document or PUTting to a
> URI provided by the server. So beyond being strongly typed, each URI
> must have associated with it a set of possible methods and inputs. Think
> of this as a 4-tuple:
>
>  * HTTP method
>  * query parameters
>  * HTTP headers
>  * body content (often XML in some vocabulary)
>

Jesus, this is scary.  I was thinking about this on the drive home today, in
the sense of abstract models for the Web.  I was coming from the direction of
modeling requests and responses directly ---  two kinds of tuples, one a
request-type tuple and another a response-type tuple.  The request tuple Q is

< namespace, base-uri, query-uri, method, headers, body >

It's important to capture namespace (aka the Host: header, elevated to
first-class status due to its primary role in dispatching requests arriving
at a given node) and the base-uri so that you can model the behavior of
intermediaries and e.g. WD-Proxylike NOTIFY where the receipient is a
different Host: than the actual server, also important for virtual hosts,
etc.  A response tuple S is then something like

< response-code, headers, body >

A resource is then viewed as a function R:  Q --> time --> S, and a server
(node) is viewed as a generic function N: Q --> R.  (Sorry for the
Haskell-like notation if it's confusing.  X --> Y is a unary function that
maps X into Y,  X --> Y --> Z is a curry function that takes X into a
function that takes Y into Z.  Perhaps more intuitively, it's a 2-ary
function that takes X and Y into Z.)

The point of all of these contortions in my mental exercise was to arrive at
a concise way to specify the semantics of the Web in a manner that would
enable dataflow-like composition --- or any sort of compositional algebra of
operations on --- various Web resources, transformations, and so on.  The Web
needs a shell language, and this could be the start of its theoretical
underpinnings.

Anyway, Paul, I think you're on an interesting track with this!

jb









-----------------------------------------------------------------------------------
Post ID:728
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-15 08:24:45
Subject:Re: [rest-discuss] Idea: Simple Web Service Behaviour Language
Message:

Jeff Bone wrote:
> 
>...
> 
> < namespace, base-uri, query-uri, method, headers, body >
> 
> It's important to capture namespace (aka the Host: header, elevated to
> first-class status due to its primary role in dispatching requests arriving
> at a given node) and the base-uri so that you can model the behavior of
> intermediaries and e.g. WD-Proxylike NOTIFY where the receipient is a
> different Host: than the actual server, also important for virtual hosts,
> etc.  A response tuple S is then something like

I don't understand base-uri and I'm not sure if I need it for my app.

If you're saying that you need to separate out query parameters from the
base URI then I agree. Query parameters are in the domain of the
application whereas the base URI is opaque. So for my language you need
to be able to fiddle query parameters, just as HTML forms do. Whereas
the rest of the URI comes from the server and you just leave that alone.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:729
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-02-15 14:03:13
Subject:Re: Idea: Simple Web Service Behaviour Language
Message:

I have been lurking on the REST conversations since Mark Baker 
started them on FoRK, and even before then on the distributed objects 
mailing list.

I think you-all are changing minds all over the place, and you have 
my sincere thanks and congratulations.

I have been trying to pick my time to try to join the conversation.  
After a few false starts, maybe this SWSBL topic is a good opening

I really like Paul Prescod's recent articles. He's starting to try to 
work with business concepts like Purchase Orders, which are part of 
my domain.  

However, I see this also happen a lot in other Web Service examples:  
The business logic behind the examples is often not very realistic, 
and so the solutions may not be realistic either.  

I think I can provide some realistic business examples, and learn 
something about how to model them as REST resources.

I'm not sure how deep you-call want to get into business processes, 
but I have some time to discuss the issues in the next week or two 
and so will put the question on the table now.  Please forgive the 
long message.  It contains some info on where I'm coming from, some 
comments on business processes, and a couple of RESTification 
attempts.

I'm coming from heavy involvement with ebXML and its follow-on 
activities in eBTWG:
http://www.ebxml.org
http://www.ebtwg.org

These groups are trying to define standards for B2B collaborations.
The background of many of the participants is traditional EDI, which 
means peer-to-peer document transfer.  They assume that the documents 
just flow over the wire from one internal business system to another 
and never surface as Web resources.  Thus you will see ebXML projects 
like the Registry act like private database systems when they would 
have better as catalogs of Web resources.  (Similar to UDDI.)

My goal in joining your discussion is to take some of the business 
concepts from ebXML and RESTify them.  I hope to influence ebXML and 
related efforts to move in the REST direction.

I find it fairly natural to model business objects as suites of Web 
resources.  (Paul Prescod:  refering to one of your recent opponents 
on the xml-dev list, I think it is perfectly feasible to model almost 
everything in any business application system (ERP, CRM, etc.) in Web 
resources.) 

I'm having some trouble getting the business *conversations* 
RESTified correctly, though, and maybe you can help.

For example:
The business protocol for a Order is Offer-Acceptance.
A Purchase Order is an offer to buy.  
To be binding, it must be explicitly accepted by the supplier.
The offer must have a time constraint - it is not good forever.  

So a Purchase Order as a Web resource is also an element in a dialog 
between Customer and Supplier.  

The offer-acceptance protocol for a Purchase Order in RosettaNet and 
ebXML includes stages of requesting and responding messages with 
timeouts:
1. The Customer places the Purchase Order.
2. The Supplier sends a receiptAcknowledgment quickly signifying both 
receipt and schema validation.
3. The Supplier sends an acceptance or rejection (for which they 
would typically have more time).  Acceptance means contract formation 
or binding - a Purchase Order is a type of contract.
4. The Customer sends a receiptAck of the acceptance or rejection.

There are reasons for these signals.  If the receiptAck times out, 
the Customer may retry or go to another Supplier without wasting any 
more time.  If the acceptance times out, the offer failed.  B2B 
orders are usually not like consumer ones where the customer prepays 
using a credit card.  B2B orders are often postpaid, on credit.  So 
business state alignment is important:  meaning both parties must 
agree explicitly and deterministically on whether the order was 
accepted (or not).

"Business state alignment" implies that a Purchase Order has a state 
model:  for example, pending, accepted, rejected, fulfilled, etc.
(That was not a complete list of states, by the way.)

Allowed actions will be constrained by PO state:  for example, a PO 
in the "fulfilled" state cannot be canceled; a "rejected" order 
should not be fulfilled.  In other words, orchestration of actions is 
conditioned by resource state.  (Not by message sequence.)

ebXML (among other initiatives) is attempting to express the 
orchestration rules as XML documents.  Which means the business 
process can become a Web resource as well as the business objects.  I 
think this is very similar to what Paul is trying to do with SWSBL, 
except that (1) it may be more complex than what you have in mind, 
and (2) the ebXML guys for the most part do not have a Web resource 
model in their collective mind.

Ok, one feeble attempt to model this all as hierarchies of REST 
resources:

ProductCatalog
  Product102
PurchaseOrders
  PO203
    OrderLines
    Deliveries
    Payments
    TransactionLog
      NegotiationTransactions
      DeliveryTransactions
      PaymentTransactions
      ProblemResolutionTransactions
PurchasingProcess
  ActivityModel
    ProcessStages
      NegotiationStage
      DeliveryStage
      PaymentStage
      ProblemResolution
  ObjectModels
    PurchaseOrder
      StateModel
    Delivery
      StateModel
    Payment
      StateModel
  TransactionPatterns
    Offer-Acceptance
    Notify-Confirm

(Note:  Notify-Confirm is the protocol for deliveries and payments.)

My current vague idea for RESTifying the conversations is for the 
participants to Post or Put documents to the TransactionLog, which 
will process them according to the state of the related business-
object-resource (following the rules of the Purchasing Process) and 
possibly change the state of the resource accordingly, while adding 
the document to the TransactionLog.

Timeouts and acks might be Notifications.

One really interesting issue is where do the Web resources live?  
That is, who hosts them: Customer, Supplier or trusted 3rd party?  
The realities of business say: 
(a) both parties want their own copies in their own internal systems 
and neither fully trusts the other to maintain an "official" version;
(b) trading partner relationships are usually unbalanced, that is, 
one partner is dominant, and the dominant partner would most 
naturally host the Web resources.

All three of the possible hosts can be found in practice:
3rd parties like CommerceOne and Ariba;
customer hosts like big companies who publish Web orders for their 
smaller suppliers;
big suppliers who provide Web ordering facilities for their customers.

I have not seen the business processes as Web resources yet.

Here is another attempt to RESTify some business objects, assembled 
by one of my business partners from anonymized real-world cake mix 
contracts:
http://homepage.interaccess.com/~linkage/Contracts/CakeMix.htm

Don't look critically at the HTML - the author is a supply chain 
manager, not a technical person.  Just look at how easy he found it 
to RESTify this stuff.  







-----------------------------------------------------------------------------------
Post ID:730
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-02-15 14:12:48
Subject:Re: Idea: Simple Web Service Behaviour Language
Message:

Correcting the hierachy so it indents properly, two dots per level:

ProductCatalog
..Product102
PurchaseOrders
..PO203
....OrderLines
....Deliveries
....Payments
....TransactionLog
......NegotiationTransactions
......DeliveryTransactions
......PaymentTransactions
......ProblemResolutionTransactions
PurchasingProcess
..ActivityModel
....ProcessStages
......NegotiationStage
......DeliveryStage
......PaymentStage
......ProblemResolution
..ObjectModels
....PurchaseOrder
......StateModel
....Delivery
......StateModel
....Payment
......StateModel
..TransactionPatterns
....Offer-Acceptance
....Notify-Confirm

(sorry about that)








-----------------------------------------------------------------------------------
Post ID:731
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-02-15 15:58:13
Subject:Re: Idea: Simple Web Service Behaviour Language
Message:

> The background of many of the participants is traditional EDI, 
which 
> means peer-to-peer document transfer.  They assume that the 
documents 
> just flow over the wire from one internal business system to 
another 
> and never surface as Web resources.  Thus you will see ebXML 
projects 
> like the Registry act like private database systems when they would 
> [work] better as catalogs of Web resources.  (Similar to UDDI.)

The referent of "similar" in that statement was unclear:  I meant 
that UDDI shares the unfortunate tendency of ebXML to divorce 
themselves from "the Web" and try to carve out a separate space 
operating by other rules.







-----------------------------------------------------------------------------------
Post ID:732
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-02-15 18:19:05
Subject:application level status codes
Message:

RFC 2616 is unclear about whether and how to mix application and transport
status codes.  For example, status code 205 goes all the way up to the UI
level:

205 Reset Content
    The server has fulfilled the request and the user agent SHOULD reset
   the document view which caused the request to be sent. This response
   is primarily intended to allow input for actions to take place via
   user input, followed by a clearing of the form in which the input is
   given so that the user can easily initiate another input action. The
   response MUST NOT include an entity.

It's important to be able to distinguish transport errors from application
errors, since a request might be be legal HTTP but have illegal parameter
values as far as the resource is concerned.  And it's very useful to use
the response headers to communicate application status, because otherwise
the application needs to define a new format within the message body, and
the message body may be reserved for other information.

SOAP et al already have definitions for application status codes and SOAP
et al are really useful for application-level envelopes, if not for
node-level semantics, but Joe Schmoes's app shouldn't have to depend on
them just to communicate application status codes.  So I'm going to
propose a strawman for application status codes in the response headers.
I don't mean to create a "standard" for interop.  I do mean to solicit
comments and discussion of how appropriate it is use response headers for
application-level info, and of how good the proposed scheme is.

Proposal for application status codes: An application can return status
codes in response headers titled "Application-Response-Code."  There can
be 0 or more such response headers.  The value of a
Application-Response-Code field may contain three elements, a numeric
field code, a textual explanation, and a text value to say the object of
the error.  The fields are comma delimited.  Commas are illegal values in
the numeric field code or the textual explanation.  The commas are
required -- a well-formed Application-Response-Code will always have at
least two.  The meaning of Application-Response-Code is orthogonal to the
meaning of the HTTP status code; there is no requirement that the HTTP
status code be 200 OK, for example.

Thoughts?

- Lucas










-----------------------------------------------------------------------------------
Post ID:733
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-15 18:51:51
Subject:Re: [rest-discuss] Idea: Simple Web Service Behaviour Language
Message:


Paul Prescod wrote:

> Jeff Bone wrote:
> >
> >...
> >
> > < namespace, base-uri, query-uri, method, headers, body >
> >
> > It's important to capture namespace (aka the Host: header, elevated to
> > first-class status due to its primary role in dispatching requests arriving
> > at a given node) and the base-uri so that you can model the behavior of
> > intermediaries and e.g. WD-Proxylike NOTIFY where the receipient is a
> > different Host: than the actual server, also important for virtual hosts,
> > etc.  A response tuple S is then something like
>
> I don't understand base-uri and I'm not sure if I need it for my app.
>
> If you're saying that you need to separate out query parameters from the
> base URI then I agree.

Right, right.

The difference between what I was describing and what you're talking about ---
the reason my model includes the base-uri --- is that we're doing different
things.  I'm looking at ways to precisely describe the semantics of Web
interaction in general, therefore I've got to capture notions like "server,"
"host namespace" (for diambiguating virtual hosts, describing proxy behavior,
etc.)  and so forth.  Not clear that you need those, though perhaps they don't
hurt.

jb








-----------------------------------------------------------------------------------
Post ID:734
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-15 18:49:57
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

bhaugen32 wrote:
> 
>...
> 
> I'm having some trouble getting the business *conversations*
> RESTified correctly, though, and maybe you can help.

I think we can be mutually helpful here! I may have to be short today,
though. Other stuff to do.
 
> For example:
> The business protocol for a Order is Offer-Acceptance.
> A Purchase Order is an offer to buy.
> To be binding, it must be explicitly accepted by the supplier.
> The offer must have a time constraint - it is not good forever.
> 
> So a Purchase Order as a Web resource is also an element in a dialog
> between Customer and Supplier.
> 
> The offer-acceptance protocol for a Purchase Order in RosettaNet and
> ebXML includes stages of requesting and responding messages with
> timeouts:
> 1. The Customer places the Purchase Order.

POST.

> 2. The Supplier sends a receiptAcknowledgment quickly signifying both
> receipt and schema validation.

Response to POST. Generates a new URI representing the eventual target
of its acceptance or rejection.

Customer uses HTTPEvents to WATCH the new URI (call it /acceptance).

> 3. The Supplier sends an acceptance or rejection (for which they
> would typically have more time).  Acceptance means contract formation
> or binding - a Purchase Order is a type of contract.

A notification comes through that the client should check /acceptance
because something has changed at the URI. The customer sees that
/acceptance says <accept/> (with a date, digital signature, contract,
list of things supplied, etc.)

> 4. The Customer sends a receiptAck of the acceptance or rejection.

Customer POSTs their ack with a digital signature and a URI pointing
back to /acceptance.

> There are reasons for these signals.  If the receiptAck times out,
> the Customer may retry or go to another Supplier without wasting any
> more time.  If the acceptance times out, the offer failed.  B2B
> orders are usually not like consumer ones where the customer prepays
> using a credit card.  B2B orders are often postpaid, on credit.  So
> business state alignment is important:  meaning both parties must
> agree explicitly and deterministically on whether the order was
> accepted (or not).

That's where the digital signatures and URIs help.

> "Business state alignment" implies that a Purchase Order has a state
> model:  for example, pending, accepted, rejected, fulfilled, etc.
> (That was not a complete list of states, by the way.)

You might think of those as different kinds of resources, pending_po,
accepted_po, rejected_po, fulfilled_po. Because they all have URIs, you
can say: "LOOK, I rejected that PO. Here's the URI." Of course one
cannot necessarily trust one's business partner so you need to have a
mirror on your side also.

> Allowed actions will be constrained by PO state:  for example, a PO
> in the "fulfilled" state cannot be canceled; a "rejected" order
> should not be fulfilled.  In other words, orchestration of actions is
> conditioned by resource state.  (Not by message sequence.)

Another good reason to have separate resources. A fullfilled_PO will
simply reject the cancellation POST.

> ebXML (among other initiatives) is attempting to express the
> orchestration rules as XML documents.  Which means the business
> process can become a Web resource as well as the business objects.  I
> think this is very similar to what Paul is trying to do with SWSBL,
> except that (1) it may be more complex than what you have in mind,
> and (2) the ebXML guys for the most part do not have a Web resource
> model in their collective mind.

Agreed.

I'll have to look at the rest of your stuff later. 

I think it is important to show real business examples. I admit that I
think in terms of technology and not business. I just know from what I
hear from business people that the technological problems are similar to
more standard protocol problems.

Maybe we could work together sometime on an article about the
intersection of ebXML and REST. I think that the ebXML crowd should be
fertile ground for REST thought. Many of them are old SGML heads who
would understand the benefits of linking. Others probably have a sense
that the web services world is going in the wrong direction and would
like to see something going in the right one.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:735
Sender:"Fred L. Drake, Jr." <fdrake@...>
Post Date/Time:2002-02-15 19:26:41
Subject:Python's urlparse() function
Message:

I just found out about this forum and this discussion, in particular.

--- In rest-discuss@y..., Mark Nottingham <mnot@m...> wrote:
> Python's urlparse is broken; it assumes that you can only
> parameterise the last path segment, not every path segment. As a
> result, 
>   http://www.example.com/foo;bar/baz?bat
> gets parsed as
>  ('http', 'www.example.com', 'foo', 'bar/baz' 'bat' '')

I'd like to note that Python 2.2 provides an additional call,
urlparse.urlsplit(), that avoids the assumption that only the last
path segment can be parameterized; the bug in urlparse.urlparse() is
also fixed in that version:

>>> import urlparse
>>> urlparse.urlsplit('http://www.example.com/foo;bar/baz?bat')
('http', 'www.example.com', '/foo;bar/baz', 'bat', '')
>>> urlparse.urlparse('http://www.example.com/foo;bar/baz?bat')
('http', 'www.example.com', '/foo;bar/baz', '', 'bat', '')


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation






-----------------------------------------------------------------------------------
Post ID:736
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-02-16 00:41:33
Subject:Re: [rest-discuss] Python's urlparse() function
Message:

Fantastic! This is great news, and I'll be upgrading to 2.2
immediately.

Cheers & thanks,


On Fri, Feb 15, 2002 at 02:26:41PM -0500, Fred L. Drake, Jr. wrote:
> 
> I just found out about this forum and this discussion, in particular.
> 
> --- In rest-discuss@y..., Mark Nottingham <mnot@m...> wrote:
> > Python's urlparse is broken; it assumes that you can only
> > parameterise the last path segment, not every path segment. As a
> > result, 
> >   http://www.example.com/foo;bar/baz?bat
> > gets parsed as
> >  ('http', 'www.example.com', 'foo', 'bar/baz' 'bat' '')
> 
> I'd like to note that Python 2.2 provides an additional call,
> urlparse.urlsplit(), that avoids the assumption that only the last
> path segment can be parameterized; the bug in urlparse.urlparse() is
> also fixed in that version:
> 
> >>> import urlparse
> >>> urlparse.urlsplit('http://www.example.com/foo;bar/baz?bat')
> ('http', 'www.example.com', '/foo;bar/baz', 'bat', '')
> >>> urlparse.urlparse('http://www.example.com/foo;bar/baz?bat')
> ('http', 'www.example.com', '/foo;bar/baz', '', 'bat', '')
> 
> 
>   -Fred
> 
> -- 
> Fred L. Drake, Jr.  <fdrake at acm.org>
> PythonLabs at Zope Corporation
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:737
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-02-16 15:51:57
Subject:Re: Purchase Orders
Message:

Paul Prescod <paul@p...> wrote:
> > "Business state alignment" implies that a Purchase Order has a 
state
> > model:  for example, pending, accepted, rejected, fulfilled, etc.
> > (That was not a complete list of states, by the way.)
> 
> You might think of those as different kinds of resources, 
pending_po,
> accepted_po, rejected_po, fulfilled_po. Because they all have URIs, 
you
> can say: "LOOK, I rejected that PO. Here's the URI." Of course one
> cannot necessarily trust one's business partner so you need to have 
a
> mirror on your side also.
> 
> > Allowed actions will be constrained by PO state:  for example, a 
PO
> > in the "fulfilled" state cannot be canceled; a "rejected" order
> > should not be fulfilled.  In other words, orchestration of 
actions is
> > conditioned by resource state.  (Not by message sequence.)
> 
> Another good reason to have separate resources. A fullfilled_PO will
> simply reject the cancellation POST.

I'm trying to keep an open mind, but having trouble accepting the 
idea of separate resources for a PO depending on its state.  But 
maybe I don't understand your proposal.

Questions:
1. Do you mean that the PO changes its identity depending on its 
state? (POs should not change their identity.)

2. Do mean that the history of PO-states-as-resources is persistent? 
That accepted_po and fulfilled_po co-exist?  In which case, what is 
to prevent one from canceling the accepted_po and ignoring the 
fulfilled_po?  (A PO should be in one and only one state at a time.)

From another angle:
3. Is there something un-RESTful in your view about a PO resource 
that knows its own state and can respond to transactions accordingly?
I mean, is there some essential REST difference between "PO in 
fulfilled state" that rejects cancellations and "fulfilled_po" that 
that rejects cancellations?

Thanks,
Bob Haugen







-----------------------------------------------------------------------------------
Post ID:738
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-02-17 00:10:57
Subject:201 Created
Message:

Reading this bit of rfc 2616...

10.2.2 201 Created

   The request has been fulfilled and resulted in a new resource being
   created. The newly created resource can be referenced by the URI(s)
   returned in the entity of the response, with the most specific URI
   for the resource given by a Location header field. The response
   SHOULD include an entity containing a list of resource
   characteristics and location(s) from which the user or user agent can
   choose the one most appropriate. The entity format is specified by
   the media type given in the Content-Type header field. The origin
   server MUST create the resource before returning the 201 status code.
   If the action cannot be carried out immediately, the server SHOULD
   respond with 202 (Accepted) response instead.

It's not clear to me what this stuff means:
   The response
   SHOULD include an entity containing a list of resource
   characteristics and location(s) from which the user or user agent can
   choose the one most appropriate. The entity format is specified by
   the media type given in the Content-Type header field.

What are the resource characteristics?  Is that the mime type of the
resource created?  Does this mean that the mime type of the resource
created goes in the Content-Type response header?

Thanks in advance.









-----------------------------------------------------------------------------------
Post ID:739
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-02-17 00:21:28
Subject:minute mysteries: 9.5 POST
Message:

Reading this bit of rfc 2616...

9.5 POST

   If a resource has been created on the origin server, the response
   SHOULD be 201 (Created) and contain an entity which describes the
   status of the request and refers to the new resource, and a Location
   header (see section 14.30).

...I don't understand what it means for the response entity to describe
 the status of the request, aside from setting the response status code,
which is already known to be 201.

Any of you high priests care to help clue me in?









-----------------------------------------------------------------------------------
Post ID:740
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-17 17:28:15
Subject:Re: [rest-discuss] 201 Created
Message:

Lucas Gonze wrote:
> 
>...
> 
> It's not clear to me what this stuff means:
>    The response
>    SHOULD include an entity containing a list of resource
>    characteristics and location(s) from which the user or user agent can
>    choose the one most appropriate. The entity format is specified by
>    the media type given in the Content-Type header field.
> 
> What are the resource characteristics?  Is that the mime type of the
> resource created?  Does this mean that the mime type of the resource
> created goes in the Content-Type response header?

Here's how I interpret it: when you create an entity you need to return
a reference to the entity not just in the header but also in the body
(e.g. an HTML page that says "click here to see your post" or an XML
page that has a URI attribute). In order for the client to select among
the potentially numerous URIs for the object, you should describe the
reason that there are multiple URIs and the advantages of each.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:741
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-02-17 18:45:05
Subject:Re: [rest-discuss] 201 Created
Message:

Good call -- your interpretation strikes me as correct.

So, in the case where there is no need for a user decision (e.g. with a
single response), there would be no need for metadata about resource
characteristics.




On Sun, 17 Feb 2002, Paul Prescod wrote:

> Lucas Gonze wrote:
> >
> >...
> >
> > It's not clear to me what this stuff means:
> >    The response
> >    SHOULD include an entity containing a list of resource
> >    characteristics and location(s) from which the user or user agent can
> >    choose the one most appropriate. The entity format is specified by
> >    the media type given in the Content-Type header field.
> >
> > What are the resource characteristics?  Is that the mime type of the
> > resource created?  Does this mean that the mime type of the resource
> > created goes in the Content-Type response header?
>
> Here's how I interpret it: when you create an entity you need to return
> a reference to the entity not just in the header but also in the body
> (e.g. an HTML page that says "click here to see your post" or an XML
> page that has a URI attribute). In order for the client to select among
> the potentially numerous URIs for the object, you should describe the
> reason that there are multiple URIs and the advantages of each.
>
>  Paul Prescod
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>







-----------------------------------------------------------------------------------
Post ID:742
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-17 18:53:15
Subject:Re: [rest-discuss] 201 Created
Message:

Lucas Gonze wrote:
> 
> Good call -- your interpretation strikes me as correct.
> 
> So, in the case where there is no need for a user decision (e.g. with a
> single response), there would be no need for metadata about resource
> characteristics.

Agreed.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:743
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-17 18:57:06
Subject:Re: [rest-discuss] minute mysteries: 9.5 POST
Message:

Lucas Gonze wrote:
> 
> Reading this bit of rfc 2616...
> 
> 9.5 POST
> 
>    If a resource has been created on the origin server, the response
>    SHOULD be 201 (Created) and contain an entity which describes the
>    status of the request and refers to the new resource, and a Location
>    header (see section 14.30).
> 
> ...I don't understand what it means for the response entity to describe
>  the status of the request, aside from setting the response status code,
> which is already known to be 201.

I think this is similar to the other issue. There should be HTML or XML
or ... of the form "I created this thing for you. Here it is."

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:744
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-02-17 22:59:39
Subject:detailed protocol writeup posted
Message:

I have written up the conversations on one-shot notifications in a
detailed way and posted it on the web at
http://www.gonze.com/http-notifications.html and
http://www.gonze.com/http-notifications.txt








-----------------------------------------------------------------------------------
Post ID:745
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-18 05:55:38
Subject:Re: [rest-discuss] detailed protocol writeup posted
Message:

Lucas Gonze wrote:
> 
> I have written up the conversations on one-shot notifications in a
> detailed way and posted it on the web at
> http://www.gonze.com/http-notifications.html and
> http://www.gonze.com/http-notifications.txt

It looks great but a few details:

 1. I don't see how the client knows WHERE to POST to the server. It may
have a priori knowledge but it may not. HTTPEvents allows the server to
tell the client where to POST through a header that is available on a
GET or HEAD. It also allows the server to generate a URI that obviates
the need for the Watched-Resource-URI. This should be step "0". My
mental model was that you could surf the web and the browser would tell
you (discreetly) when a watchable resource popped up. Same for Google.
It could spider around subscribing to things. If a particular
application wants to skip this step, it may, if it already has an
appropriate URI.

 2. I think you overspecify the structure of the notification. 
    * arguably methods should be application dependent...
    * I strongly feel that the input parameters should be application
dependent!
    * It should be possible for the response to trigger a
re-subscription through a magic header
    * "URI MUST change for each Step 1" - depends on the security level
of the app. Should not be overspecified.

>   Attackers are prevented from altering the meaning of a Step 4 (Notification)
>   by the following means: the only data transmitted in the Step 4
>   (Notification) is the fact that a pre-arranged callback URI has been
>   activated. The meaning of that URI is left entirely up to the sink, which
>   generates it, and to any information exchanged during a Step 1
>   (Subscription).

I think this is overspecified. The client and server might prefer to use
a signature.

>   Attackers are prevented from tricking a sink into believing that a Step 4
>   (Notification) has happened by the following means: the callback URI itself
>   is a secret until the source invokes it in the Step 4 (Notification), the
>   callback URI MUST be hard to guess (for example, by being a 50 character
>   random string), and the callback URI is never used more than once.

There is hardly any harm in being "tricked" into re-fetching the
resource too soon. This just complicates the implementation of the
client side of the protocol for little benefit.

 3. I haven't thought through all of the race condition issues and I'm
glad you have. But consider whether there are If-modified-since or
e-tags tricks you can use to avoid the contortions of inventing new URIs
and forcing a certain order of steps. I don't have time to think about
it right now but something seems inelegant about the level of effort you
need to go to to avoid race conditions.

Anyhow, the GET step should be optional because you may not care about
the current state of the resource. You only want to know if it changes.
For instance there may be a gateway that emails the user when the
resource changes. The gateway doesn't want to fetch the resource every
time. The user will fetch it when the user wants it.

You seem not to have dealt with something on my todo list for
HTTPEvents, container sub-resource changes. 

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:746
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-02-18 12:59:05
Subject:Re: [rest-discuss] detailed protocol writeup posted
Message:

Hey Paul,

>  1. I don't see how the client knows WHERE to POST to the server. It may
> have a priori knowledge but it may not. HTTPEvents allows the server to
> tell the client where to POST through a header that is available on a
> GET or HEAD.

Yup -- this strikes me as useful, so there's an analog down in "Enabling
Bot Inclusion", along with another possible alternative.

> It also allows the server to generate a URI that obviates
> the need for the Watched-Resource-URI. This should be step "0". My
> mental model was that you could surf the web and the browser would tell
> you (discreetly) when a watchable resource popped up. Same for Google.
> It could spider around subscribing to things. If a particular
> application wants to skip this step, it may, if it already has an
> appropriate URI.

If I understand this right, are you thinking the watched resource and the
watcher are the same thing?


>  2. I think you overspecify the structure of the notification.

Well, I was trying to do an experiment more than to write a standard.  I
wanted to know exactly what a callback design would have to do, what the
hard problems would be, where the low-hanging fruit would be, etc.  So the
high level of detail is about getting a really clear picture of the
problem set.

To the degree that I _was_ trying to write a recipe for implementors, it's
not so much a standard as a debugged algorithm.  For example, anything
that's a MUST is there because otherwise a critical feature won't work.
It happens that the language of standards is great for writing
meta-programs, that's the only reason I used it.

>     * arguably methods should be application dependent...
>     * I strongly feel that the input parameters should be application
> dependent!

...again, I defer to my experiment+recipe intent, vs. an intent to
standardize.

>     * It should be possible for the response to trigger a
> re-subscription through a magic header

I definately agree and spent a while working on that, but found that it
led me into turf where there's a persistent subscription to manage, and
didn't want to open up that can of worms.  In the short term it turned out
that having the source delete the sub once expiration is over or a
notification has been sent was a big advantage.

so, basically, figuring out how to do the re-sub automatically would be a
big win but I was hard pressed enough to do the minimum reasonably well
that had to put off the whole issue of persistence.

> There is hardly any harm in being "tricked" into re-fetching the
> resource too soon. This just complicates the implementation of the
> client side of the protocol for little benefit.

I will mull over this for a little while.

>  3. I haven't thought through all of the race condition issues and I'm
> glad you have. But consider whether there are If-modified-since or
> e-tags tricks you can use to avoid the contortions of inventing new URIs
> and forcing a certain order of steps. I don't have time to think about
> it right now but something seems inelegant about the level of effort you
> need to go to to avoid race conditions.
>
> Anyhow, the GET step should be optional because you may not care about
> the current state of the resource. You only want to know if it changes.
> For instance there may be a gateway that emails the user when the
> resource changes. The gateway doesn't want to fetch the resource every
> time. The user will fetch it when the user wants it.

Optionalness: good point.  Will do.  If-modified-since etc is also a good
thing, and I will dig around to bring this within the algorithm.

> You seem not to have dealt with something on my todo list for
> HTTPEvents, container sub-resource changes.

More?

(Sorry to post that big chunk of text and run, but I have a new consulting
gig starting today and so will be out of touch til late evening.)

- Lucas








-----------------------------------------------------------------------------------
Post ID:747
Sender:"Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-18 17:35:51
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

>
>I think it is important to show real business examples. I admit that I
>think in terms of technology and not business. I just know from what I
>hear from business people that the technological problems are similar to
>more standard protocol problems.

I also really like the grounding in real business examples - especially a 
'complex' message exchange like a purchase order and acknowledgment. My 
current job is heavily into that at the moment as well.
A tricky line to draw is whether when using HTTP, the HTTP request/respones 
messages are exactly equivalent to business documents (a purchase-order in a 
POST, and a purchase-order-ack in the response) or whether HTTP messages are 
delivery vehicles and the business documents span http messages (a response 
to a POST is only a 'delivery acknowledgement' and the purchase-order-ack is 
delivered to the sender somehow else (notification, new request, etc.)

I'm using the approach of transferring business documents between queues 
using http messages carrying soap formatted data, the http and soap 
responses only talk about successfull delivery - the content of the messages 
describe the 'success/failure' of the business transaction.

mike


_________________________________________________________________
Join the world�s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com







-----------------------------------------------------------------------------------
Post ID:748
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-02-18 18:31:12
Subject:Re: Idea: Simple Web Service Behaviour Language
Message:

"Mike Dierken" <mdierken@h...> wrote:
> I also really like the grounding in real business examples - 
especially a 
> 'complex' message exchange like a purchase order and 
acknowledgment. My 
> current job is heavily into that at the moment as well.
> A tricky line to draw is whether when using HTTP, the HTTP 
request/respones 
> messages are exactly equivalent to business documents (a purchase-
order in a 
> POST, and a purchase-order-ack in the response) or whether HTTP 
messages are 
> delivery vehicles and the business documents span http messages (a 
response 
> to a POST is only a 'delivery acknowledgement' and the purchase-
order-ack is 
> delivered to the sender somehow else (notification, new request, 
etc.)

Depends on the context and conditions of business relationship.
1. "I am the big dog and you will accept my order regardless."
Purchase-order-acceptance could be the HTTP response.

2. Supplier needs some time to decide whether to accept order or not.
HTTP response is receipt-ack only, Purchase-order-acceptance is 
delivered separately and later.  Requester must associate later 
response with original request to close transaction.

3. Negotiated order:  supplier may be allowed to propose changes to 
order - later delivery, split deliveries, substitute product, etc.
Response to original order could be rejection-with-counter-offer-
pending; Counter-offer starts a new transaction.

> I'm using the approach of transferring business documents between 
queues 
> using http messages carrying soap formatted data, the http and soap 
> responses only talk about successfull delivery - the content of the 
messages 
> describe the 'success/failure' of the business transaction.

A. How do you handle timeouts?
B. How do you handle order fulfillment?
C. Are these B2B?  
D. If B2B, what kind of items?  Supplies?
Products for resale?  Components for manufacture?
Business services?  Other?

Thanks,
Bob Haugen








-----------------------------------------------------------------------------------
Post ID:749
Sender:Paul Prescod <paulp@...>
Post Date/Time:2002-02-18 19:06:02
Subject:Re: [rest-discuss] detailed protocol writeup posted
Message:

Lucas Gonze wrote:
> 
>...
> 
> If I understand this right, are you thinking the watched resource and the
> watcher are the same thing?

No. The watched resource can POINT to a watcher that knows how to watch
it. That doesn't mean that you can't watch it if it does NOT point to
such a watcher. But if you use a third-party watcher then of course you
may lose notification granularity.

> >  2. I think you overspecify the structure of the notification.
> 
> ...
> 
> To the degree that I _was_ trying to write a recipe for implementors, it's
> not so much a standard as a debugged algorithm.  For example, anything
> that's a MUST is there because otherwise a critical feature won't work.
> It happens that the language of standards is great for writing
> meta-programs, that's the only reason I used it.

Isn't interoperability between independently authored clients and
servers a goal? If so, it is defacto a standard, if not a defacto
standard. ;)

> >     * arguably methods should be application dependent...
> >     * I strongly feel that the input parameters should be application
> > dependent!
> 
> ...again, I defer to my experiment+recipe intent, vs. an intent to
> standardize.

Even so, your "recipe" could say: "you could do X with these security
implications" as opposed to "you must do X because that's the most
secure way."

>...
> I definately agree and spent a while working on that, but found that it
> led me into turf where there's a persistent subscription to manage, and
> didn't want to open up that can of worms.  

Not clear on why a re-sub is the same as a persistent subscription to
manage....but if you leave the notification response body structure
undefined then maybe we can figure it out through experimentation.

>...
> so, basically, figuring out how to do the re-sub automatically would be a
> big win but I was hard pressed enough to do the minimum reasonably well
> that had to put off the whole issue of persistence.

Fair enough. Time is finite.

>...
> > You seem not to have dealt with something on my todo list for
> > HTTPEvents, container sub-resource changes.
> 
> More?

If I have a resource "/foo" and somebody does a POST to it to create
"/foo/bar" (yes, URIs are opaque but you know what I mean...a
subresource is created). Does that trigger a notification for "foo"? It
would be confusing to go look at "/foo" and see that it is exactly as
you left it. (because POSTing doesn't necessarily change the resource).

At one point I thought that it was important to have a feature to handle
this but thinking about it now I think the way to handle it is to have
"/foo" be a resource with a representation that points to all of its
sub-resources. Then it is intuitive that a change to a sub-resource
triggers a notification and it is relatively easy to figure out what
sub-resource appeared or disappeared by "diffing" your cached copy
against the sub-resources. But you could only figure out if a
sub-resource was mutated if the entity body had something like hashes or
last-modified-times for each sub-resource in it.

So I'm inclined to encourage you not to worry about it...

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:750
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-18 19:12:33
Subject:REST and Cross-network Scripting
Message:

Thought this exchange where I came to some agreement with Dave Winder
might be interesting.

http://aspn.activestate.com/ASPN/Mail/Browse/Plain/xml-dev?period=200202

Dave Winer says:
> Paul those are good compelling points, had they been raised before we built 
> an infrastructure for XML-RPC and SOAP at the script level. 
>  
> Earlier this month we finally implemented the top of the stack, something 
> called SCNS or Simple Cross-Network Scripting, which makes calling a web 
> service as simple as calling a procedure (yes it looks a little different, 
> and that's good, imho, people should know when they're making a networked 
> call. 

Paul Prescod says:
> REST is admittedly not about cross-network scripting. REST is about
> building web services. Here's what I see as the difference: with
> cross-network scripting you are trying to hide many of the differences
> between making a local call and making a remote call. That's great for
> ease of use but it sacrifies a bunch of stuff in terms of
> addressability, scalability, peformance and potentially security. I am
> totally in favour of this trade-off where it makes sense. I advocate
> XML-RPC as a viable alternative to REST with the caveat that I am
> nervous about its reliance on "ASCII" and a few other things like that.
> 
> REST is about taking the networking issues most seriously. This means
> that the interface to networked code is different than to local code.
> Not harder, but different. Both client and server have to think
> differently when they access networked code. You could paper over the
> differences on the client side with an OO library but this might
> introduce performance or reliability problems.
> 
> In my mind, web services are about doing the sorts of things we couldn't
> do with COM or CORBA (otherwise why invent a new buzzword) so I don't
> see XML-RPC (or SOAP RPC) as a Web Services technology. I am happy to
> promote XML-RPC as a cross-network scripting tool, however, and I have.

Dave Winer says:
> BTW, thanks for the positive energy -- I feel much better about this stuff
> now that it isn't all or nothing, as some people have cast it in the past.
> 
> I will look for an opportunity to define an interface, in public, both ways.


 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:751
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-19 01:57:31
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

>
> A. How do you handle timeouts?
The sender has a queue & stale messages will kick back a notification into
an 'outer workflow' manager.

> B. How do you handle order fulfillment?
It's out of band for our app - we just delivery the docs. If a business
document is defined for 'shipping notice' or 'delivery status' or whatnot,
we'll deliver those.

> C. Are these B2B?
Yes - bigco to smallbiz (hub & spoke today, Tomorrow The World (tm))


> D. If B2B, what kind of items?  Supplies?
> Products for resale?  Components for manufacture?
> Business services?  Other?
Don't know... currently mainly accounting types of docs for any industry,
product or service.









-----------------------------------------------------------------------------------
Post ID:752
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-02-19 13:13:02
Subject:Re: Idea: Simple Web Service Behaviour Language
Message:

"S. Mike Dierken" <mdierken@h...> wrote:
> > B. How do you handle order fulfillment?
> It's out of band for our app - we just delivery the docs. If a 
business
> document is defined for 'shipping notice' or 'delivery status' or 
whatnot,
> we'll deliver those.

Got any ideas on how you might RESTify this app?
Possibly relevant excerpt from REST Wiki FAQ:
<quote>
A good test of REST-fulness (though not complete by any means, since 
HTML forms fail) is, can I do a GET on the URLs that I POST to, and 
if so, do I get something that in some way represents the state of 
what I've been building up with the POSTs? 

For ebXML, the answer is "no". ebXML assumes that the POSTed 
documents disappear into each trading partner's internal business 
systems. However, the business process would actually work better if 
it was treated like a Web resource, for example an order resource, 
where all of the subsequent POSTs such as shipments, payments, etc. 
became sub-resources. Amazon puts your order on a Web page where you 
can track its status. B2B ecommerce is sometimes not so nice. 
</quote>









-----------------------------------------------------------------------------------
Post ID:753
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-20 00:57:00
Subject:REST made more concrete still
Message:

I had a much better idea of how to do static service declarations (as
per IDL or WSDL) for REST web services:

http://www.prescod.net/wrdl.html

It reflects the underlying Web Architecture much more clearly than my
old proposal did. It is consequently simpler. 

It has first-class concepts of "resource", "representation", "method",
"input" and "output". Methods are HTTP methods like PUT, GET, DELETE,
YOURMETHOD. Inputs are like HTTP method inputs: headers, query params
and body (the URI is implied by the resource!). Outputs are like HTTP
outputs: status code, headers and body. Resources know what
representations they support and you can navigate from resource to
resource through hyperlinks without worrying about the XML or HTML
syntax of the representation (unless you want to). Following a hyperlink
is a type-safe operation.

That's about all the concepts in it.

A rough proposal for an API (Java-ish syntax to prove it isn't biased
towards dynamic languages) is provided. Everything is statically type
checked just as with IDL or WSDL. Of course in Python everything would
be done at runtime and thus save a build step.

When I implement it I think it will be a really cool tool. Until then, I
think it is a useful pedagogic tool for those working on REST Zen. If
*you* want to implement it before I get around to it, in whatever
language, please do. I'll work with you to clear up any fuzzy parts of
the spec.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:754
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-20 03:53:42
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

>
> Got any ideas on how you might RESTify this app?
Yes - i've segregated the main 'methods' into.... post, reply, notify and
get (there will probably be a put also) - so a small number of methods on a
large number of resources. The reply happens after an initial response of
'accepted' (unless there is an immediate failure) and the notify is a
(currently optional) status update about that business document (like if a
manual approval process was successful). With a high fidelity access to a
business system these notifications would be common. But they are purely
optional for 'value added' capabilities.
The 'notify' identifies the 'resource' that it is 'about'.

mike






-----------------------------------------------------------------------------------
Post ID:755
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-02-20 03:46:22
Subject:Re: [rest-discuss] REST made more concrete still
Message:

Interesting! I've been thinking about APIs and frameworks that
encourage the use of REST ever since my experiment with RESTifying a
Web/LDAP gateway (which resulted in Wallal [1]). 

I see some similarities between the back-of-a-napkin sketches I've
done and what you propose here, but I was thinking more in terms of
just mapping resources <-> objects.


[1] http://www.mnot.net/wallal/




On Tue, Feb 19, 2002 at 04:57:00PM -0800, Paul Prescod wrote:
> I had a much better idea of how to do static service declarations (as
> per IDL or WSDL) for REST web services:
> 
> http://www.prescod.net/wrdl.html
> 
> It reflects the underlying Web Architecture much more clearly than my
> old proposal did. It is consequently simpler. 
> 
> It has first-class concepts of "resource", "representation", "method",
> "input" and "output". Methods are HTTP methods like PUT, GET, DELETE,
> YOURMETHOD. Inputs are like HTTP method inputs: headers, query params
> and body (the URI is implied by the resource!). Outputs are like HTTP
> outputs: status code, headers and body. Resources know what
> representations they support and you can navigate from resource to
> resource through hyperlinks without worrying about the XML or HTML
> syntax of the representation (unless you want to). Following a hyperlink
> is a type-safe operation.
> 
> That's about all the concepts in it.
> 
> A rough proposal for an API (Java-ish syntax to prove it isn't biased
> towards dynamic languages) is provided. Everything is statically type
> checked just as with IDL or WSDL. Of course in Python everything would
> be done at runtime and thus save a build step.
> 
> When I implement it I think it will be a really cool tool. Until then, I
> think it is a useful pedagogic tool for those working on REST Zen. If
> *you* want to implement it before I get around to it, in whatever
> language, please do. I'll work with you to clear up any fuzzy parts of
> the spec.
> 
>  Paul Prescod
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:756
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-20 04:21:03
Subject:Re: [rest-discuss] REST made more concrete still
Message:

I really like the idea of this - especially hashing things out via code...

----- Original Message -----
From: Paul Prescod <paul@...>
To: <rest-discuss@yahoogroups.com>; <xml-dev@...>; xml-sig
<xml-sig@...>
Sent: Tuesday, February 19, 2002 4:57 PM
Subject: [rest-discuss] REST made more concrete still


> I had a much better idea of how to do static service declarations (as
> per IDL or WSDL) for REST web services:
>
> http://www.prescod.net/wrdl.html
>
> It reflects the underlying Web Architecture much more clearly than my
> old proposal did. It is consequently simpler.
>
> It has first-class concepts of "resource", "representation", "method",
> "input" and "output". Methods are HTTP methods like PUT, GET, DELETE,
> YOURMETHOD. Inputs are like HTTP method inputs: headers, query params
> and body (the URI is implied by the resource!). Outputs are like HTTP
> outputs: status code, headers and body. Resources know what
> representations they support and you can navigate from resource to
> resource through hyperlinks without worrying about the XML or HTML
> syntax of the representation (unless you want to). Following a hyperlink
> is a type-safe operation.
>
> That's about all the concepts in it.
>
> A rough proposal for an API (Java-ish syntax to prove it isn't biased
> towards dynamic languages) is provided. Everything is statically type
> checked just as with IDL or WSDL. Of course in Python everything would
> be done at runtime and thus save a build step.
>
> When I implement it I think it will be a really cool tool. Until then, I
> think it is a useful pedagogic tool for those working on REST Zen. If
> *you* want to implement it before I get around to it, in whatever
> language, please do. I'll work with you to clear up any fuzzy parts of
> the spec.
>
>  Paul Prescod
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:757
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-20 05:17:49
Subject:Re: [XML-SIG] REST made more concrete still
Message:

akuchlin@... wrote:
> 
> On Tue, Feb 19, 2002 at 04:57:00PM -0800, Paul Prescod wrote:
> >http://www.prescod.net/wrdl.html
> 
> Hmmm... I'm trying to wrap my head around this.

It's very rough right now. Release early and often. It's changed its
name three times this week. ;) More a direction to get people thinking
then something clearly implementable.

> * In the example, purchaseOrder has the query string declared as type
>   integer.  In the invocation example, at no point is this integer parameter
>   supplied.

Yeah, I didn't align the examples. That's confusing. For now I'll
mention that fact and then later I'll go through and do that.

> * I don't understand the match attribute of 'representation'; does it mean
>   that "if the XPath expression returns a non-empty set of nodes, the
>   document is considered to match this representation type.  The set
>   of matching nodes is then discarded, having served its purpose."

Now that you mention it, the equivalent in XSLT is not exactly match but
"test" 

http://www.w3schools.com/xsl/xsl_if.asp

I'll add a pointer to that for those who don't know XSLT.

> * I also don't understand the sentence about " This is not a problem
>   because representations are only checked in a boolean fashion..."
>   This doesn't clarify what happens if a document matches multiple
>   representation types; is it considered to be all of those matching types,
>   or just one of them?

At the time I wrote that it really didn't matter. It's like a type check
of whether a thing is an integer or a float. As long as it matches you
don't really care. Once the API is flushed out we might start caring
because coding is easier if you can ask "what's this I've got" instead
of looking at the elements and attributes. But then maybe that should be
left to an orthogonal (but integrated) XML data binding layer.

> * How do you know when a new resource has been created in response to
>   some request?  Is that indicated in the returned document in some way
>   dependent on its schema?  (Say, if it has a <new-resource> element in it.)
>   Or is it an HTTP header or something like that?

Have to think a little bit more about that to check whether I've got it
right...

The only methods that really create new resources are PUT and POST. PUT
always creates a new resouce unless it fails. POST returns a Location:
header. I've been back and forth over and over again on whether this
needs to be declared in advance and what it means for the API. 

View 1:

The Location: header is probably irrelevant...the representation
returned by POST should point to the new thing that's created. Do you
care whether it really, really created something new or if it happened
to point to something it already had?

View 2:

HTTP privileges a particular URI in the entity as the "location" URI. I
think that logically everything else in the entity is just wrapping
around that main URI. So "creation" is important and should have
first-class support.

This minute View 2 is stronger in my mind.

> * In the 'po' representation type, what are the approve and cancel
>   references intended to be, semantically?  Are they resources that you could
>   POST to in ordr to approve or cancel the order, or something else?

Yes, they are sort of trigger resources. Since REST-style denies you the
luxury of attaching arbitrary methods to resource you "run out" of
methods sometimes. So you either 

 a) pull this trick
 b) do RPC (POST a do-what-I want)
 or 
 c) think of a noun-ification of what you want and POST it. As in post a
"CANCELLED-PO resource". I'm not sure if this is really different than
RPC.

I think this trick is best because when we get event-handling and
orchestration integrated you'll be able to set up a chain of events so
that when resource A changes it triggers a POST to one of these trigger
resources. So you could say that when the boss's digital signature
resource appears in one place the approval method is triggered
automatically.

>   (Having them be xsltResources makes it really unclear what they're
>   supposed to be.)

Typo. I'll change those to "digitalSignatureResource" to be more
realistic. And really they could respond to PUT instead of POST. This
make sense to you:

<resourceType name="digitalSignature"
representations="some-dsig-standard">
    <method name="PUT"/>
</resourceType>

> * Am I going to have to invent 187 different schemas for an application?
>   Say a resource has a bunch of subresources: an owner, a history, etc.
>   Some of these might use an existing schema -- RDF, HTML, whatever --
>   but some might return something simple or ad hoc, such as just a
>   string or an integer.  Do I have to dress up this return value as:
> 
> <dummy-root>http://newuri/</dummy-root>
> <dummy-root>35</dummy-root>
> 
>   Or could I declare "treat the body of this action as a string/integer/
>   new URI"?

Several answers to this:

1. I would expect these minor sub-resources to be grouped into a single
logical object. REST encourages coarse-grained, not fine-grained
interactions -- big difference from RPC.

2. I may one day add WebDAV support. WebDAV is very REST-y in that it is
an HTTP extension even if it is not perfectly REST-y. And it has a
first-class notion of properties.

3. But even to do that ad-hoc stuff you don't need 187 schemas. You can
use the XML-RPC or SOAP encoding or WDDX schema for hundreds of ad-hoc
apps. Or just define a schema where <xsd:integer> is of type
<xsd:integer> etc.

4. You could also use MIME-RPC media-types instead of XML at all.
http://www.mime-rpc.com/protocol.html

> I have a project currently specified as a set of XML-RPC interfaces;
> RESTifying it will make an interesting thought experiment.

Cool. I don't always suggest switching from XML-RPC to REST, though. The
terminology I use (now) is that XML-RPC is better for "cross-network
scripting" and REST is for building big, long-lived, scalable,
extensible apps.

I'll fix those bugs. Pedagogic ones are more important at this stage
than ambiguities because it is more a thought experiment than a real
spec.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:758
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-20 13:00:05
Subject:Re: [XML-SIG] REST made more concrete still
Message:

akuchlin@... wrote:
> 
>...
> 
>    REST version:
>    GET master/list_services
>    Returns a list of services as the body.
>    XXX should the optional 'application argument be a URL parameter? Then
>    you'd do "GET master/list_services;scope" to get all the microscope
>    services. Or should it be the query string?

Good question. I think that the answer is:

 * URIs are mostly opaque. This gives you tremendous flexibility as an
application designer. If you relate to resources through a URI then you
could actually move one resource physically to another mean and just
update the link.

 * ;-parameters are opaque. So if you use them, you are saying that
client software should NOT understand what the stuff after the semicolon
means. 

 * ?-parameters are not opaque. You're saying that it's okay for the
client to try to understand tha part of the URI and fiddle with the part
after the ? mark. 

Practically speaking you could use "?" if you want to allow an HTML
forms client to work with this stuff. That's a way of thinking through
whether you mean for it to be opaque.

>    XXX how should the returned result, which are (service ID, application
>    ID, host, port) 3-tuples, be encoded? As an XML-RPC array of structs?
>    As a little custom XML schema?

No real advice. Depends on whether you are trying to make life really
easy for the client (xmlrpc.decode()) or whether you want to have other
people elsewhere on the Web support your little "schema" (in which case
a formal definition woudl be better) and whether you think message
self-descriptiveness is important or not. A merger might look like:

<array role="service_description"><int role="id">..</int><int
role="host">...</int>...</array>

Costs and benefits to everything. Also consider an element with three
attributes. Compact, very readable and trivial to work with in a DOM.

But then again, maybe this resource should just be *hyperlnks* to the
services. You could have an optimized "report" sub-resource for fetching
batch data, but I like the idea that Matisse server could incorporate
services described on other people's boxes just by reference. Part of
the benefit of REST. You might not take advantage of it but another
Mattise interface implementor might. ;) Build a web of Matisse's!

> \begin{methoddesc}{get_service}{service}
> Returns a struct (= a Python dictionary or a Java \class{Vector}
> instance) with information about the given service.  The contents of
> the struct are explained below.  \var{service} is a string containing
> a service ID.
> \end{methoddesc}
> 
>    REST version: GET master/service;service ID. Returns an HTTP body,
>    encoded using the same schema/form as list_services().

I'd use "/" instead of ";" to indicate hierarchy but it doesn't matter
much.

> Interface: Login
> 
> \begin{methoddesc}{get_service_ticket}{user_id, password, service_id}
> If the user ID and password are correct, returns a string containing a
> ticket for the given service.  If they're wrong, it will raise a fault
> with the fault code 1 and fault string ``IncorrectPassword''.
> \var{user_id}, \var{password}, \var{service_id} are all strings.
> \end{methoddesc}
> 
>    REST version: POST master/get_service_ticket. This must be HTTP
>    authenticated with the username (meaning a human-friendly ID as
>    opposed to a URI?) and password. The body is the service ID. Returns
>    an authorization ticket as the body.
>    XXX should the service ID be specified as a query string?
>    XXX or should this be a subset of the service's URI, so you'd access
>    master/(service ID)/get_ticket, instead?

Yes, I like this latter one. *BUT* /-separated URIs are opaque so to be
REST-y you need to have service_ids point to their ticket granting
components. The client shouldn't just paste together the URI. Once again
the virtue is that you can put the ticket granting component on any box
on the Web. Plus spiders can follow the links but not guess your URI
conventions.

Should the ticket be a resource? Here's are arguments in favor: the
client can DELETE when it is done with it. When we add notifications to
HTTP, the client could WATCH it to see if the server DELETEs it because
the client is kicked off or something. A client that is kicked off could
do a GET to see if the authorization ticket disappeared or was just
replaced.

Of course, like anything, you need to decide when more REST is more
effort for not enough gain.

> Interface: Authorization
> 
> \begin{methoddesc}{check}{user_id, service_id}
> Returns a Boolean value.  Returns true if the user \var{user_id}
> is permitted to access the service identified by \var{service_id}.
> \end{methoddesc}
> 
>    REST version: POST master/check_auth
>    XXX how should the two parameters be passed? (XML-RPC again?)

Why not query params?

I notice you have multiple top-level URIs. I think you should have a
Matisse.xml which is a tiny vocabulary that points to them for the URI
opacity reason I've given before. One day you may move some methods off
for load reasons or something and you can do that by just redirecting a
URI. Plus this is a simple form of interface introspection.

> Interface: MetadataStore
> 
> \begin{methoddesc}{get_cache_location}{ticket, metadata}
> \var{ticket} and \var{metadata} are both strings.  Returns a string
> containing an FTP URL; the data should be stored to this URL.
>
> (Rationale for choosing FTP: it's standard, it seems hard to improve
> on it for shipping data at high speed, and the DPSS code supports it.)
> \end{methoddesc}

Does anyone use "NETBLT"? Someone pointed me at it a few months back.
 
>    REST version: POST master/get_cache_location. The body is your
>    authorization ticket. The returned body is the new URI for the data
>    time. HTTP PUT the content to the URI to store the data; HTTP PUT the
>    metadata to URI/metadata to store it.
>    XXX what if you crash after getting the new URI? You now have an empty
>    resource. Can this all be done in one HTTP operation?

Sure. Shove as much data as you want down the POST. Maybe it's mildly
non-HTTP-ish to create two resources with a single POST but it is very
mild. If you want to be a purist, use HTTP POST and then a PUT for the
metadata. Have the data time URI point to its metadata.

Method names that start with "get_" bother me because they seem RPC-ish.
Ones that start with get_ and do a POST kind of freak me out. ;) Maybe
generate_data_time or something. Why is this a POST at all instead of a
GET (perhaps dynamic)?

> Interface: MetadataSearch
> 
> \begin{methoddesc}{search}{ticket, condition1, condition2, ...}
> Returns a list of metadata IDs that match all of the given conditions.
> 
> ... full description deleted ...
> \end{methoddesc}
> 
>    REST version: No equivalent is attempted. You could let Google crawl
>    the URIs for your data, build RDF or topic maps or whatever you like.
>    This interface goes away and is replaced by the panoply of search
>    technologies available for the Web.

ZEN! 

Of course you can always provide a search facility if you want using
query params. There's nothing wrong with it if you can implement it more
efficiently server side.

> Interface: Preferences
> 
> \begin{methoddesc}{get_preferences}{ticket, service/application}
> Retrieve a string containing preferences information.
> \end{methoddesc}
> \begin{methoddesc}{set_preferences}{ticket, service/application, prefdata}
> Store the string \var{prefdata} containing preferences information.
> \end{methoddesc}
> 
>    REST version: easy! To get preferences, POST
>    user-URI/prefs/applicationID, passing an authorization ticket as the
>    body. To set preferences, PUT to the same URI, passing the preference
>    data in the body.

If authorization tickets are resources then you can do a GET of the same
form as this:

user-URI/prefs/applicationID?URI_encoded_authorization_URI....

GET and PUT go nicely together. ;)

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:759
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-02-20 15:33:30
Subject:Re: [XML-SIG] REST made more concrete still
Message:

Paul Prescod <paul@p...> wrote:
>I didn't align the examples. That's confusing. For now I'll
> mention that fact and then later I'll go through and do that.

I think it would help me understand a lot better if you showed the 
resulting Web resource hierarchy. 

I'm still confused by a previous version where (I thought) you 
intended to model states of purchase orders by changing the PO 
identity. I'm still not clear about exactly what you meant, or if 
that idea is still part of the proposal.  

It would also be useful if you showed how the PO gets accepted.  
Purchase orders represent contractual bindings between buyer and 
seller and should be explicitly accepted in some way (according to 
some explicit rules).  (I agree that representing the rules in linked 
XML business process scripts is the right way to do it.)

(I assume "approved" is internal, the boss's approval, and not the 
same as "accepted" by the seller.)

One more sort-of side issue:  we found in ebXML that digital 
signatures could not be used (all by themselves) to indicate 
acceptance, because they are used for so many other purposes. 
(Rejections should be signed, too.)  The content of the signed 
document or message should explicitly declare its intent.

Thanks,
Bob Haugen







-----------------------------------------------------------------------------------
Post ID:760
Sender:Andrew Kuchling <akuchlin@...>
Post Date/Time:2002-02-20 19:44:06
Subject:Re: [XML-SIG] REST made more concrete still
Message:

On Tue, Feb 19, 2002 at 09:17:49PM -0800, Paul Prescod wrote:
>3. But even to do that ad-hoc stuff you don't need 187 schemas. You can
>use the XML-RPC or SOAP encoding or WDDX schema for hundreds of ad-hoc
>apps. Or just define a schema where <xsd:integer> is of type
><xsd:integer> etc.

It seems to me that you'd need two very simple schemas to handle these
ad-hoc bits.  One is simply for data structures in your programming
language, and could be XML-RPC (but there's no None in it!), SOAP, or
a language-independent xml_pickle (aren't there a few such
proposals?).  Another would be a schema for specifying what sublinks a
resource makes available; this might be your REST specification
schema, or something else.

--amk                                                  (www.amk.ca)
Non-masochists, please delete this article NOW.
    -- Aaron Watters, 20 Jan 1995






-----------------------------------------------------------------------------------
Post ID:761
Sender:Andrew Kuchling <akuchlin@...>
Post Date/Time:2002-02-20 20:50:37
Subject:Re: [XML-SIG] REST made more concrete still
Message:

Paul, note that I only mailed my note to the XML-SIG.  To explain all
this to rest-discuss readers: I took a set of XML-RPC interfaces and
tried writing out a REST equivalent.  My RESTification is described at
http://www.amk.ca/conceit/rest-version.html, and I posted a version of
it to the Python XML-SIG, which is what Paul is replying to.

Thrashing onward...

On Wed, Feb 20, 2002 at 05:00:05AM -0800, Paul Prescod wrote:
>Practically speaking you could use "?" if you want to allow an HTML
>forms client to work with this stuff. That's a way of thinking through
>whether you mean for it to be opaque.

OK, so let's make a few decisions and remove some of those XXX's.
I'll use the query string for this purpose, and will use XML-RPC's
serialization format for bodies that return an arbitrary little data
structure.

>But then again, maybe this resource should just be *hyperlnks* to the
>services. You could have an optimized "report" sub-resource for fetching

So what would these hyperlinks be written in?  HTML, generic XLink,
something custom?  Aha!  You just have to give them names, so it would
be OK to just say <link name='ticket' href='.../ticket'/>.  Your
programming language binding would then let you do something like:

serv = Service(<uri>)
ticket = serv.ticket.GET(username, password)

Hm... I'm starting to get that itchy implementing feeling.

>>    REST version: GET master/service;service ID. Returns an HTTP body,
>>    encoded using the same schema/form as list_services().
>
>I'd use "/" instead of ";" to indicate hierarchy but it doesn't matter
>much.

Of course, when you use '/', the resulting URL
<master>/service/serviceId looks just like the URI for that service!
That actually makes things simpler; got a service URI?  Just hit it to
find where that service lives.  And <service URI>/ticket can then be
how you get a ticket for that service, and <service
URI>/check_auth?user_id is how you check whether a user can access
that service.

>Should the ticket be a resource? Here's are arguments in favor: the
>client can DELETE when it is done with it. When we add notifications to
>HTTP, the client could WATCH it to see if the server DELETEs it because
>the client is kicked off or something. A client that is kicked off could
>do a GET to see if the authorization ticket disappeared or was just
>replaced.

Interesting possibilities, but they'd make this REST version way more
complicated than the XML-RPC version.  More powerful, too, of course
-- the WATCH idea is particularly neat -- but I want to stay close to
the original version's capabilities.

>>    REST version: POST master/check_auth
>>    XXX how should the two parameters be passed? (XML-RPC again?)
>
>Why not query params?

How about just this: POST <service URI>/check_auth?user_id, returning
an XML-RPC encoded Boolean.  And the interface gets a little bit
simpler, again.

>I notice you have multiple top-level URIs. I think you should have a
>Matisse.xml which is a tiny vocabulary that points to them for the URI
>opacity reason I've given before. One day you may move some methods off
>for load reasons or something and you can do that by just redirecting a
>URI. Plus this is a simple form of interface introspection.

So this could potentially be as simple as just name/URI pairs since
these are just hyperlinks, right?.  Return types and all that could be
added later, but aren't mandatory.

>>    XXX what if you crash after getting the new URI? You now have an empty
>>    resource. Can this all be done in one HTTP operation?
>
>Sure. Shove as much data as you want down the POST. Maybe it's mildly
>non-HTTP-ish to create two resources with a single POST but it is very
>mild. If you want to be a purist, use HTTP POST and then a PUT for the
>metadata. Have the data URI point to its metadata.

I think I like the POST+PUT approach.  Putting two resources, data +
metadata, in a single POST isn't practical because the data might be
very large, say a couple of gigabytes.

>Method names that start with "get_" bother me because they seem RPC-ish.
>Ones that start with get_ and do a POST kind of freak me out. ;) Maybe
>generate_data_time or something. Why is this a POST at all instead of a
>GET (perhaps dynamic)?

Revised REST version: POST <master>/new_cache_location?<ticket>.  The
body is the data to be stored.  You will be returned a Location:
header with the new URI for the data object.  GET from the new URI to
get a URI for the metadata (probably URI/metadata); HTTP PUT the
metadata to store it.

>> Interface: MetadataSearch
>>    REST version: No equivalent is attempted. You could let Google crawl
>>    the URIs for your data, build RDF or topic maps or whatever you like.
>>    This interface goes away and is replaced by the panoply of search
>>    technologies available for the Web.
>Of course you can always provide a search facility if you want using
>query params. There's nothing wrong with it if you can implement it more
>efficiently server side.

Then again, if I have private data that I don't want Google to index
for all the world to see, using HTTP+URIs doesn't buy me much.  And
even if they're public, Google doesn't index arbitrary XML documents.
(Stray thought: I wonder if you could crawl the world's XML documents
and efficiently support an XPath query over them all?)

>> Interface: Preferences
>>    REST version: easy! To get preferences, POST
>>    user-URI/prefs/applicationID, passing an authorization ticket as the
>>    body. To set preferences, PUT to the same URI, passing the preference
>>    data in the body.

I'm not sure whether preferences are a property of the user, indexed
by application, or a property of the application indexed by user.  If
the latter, then GETting/PUTting to <service-URI>/prefs?<URI-encoded
ticket> works nicely.

Hmmm... there are no more XXX's in my text, the rewritten REST version
now uses GET instead of POST in many places, and in fact the
new_cache_location method is the only one left that uses POST.  The
REST version is beginning to seem fairly clean, and roughly comparable
in complexity to the XML-RPC version, given the right set of
client-side abstractions.  Interesting...

--amk                                                  (www.amk.ca)
But are not the dreams of poets and the tales of travellers
notoriously false?
    -- H.P. Lovecraft, "The Street"






-----------------------------------------------------------------------------------
Post ID:762
Sender:"Inggs, Andrew" <andrew.inggs@...>
Post Date/Time:2002-02-20 21:35:54
Subject:REST applied to provisioning
Message:

After reading Paul Prescod's REST article on XML.com I was
instantly converted :-).  I'm trying to apply REST principles to
a provisioning interface I'm working on.  The interface creates
typical VISP (virtual ISP) services such as a website or email
account.

At the highest level I've defined what I call a profile, it looks
something like this:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE viml SYSTEM "viml.dtd">
<viml>
  <profile username="user1">
    <website domain="www.customer.com">
      <!-- the path (below) is mainly useful for customers that
           don't get their own domains, in which case it would
           typically be /username
        -->
      <path>/</path>
      <password>secret1</password>
      <storage-space>15</storage-space> <!-- MB -->
      <bandwidth>50</bandwidth> <!-- MB/day -->
    </website>
    <email-domain domain="customer.com" type="standard">
      <email-account local-part="me">
        <password>secret2</password>
        <storage-space>5</storage-space> <!-- MB again -->
        <email-alias alias="myself"/>
      </email-account>
    </email-domain>
  </profile>
</viml>

Which provisions

 - The website http://www.customer.com/
   with FTP access using the given password
 - The email address me@...
   with POP3 access using the given password
 - The email alias myself@...
   which really goes to me@...

An email domain can also have type="backup" which means it
accepts mail for relay only, i.e., the customer has their own
mail server and uses us as backup.

URIs have the form:

    http://server/visp/serviceid/vispid/identifier

That's a little difficult to understand, so here's an example:

    http://server/visp/website/xyz/user1
    ^^^^^^^^^^^^^^^^^^
    Fixed

In this case the serviceid is website, the vispid is xyz, and
the identifier is user1.  The idea is that you can make the
identifier more complex to drill down to only one component of
the profile, e.g., to refer to the alias in the example above:

    http://server/visp/email-alias/xyz/user1/customer.com/me/myself

Now when the XYZ client wants to provision some services for a
new user who's signed up, they need to create the services.
At the moment, for the above example, this would mean doing
the following PUTs with the given data:

PUT /visp/website/xyz/user1/www.customer.com

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE viml SYSTEM "viml.dtd">
<viml>
  <website domain="www.customer.com">
    <path>/</path>
    <password>secret1</password>
    <storage-space>15</storage-space>
    <bandwidth>50</bandwidth>
  </website>
</viml>

PUT /visp/email-domain/xyz/user1/customer.com

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE viml SYSTEM "viml.dtd">
<viml>
  <email-domain domain="customer.com" type="standard"/>
</viml>

PUT /visp/email-account/xyz/user1/customer.com/me

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE viml SYSTEM "viml.dtd">
<viml>
  <email-account local-part="me">
    <password>secret</password>
    <storage-space>5</storage-space>
  </email-account>
</viml>

PUT /visp/email-alias/xyz/user1/customer.com/me/myself

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE viml SYSTEM "viml.dtd">
<viml>
  <email-alias alias="myself"/>
</viml>

Some things can be updated, for example, the storage space or
password for a website, others must be deleted and recreated,
like email aliases.

Problems I have with my own design:

 - If I were a client I would expect to be able to send a
   whole profile and have everything provisioned at once.
   This is not insurmountable, just more effort (and some
   thinking about transactional guarantees, if any).

 - There is redundant data in each request that is already in
   the URI.  This means extra processing on both sides, and an
   extra check on my side -- and what do I do if there's a
   mismatch?

 - For an update (POST) it's not always clear what can and
   can't change.  For example, when updating a website you can
   change the password but not the path.  In the case of an alias
   you can't even do an update.  I see problems ahead.

I feel like I'm almost there, but I'm still missing something.
Any comments or suggestions for improvement welcome.

-- Andrew






-----------------------------------------------------------------------------------
Post ID:763
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-21 01:01:16
Subject:Re: [rest-discuss] REST applied to provisioning
Message:

"Inggs, Andrew" wrote:
> 
>...
> URIs have the form:
> 
>     http://server/visp/serviceid/vispid/identifier
> 
> That's a little difficult to understand, so here's an example:
> 
>     http://server/visp/website/xyz/user1
>     ^^^^^^^^^^^^^^^^^^
>     Fixed
> 
> In this case the serviceid is website, the vispid is xyz, and
> the identifier is user1.  The idea is that you can make the
> identifier more complex to drill down to only one component of
> the profile, e.g., to refer to the alias in the example above:
> 
>     http://server/visp/email-alias/xyz/user1/customer.com/me/myself

If client applications are supposed to care about the structure of the
URI then you should use query parameters. The /s/s/s/s/ part of the URI
is supposed to be opaque to client software. Only the server knows or
cares what the slashes mean.

The best way to establish hierarchy is through XML documents where the
parent has hyperlinks to the children and they have hyperlinks to their
children and so forth. Consider, for example, how easy it becomes to
write a spider that slurps up the structre and moves it. (if you
consider that a good thing...otherwise forget I said it. ;)

> Now when the XYZ client wants to provision some services for a
> new user who's signed up, they need to create the services.
> At the moment, for the above example, this would mean doing
> the following PUTs with the given data:
> 
> PUT /visp/website/xyz/user1/www.customer.com
> 
> <?xml version="1.0" encoding="iso-8859-1"?>
> <!DOCTYPE viml SYSTEM "viml.dtd">
> <viml>
>   <website domain="www.customer.com">
>     <path>/</path>
>     <password>secret1</password>
>     <storage-space>15</storage-space>
>     <bandwidth>50</bandwidth>
>   </website>
> </viml>

I would use a POST for two reasons. First, uses of PUTs to brand new
URIs that the client creates are not opaque. Second, you don't have to
duplicate the data, as you noticed.

PUTs are okay for creating new things when there is a good reason for
the client to "own" the namespace as in a content management situation. 

>...
> Problems I have with my own design:
> 
>  - If I were a client I would expect to be able to send a
>    whole profile and have everything provisioned at once.
>    This is not insurmountable, just more effort (and some
>    thinking about transactional guarantees, if any).

POST can handle that.

>  - There is redundant data in each request that is already in
>    the URI.  This means extra processing on both sides, and an
>    extra check on my side -- and what do I do if there's a
>    mismatch?

POST can handle that.

>  - For an update (POST) it's not always clear what can and
>    can't change.  For example, when updating a website you can
>    change the password but not the path.  In the case of an alias
>    you can't even do an update.  I see problems ahead.

Actually, you should use *PUT* for updates and POST for creating new
stuff. It's helpful to read the definitions of the major methods here:

http://www.w3.org/Protocols/rfc2068/rfc2068

Anyhow, are your update problems really any different than validation
problems? Trying to update a password is logically impermissable so you
return an error, just like if you tried to put an integer where a phone
number should go.

Hope those ideas help.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:764
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-02-21 17:05:49
Subject:REST and the Real World
Message:

The subject article, at
http://www.xml.com/lpt/a/2002/02/20/rest.html
is really excellent.

This comment is just a minor quibble.
In the article, Paul Prescod wrote:
"Once you begin to orchestrate multiple web services, transaction 
processing becomes much harder. It is very difficult for the client 
to get the various services to have a common view of a "transaction" 
so that a failure on any service causes a complete rollback on all of 
them. HTTP does not have a magical solution to this problem but 
neither do specifications such as SOAP or ebXML. The solutions 
proposed by the OASIS Business Transactions working group are 
currently protocol agnostic and should work fine with HTTP."

ebXML does have a business transaction protocol.

It is the same as the RosettaNet PIP protocol, and has also been used 
previously in telecommunications.

The documents describing it are way too complicated for their own 
good, but the protocol is fairly simple.  It is a two-party set of 
stereotyped messages with timeouts that either succeed completely or 
fail completely.  The goal is business state alignment instead of 
database transactions.  An example of business state alignment:  the 
Purchase Order was either accepted or rejected or the transaction 
failed due to a timeout.

The OASIS Business Transaction group dismisses the ebXML/RosettaNet 
transaction protocol as too simplistic (last I saw).  They provide 
for multi-party transactions, which ebXML/RosettaNet do not.  On the 
other hand, we in ebXML have not found any multi-party business 
process so far that could not be broken down into orchestrated sets 
of two-party commitments and thus two-party transactions.

ebXML business transactions are described in:
http://homepage.interaccess.com/~linkage/COOL.ppt 
http://www.ebxml.org/specs/ebBPSS.pdf
http://www.ebtwg.org/projects/documentation/bioreference/pdf/Chapter9_
Patterns.pdf

-Bob Haugen










-----------------------------------------------------------------------------------
Post ID:765
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-21 20:45:50
Subject:Re: [rest-discuss] Re: [XML-SIG] REST made more concrete still
Message:

Andrew, Paul --- I think this is a great thread!  It's nice to see somebody
looking at RESTifying an already-designed XML-RPC interface with a possible eye
towards implementation instead of simply as a thought experiment.  And the idea
about language binding is *juicy...*  (Hint, hint, Andrew. ;-)

Just a few comments, with the proviso that my understanding of Matisse is
limited to a single read-through of the REST and RPC specs.

> <service
> URI>/check_auth?user_id is how you check whether a user can access
> that service.

This is more an aesthetics-of-naming comment than anything else, but it seems to
me that there's a more "resourceful" way to model this.  How about

<serviceURI>/users
  GET returns a collection of authorized users for this service
...and optionally....
  POST of <something?> if authorized adds a user to this service, creating a new
userID
  PUT of <something?> if authorized replaces the collection of authorized users

<serviceURI>/users/userID
  GET returns a struct describing the user, if it exists and is authorized; 404
means not authorized
...and optionally...
  POST / PUT update or replace user by userID
  DELETE removes a user

Note that while the controversy rages on over whether URI and verbs (e.g.
"check_auth") are in some way incompatible, the more I work through these things
the more I find that (a) verbs-as-resources usually aren't necessary, and (b)
URI-izing what are otherwise parameters to methods / verbs generally results in
the exposure of domain objects as interesting resources in their own right.

> Interesting possibilities, but they'd make this REST version way more
> complicated than the XML-RPC version.  More powerful, too, of course
> -- the WATCH idea is particularly neat -- but I want to stay close to
> the original version's capabilities.

Ignoring WATCH, it's still probably useful to consider whether making tickets
into resources adds some value to what you're doing....  IMO but admittedly at
first glance, it would seem that making authentication / authorization tickets
first-class citizens of URI space is a powerful idea.

> How about just this: POST <service URI>/check_auth?user_id, returning
> an XML-RPC encoded Boolean.  And the interface gets a little bit
> simpler, again.

Cf. above comments about URI-izing users, user_ids, etc.  While it makes the
interface slightly larger, it seems much more RESTful and flexible to me without
adding a whole lot to implementation complexity or bulk.

> >Sure. Shove as much data as you want down the POST. Maybe it's mildly
> >non-HTTP-ish to create two resources with a single POST but it is very
> >mild. If you want to be a purist, use HTTP POST and then a PUT for the
> >metadata. Have the data URI point to its metadata.
>
> I think I like the POST+PUT approach.  Putting two resources, data +
> metadata, in a single POST isn't practical because the data might be
> very large, say a couple of gigabytes.

Call me a purist, but it seems that this is the correct way to do this.  Having
the metadata be a subresource of the data URI, hyperlinking them, and operating
on them independently via separate methods adds much flexibility.  (Think:  it
could then be possible to eventually use content negotiation to return different
representations of the data URI's metadata...  yummy. :-)

> Revised REST version: POST <master>/new_cache_location?<ticket>.  The
> body is the data to be stored.  You will be returned a Location:
> header with the new URI for the data object.  GET from the new URI to
> get a URI for the metadata (probably URI/metadata); HTTP PUT the
> metadata to store it.

Yup.  Nitty aesthetic naming suggestion:  how about <master>/cache instead of
all that new_cache_location stuff?

> Then again, if I have private data that I don't want Google to index
> for all the world to see, using HTTP+URIs doesn't buy me much.

Well, not necessarily true.  The benefit is that you've got all your domain
objects named and structured and accessible via a generic interface, which makes
integrating with / extending these things much, much easier.  There's lots of
benefits to this besides making this stuff Google-friendly.

> I'm not sure whether preferences are a property of the user, indexed
> by application, or a property of the application indexed by user.  If
> the latter, then GETting/PUTting to <service-URI>/prefs?<URI-encoded
> ticket> works nicely.

I agree, and I think this is a better way to look at the problem.

jb








-----------------------------------------------------------------------------------
Post ID:766
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-21 22:40:56
Subject:Using the At Sign in HTTP URI
Message:

I need a spec lawyer! ;-)  So we've had various discussions of this
topic on this and other lists in the past, with various conclusions...
will somebody clear something up for me?  Is the following:

    http://foo.bar.com/users/joe@...

a valid HTTP URI or not?  If so, what does it mean?  Skipping straight
to the meat, my conclusion is that, grammatically per RFC 2396 and 2616,
the above probably *should* and is probably *intended* to be a valid URI
without an authority component --- i.e., the '@' sign is not used to
separate the elements of an authority component, but rather
"joe@..." is an opaque segment --- but strictly speaking it's
impossible to determine whether this is the case or not.  Comments?
Dangers of using this form of URI?  Etc.?

jb

--------
Details
--------

RFC 2396, 2.2:

   Many URI include components consisting of or delimited by, certain
   special characters.  These characters are called "reserved", since
   their usage within the URI component is limited to their reserved
   purpose.  If the data for a URI component would conflict with the
   reserved purpose, then the conflicting data must be escaped before
   forming the URI.

      reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                    "$" | ","

   The "reserved" syntax class above refers to those characters that are

   allowed within a URI, but which may not be allowed within a
   particular component of the generic URI syntax; they are used as
   delimiters of the components described in Section 3.

3.2. Authority Component

   Many URI schemes include a top hierarchical element for a naming
   authority, such that the namespace defined by the remainder of the
   URI is governed by that authority.  This authority component is
   typically defined by an Internet-based server or a scheme-specific
   registry of naming authorities.

      authority     = server | reg_name

   The authority component is preceded by a double slash "//" and is
   terminated by the next slash "/", question-mark "?", or by the end of

   the URI.  Within the authority component, the characters ";", ":",
   "@", "?", and "/" are reserved.

...but we're beyond the authority component, at least semantically, in
my example URI.  It may be that some parsers incorrectly use the first @
symbol to identify the authority component...  strictly, though, it
would appear that everything's good so far in using the @ sign in this
manner outside an authority component.  Now to the meat of the matter.
By the grammar introduced in RFC 2396:

3.3. Path Component

   The path component contains data, specific to the authority (or the
   scheme if there is no authority component), identifying the resource
   within the scope of that scheme and authority.

      path          = [ abs_path | opaque_part ]

      path_segments = segment *( "/" segment )
      segment       = *pchar *( ";" param )
      param         = *pchar

      pchar         = unreserved | escaped |
                      ":" | "@" | "&" | "=" | "+" | "$" | ","

Crosschecking this with RFC 2616:

3.2.1 General Syntax

    ...For definitive information on
   URL syntax and semantics, see "Uniform Resource Identifiers (URI):
   Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
   1738 [4] and RFC 1808 [11]). This specification adopts the
   definitions of "URI-reference", "absoluteURI", "relativeURI", "port",

   "host","abs_path", "rel_path", and "authority" from that
   specification.

3.2.2 http URL

   The "http" scheme is used to locate network resources via the HTTP
   protocol. This section defines the scheme-specific syntax and
   semantics for http URLs.

   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

So here's the sticky bit in interpreting this.  An HTTP URI includes an
abs_path...  which resolves to segments, not paths...  however both
ultimately resolve to pchars, for which '@' is an acceptable character.
Here's the ambiguous bit:  tracing from

abs_path -> path_segments -> segment -> pchar, params -> pchar

*it doesn't appear from the grammar defined in 3.2.2 that an authority
component may be included.*  However, 2616 5.1.2 identifies a correctly
formed Request-URI as being:

       Request-URI    = "*" | absoluteURI | abs_path | authority

...which is even more mysterious, as it says you can pass an authority
component *but only as the only component of a Request-URI?*

My conclusion is that, grammatically per RFC 2396 and 2616,

        http://foo.bar.com/users/joe@...

probably *should* and is probably *intended* to be a valid URI, but
strictly speaking it's impossible to determine whether in fact it is or
it isn't.  Comments?  Dangers of using this form of URI?  Etc.?

jb












-----------------------------------------------------------------------------------
Post ID:767
Sender:"Inggs, Andrew" <andrew.inggs@...>
Post Date/Time:2002-02-21 23:24:27
Subject:RE: [rest-discuss] REST applied to provisioning
Message:

> From: Paul Prescod 
> 
> "Inggs, Andrew" wrote:
> > 
> >...
[snip]
> >     http://server/visp/email-alias/xyz/user1/customer.com/me/myself
> 
> If client applications are supposed to care about the
> structure of the URI then you should use query
> parameters. The /s/s/s/s/ part of the URI is supposed to
> be opaque to client software. Only the server knows or
> cares what the slashes mean.
> 
Is that the only consideration?  I just felt that the /s
help to show the hierarchy -- but perhaps that's a bad
thing if that hierarchy were ever to change.

So my URIs become

    http://server/visp/serviceid?...

with (all) possible query parameters:

    v=<vispid>&u=<userid>&d=<domain>&lp=<local-part>&a=<alias>

maybe I should then make the query parameters more natural,
for example, an email address could be identified by

    v=<vispid>&u=<userid>&e=<local-part>@<domain>

> The best way to establish hierarchy is through XML
> documents where the parent has hyperlinks to the
> children and they have hyperlinks to their children
> and so forth. Consider, for example, how easy it becomes
> to write a spider that slurps up the structure and moves
> it. (if you consider that a good thing...otherwise forget
> I said it. ;)
>
Sounds like a good idea, but feels like overkill for my
little application.  Is there a standard for hyperlinking
in XML, or would that potentially be something a formal
REST architecture could define?

If I used query parameters and hyperlinks, would that make
sense, or should I go back to slashes then?  For example:

<visp>
  <user username="user1">
    <website href="/visp/website?v=xyz&u=user1&d=www.customer.com"/>
    <email-domain href="/visp/email-domain?v=xyz&u=user1&d=customer.com"/>
    ...
  </user>
</visp>

or

<visp>
  <user username="user1">
    <website href="/visp/website/xyz/user1/www.customer.com"/>
    <email-domain href="/visp/email-domain/xyz/user1/customer.com"/>
    ...
  </user>
</visp>

> > Now when the XYZ client wants to provision some services for a
> > new user who's signed up, they need to create the services.
> > At the moment, for the above example, this would mean doing
> > the following PUTs with the given data:
> > 
> > PUT /visp/website/xyz/user1/www.customer.com
> > 
> > <?xml version="1.0" encoding="iso-8859-1"?>
> > <!DOCTYPE viml SYSTEM "viml.dtd">
> > <viml>
> >   <website domain="www.customer.com">
> >     <path>/</path>
> >     <password>secret1</password>
> >     <storage-space>15</storage-space>
> >     <bandwidth>50</bandwidth>
> >   </website>
> > </viml>
> 
> I would use a POST for two reasons. First, uses of PUTs to brand new
> URIs that the client creates are not opaque. Second, you don't have to
> duplicate the data, as you noticed.
> 
So I'd change the resource of what's specified in the URI to one
level up.  I would add a user by "appending" to the VISP's list
of users.  To create user1, I might do

POST /visp/users?v=xyz

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE viml SYSTEM "viml.dtd">
<viml>
  <user username="user1/>
</viml>

> PUTs are okay for creating new things when there is a good reason for
> the client to "own" the namespace as in a content management 
> situation. 
> 
Well, in a sense my clients own the namespace, in that they
choose the usernames, domains, etc.  Or am I getting my
terminology wrong now?

> >...
> > Problems I have with my own design:
> > 
> >  - If I were a client I would expect to be able to send a
> >    whole profile and have everything provisioned at once.
> >    This is not insurmountable, just more effort (and some
> >    thinking about transactional guarantees, if any).
> 
> POST can handle that.
> 
I'm not sure how changing to a POST solves this one.  Perhaps
I should break the hierarchy out of the DTD and define everything
at the top level.

> >  - There is redundant data in each request that is already in
> >    the URI.  This means extra processing on both sides, and an
> >    extra check on my side -- and what do I do if there's a
> >    mismatch?
> 
> POST can handle that.
> 
Yes.

> >  - For an update (POST) it's not always clear what can and
> >    can't change.  For example, when updating a website you can
> >    change the password but not the path.  In the case of an alias
> >    you can't even do an update.  I see problems ahead.
> 
> Actually, you should use *PUT* for updates and POST for creating new
> stuff. It's helpful to read the definitions of the major methods here:
> 
> http://www.w3.org/Protocols/rfc2068/rfc2068
> 
Yes, provided you look one level up.  So to change the storage
space for a website one would do a PUT on the storage space
resource, rather than a POST to the website resource, which
would not have made it clear what one was trying to update.

I think this is what I was missing, I was thinking at
the wrong level of identification because I had specific
ideas about how POST and PUT should be used.  I saw
adding a service as requiring a 201 (Created) response,
which I would get from a PUT.

> Anyhow, are your update problems really any different than
> validation problems? Trying to update a password is logically 
> impermissable so you return an error, just like if you tried
> to put an integer where a phone number should go.
> 
Absolutely, and as soon as you identify the password in
the URI, you can easily do that validation.  Actually,
changing a password is allowed, but never mind that :-).

> Hope those ideas help.
> 
Yes, thanks!

Regards,
  Andrew






-----------------------------------------------------------------------------------
Post ID:768
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-02-22 01:09:22
Subject:Re: [rest-discuss] REST made more concrete still
Message:

Hi, Paul.

Great work on the draft. I was working on something similar a few months ago
but lost momentum on it. Here's the thoughts that I had while reading your
proposal.

Can we see a full WRDL document as an example? An XML Schema would be nice,
too.

Will there be a way to bind URIs to resourceTypes in WRDL? Or are you not
going down the route to avoid what WSDL has become? I can definitely see the
benefits to NOT hardcoding a specific WRDL file to one set of URIs.

Is WRDL strictly limited to sending and receving XML documents? I can
understand reducing scope if it is. However, it might be very useful to
allow for form-data inputs. I'd like to be able to do a GET on a resource
that returns an HTML form so that I could do a POST interactively or (using
WRDL) programmatically. Of course, if I was using WRDL, I wouldn't need to
GET the resource for the HTML form.

For uniformity, extra headers, query parameters, and form-data variables (if
supported) should always be allowed.

Should we leverage XML Schema datatypes for the types of inputs? Do types
default to strings if unspecified?

Not all languages support default values for parameters. Do we really need
default and fixed? If it's fixed, why would it be an input? XML has a case
for it but I'm does WRDL?

Will there be a way to define input-sets (like XSLT's attribute-sets)?

<input-set name="my-input-set">
 <query name="my-int-query" type="int" />
 <header name="my-string-header type="string" />
</input-set>

<method name="GET">
 <input use-input-sets="my-input-set" />
</method>

If we allow something like input-sets, maybe instead of a representations
attribute on the input element, there should be a body element (as a child
of input) with a representations attribute just for uniformity.

Will there me any sort of support for modularity? wrdl:include?

You have a creates attributes on a POST method and also a
created/@representations child element but only mention the creates
attribute. Is there supposed to be only one of them?

Is it representation or representationType? You have some representationType
elements with match attributes (instead of test).

Should we be able to specify an XML Schema for a representationType?

I think that you're trying to do too much with simple binding references.
Why not leverage some other specification? I think I would actually prefer
WRDL to stay simple and not specify any binding mechanism at all. Binding to
an XML document should be orthogonal to how you received it. Having said
that, I have a few comments on references as they are written.

If reference/@name is optional, how would you refer to it? Your sample API
looks like the reference name gets converted into a method name. I think it
should be required.

reference/@match should is closer to XSLT's xsl:value-of/@select attribute
than xsl:template/@match. match attributes are restricted to a subset of
XPath that can only evaluate to node sets.

Speaking of node sets, what if your reference's match (or select) attribute
evaluates a node set? Does it return an array? Only if maxOccurs is greater
than 1? These are the types of questions that I believe shouldn't be
answered by WRDL.

Should WRDL support HTTPEvents so that languages that support events can
seamlessly subscribe to them? Or is that too SOAP-ish?

I hope this helps. I'll be glad to work on an implementation as it gets
hammered out.

Jason








-----------------------------------------------------------------------------------
Post ID:769
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-22 10:30:20
Subject:Re: [rest-discuss] REST applied to provisioning
Message:

"Inggs, Andrew" wrote:
> 
>...
> >
> Is that the only consideration?  I just felt that the /s
> help to show the hierarchy -- but perhaps that's a bad
> thing if that hierarchy were ever to change.

Right! That's exactly why the client shouldn't care about the URI
hierarchy.

>...
> maybe I should then make the query parameters more natural,
> for example, an email address could be identified by
> 
>     v=<vispid>&u=<userid>&e=<local-part>@<domain>

I think that's okay but see Jeff Bone's recent post. ;)

>...
> Sounds like a good idea, but feels like overkill for my
> little application.  Is there a standard for hyperlinking
> in XML, or would that potentially be something a formal
> REST architecture could define?

There are two standards (the nice thing about standards...) XLink and
RDF. But they are probably overkill. I would just use an attribute with
an "href". 

> If I used query parameters and hyperlinks, would that make
> sense, or should I go back to slashes then?  For example:
> 
> <visp>
>   <user username="user1">
>     <website href="/visp/website?v=xyz&u=user1&d=www.customer.com"/>
>     <email-domain href="/visp/email-domain?v=xyz&u=user1&d=customer.com"/>
>     ...
>   </user>
> </visp>

It all boils down to whether you expect the client to want to construct
those URIs. If it will always use the XML files for navigation then you
have complete freedom and would probably use the slashes. If the client
is going to want to sometimes do navigation without going through the
XML files then you should use query params.

>...
> So I'd change the resource of what's specified in the URI to one
> level up.  I would add a user by "appending" to the VISP's list
> of users. 

Exactamundo!

> ... To create user1, I might do
> 
> POST /visp/users?v=xyz
> 
> <?xml version="1.0" encoding="iso-8859-1"?>
> <!DOCTYPE viml SYSTEM "viml.dtd">
> <viml>
>   <user username="user1/>
> </viml>

Right!

> > PUTs are okay for creating new things when there is a good reason for
> > the client to "own" the namespace as in a content management
> > situation.
> >
> Well, in a sense my clients own the namespace, in that they
> choose the usernames, domains, etc.  Or am I getting my
> terminology wrong now?

I would say that your clients own their names and those names are
combined by the server into the URI namespace. In a content management
situation it is only the human being doing the publishing who knows why
they put it in /financial instead of /development. 

> > >...
> > > Problems I have with my own design:
> > >
> > >  - If I were a client I would expect to be able to send a
> > >    whole profile and have everything provisioned at once.
> > >    This is not insurmountable, just more effort (and some
> > >    thinking about transactional guarantees, if any).
> >
> > POST can handle that.
> >
> I'm not sure how changing to a POST solves this one.  Perhaps
> I should break the hierarchy out of the DTD and define everything
> at the top level.

Sorry, I meant to say that a POST could actually create more than one
resource. I don't think it violates HTTP semantics to have it do so. We
could probably argue about that though.

This issue of batch data sending has arisen before...there are three
reasons to want it: 1. client convenience, 2. reducing network latency
and 3. atomicity.

>...
> I think this is what I was missing, I was thinking at
> the wrong level of identification because I had specific
> ideas about how POST and PUT should be used.  I saw
> adding a service as requiring a 201 (Created) response,
> which I would get from a PUT.

Note that POST can generate a Created response too. 

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:770
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-22 10:39:02
Subject:Re: [rest-discuss] REST made more concrete still
Message:

Jason Diamond wrote:
> 
> Hi, Paul.
> 
> Great work on the draft. I was working on something similar a few months ago
> but lost momentum on it. Here's the thoughts that I had while reading your
> proposal.

Thanks!

> Can we see a full WRDL document as an example? An XML Schema would be nice,
> too.

Will do. But someday...

> Will there be a way to bind URIs to resourceTypes in WRDL? Or are you not
> going down the route to avoid what WSDL has become? I can definitely see the
> benefits to NOT hardcoding a specific WRDL file to one set of URIs.

Yeah, I don't know if I see the advantage. I do think it might be neat
if there were an HTTP 

> Is WRDL strictly limited to sending and receving XML documents? 

No. It's just that it can only extract hyperlinks from XML. And of
course XHTML....

> ... I can
> understand reducing scope if it is. However, it might be very useful to
> allow for form-data inputs. I'd like to be able to do a GET on a resource
> that returns an HTML form so that I could do a POST interactively or (using
> WRDL) programmatically. Of course, if I was using WRDL, I wouldn't need to
> GET the resource for the HTML form.

Right. So I'm not sure what you are asking for or if you are just
thinking aloud. WRDL is for a client of the service figuring out its
behaviour in advance. HTML form parameters are not necessary because the
service description has the parameters in it.

> For uniformity, extra headers, query parameters, and form-data variables (if
> supported) should always be allowed.

form-data variables are query parameters.

> Should we leverage XML Schema datatypes for the types of inputs? Do types
> default to strings if unspecified?

Yes and yes.

> Not all languages support default values for parameters. 

In some sense they all do. Remember that you will probably be generating
a client library so the generated library can fill in the default
values.

> ... Do we really need
> default and fixed? If it's fixed, why would it be an input? XML has a case
> for it but I'm does WRDL?

I just wanted to be the same as XML Schema. I think the case is about as
strong or weak (both) as XML. You could define a WRDL for a service you
didn't control in order to generate a client library. Maybe you want to
hard-code a parameter. Not a majorly useful feature but not in XML
either...

> Will there be a way to define input-sets (like XSLT's attribute-sets)?

Maybe. Have to see if there is a need for it.

> <input-set name="my-input-set">
>  <query name="my-int-query" type="int" />
>  <header name="my-string-header type="string" />
> </input-set>
> 
> <method name="GET">
>  <input use-input-sets="my-input-set" />
> </method>
> 
> If we allow something like input-sets, maybe instead of a representations
> attribute on the input element, there should be a body element (as a child
> of input) with a representations attribute just for uniformity.

True.

> Will there me any sort of support for modularity? wrdl:include?

Yes, certainly.

> You have a creates attributes on a POST method and also a
> created/@representations child element but only mention the creates
> attribute. Is there supposed to be only one of them?

Yeah...but I don't remember which right now. You pick. ;)

> Is it representation or representationType? You have some representationType
> elements with match attributes (instead of test).

I went back and forth on that one....representationType I guess.

> Should we be able to specify an XML Schema for a representationType?

Maybe you should be able to specify arbitrary extra validation
information.

> I think that you're trying to do too much with simple binding references.
> Why not leverage some other specification? I think I would actually prefer
> WRDL to stay simple and not specify any binding mechanism at all. Binding to
> an XML document should be orthogonal to how you received it. Having said
> that, I have a few comments on references as they are written.

Really the question isn't binding to the XML document but binding to the
*resource*. Subtle but important difference. Note that hyperlinks in
WRDL are from resourceTypes to resourceTypes. A pure XML binding
language would go from XML elements to XML elements.

> If reference/@name is optional, how would you refer to it? Your sample API
> looks like the reference name gets converted into a method name. I think it
> should be required.

Maybe that's just something you couldn't refer to. I could go eithre
way.

> reference/@match should is closer to XSLT's xsl:value-of/@select attribute
> than xsl:template/@match. match attributes are restricted to a subset of
> XPath that can only evaluate to node sets.

Isn't that what I want? I want to get a node set representing a set of
nodes to annotate.

> Speaking of node sets, what if your reference's match (or select) attribute
> evaluates a node set? Does it return an array? Only if maxOccurs is greater
> than 1? 

Yeah, that's actually why I added the concept of maxOccurs.

> ... These are the types of questions that I believe shouldn't be
> answered by WRDL.

But they are. ;)

> Should WRDL support HTTPEvents so that languages that support events can
> seamlessly subscribe to them? Or is that too SOAP-ish?

Yes, WRDL should support subscription to HttpEvents. The client binding
may or may not help you to actually respond to events.

> I hope this helps. I'll be glad to work on an implementation as it gets
> hammered out.

Great!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:771
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-02-22 17:10:48
Subject:Re: [rest-discuss] Using the At Sign in HTTP URI
Message:

On Thu, Feb 21, 2002 at 04:40:56PM -0600, Jeff Bone wrote:
> 
> I need a spec lawyer! ;-) 

I've been called that before. However, I wasn't specified as such. :)


> So here's the sticky bit in interpreting this.  An HTTP URI includes an
> abs_path...  which resolves to segments, not paths...  however both
> ultimately resolve to pchars, for which '@' is an acceptable character.
> Here's the ambiguous bit:  tracing from
> 
> abs_path -> path_segments -> segment -> pchar, params -> pchar

Right. 


> *it doesn't appear from the grammar defined in 3.2.2 that an authority
> component may be included.* 

Whoa; what makes you say that? 3.2.2 constructs the authority in,
with
  host [':' port ]

I'd note that this BNF rule isn't used anywhere in 2616. It also
appears to be specific to protocol use; it doesn't include fragment
identifiers, for example.


> However, 2616 5.1.2 identifies a correctly formed Request-URI as
> being:
> 
>        Request-URI    = "*" | absoluteURI | abs_path | authority
> 
> ...which is even more mysterious, as it says you can pass an authority
> component *but only as the only component of a Request-URI?*

That's a bit weird, but I imagine it's left as a hook for future use
(Apache doesn't seem to support it, for example).


> My conclusion is that, grammatically per RFC 2396 and 2616,
> 
>         http://foo.bar.com/users/joe@...
> 
> probably *should* and is probably *intended* to be a valid URI, but
> strictly speaking it's impossible to determine whether in fact it is or
> it isn't.  Comments?  Dangers of using this form of URI?  Etc.?

I don't understand what your concern above is, but my reading is that
it's allowed, as per RFC2396 Section 3.3.


-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:772
Sender:"Inggs, Andrew" <andrew.inggs@...>
Post Date/Time:2002-02-22 17:24:40
Subject:RE: [rest-discuss] REST applied to provisioning
Message:

Paul Prescod wrote:
> >...
> > maybe I should then make the query parameters more natural,
> > for example, an email address could be identified by
> > 
> >     v=<vispid>&u=<userid>&e=<local-part>@<domain>
> 
> I think that's okay but see Jeff Bone's recent post. ;)
> 
Well query parameters should be escaped, but I think I'll
steer clear of that one :-).

> > [...] Is there a standard for hyperlinking in XML, or
> > would that potentially be something a formal REST
> > architecture could define?
> 
> There are two standards (the nice thing about standards...)
> XLink and RDF. But they are probably overkill. I would just
> use an attribute with an "href". 
> 
I'll have a look at those then, thanks.

> > If I used query parameters and hyperlinks, would that make
> > sense, or should I go back to slashes then?  For example:
[...]
> 
> It all boils down to whether you expect the client to want to 
> construct those URIs. If it will always use the XML files for 
> navigation then you have complete freedom and would probably
> use the slashes.  If the client is going to want to sometimes
> do navigation without going through the XML files then you
> should use query params.
> 
Query parameters it is then.  Is there a verdict about whether
both types are allow, but the client can only use slashes when
following hyperlinks, otherwise query parameters?

> > ... To create user1, I might do
> > 
> > POST /visp/users?v=xyz
> > 
> > <?xml version="1.0" encoding="iso-8859-1"?>
> > <!DOCTYPE viml SYSTEM "viml.dtd">
> > <viml>
> >   <user username="user1/>
> > </viml>
> 
> Right!
> 
Say I create a website at the same time.  In the response,
would it be OK for the domain attribute to be there as well
as the href?

...
   <user username="user1">
     <website domain="www.customer.com"
              href="/visp/website?v=xyz&u=user1&d=www.customer.com"/>
   </user>
...

Perhaps not make it a website element, but a generic link:

...
   <user username="user1">
     <child href="/visp/website?v=xyz&u=user1&d=www.customer.com"/>
   </user>
...

<thinking-out-loud>
Oh no, then I'm going to have to define a separate doctype for
each of my services.  Unless I add a type attribute.
</thinking-out-loud>

> > Well, in a sense my clients own the namespace, in that they
> > choose the usernames, domains, etc.  Or am I getting my
> > terminology wrong now?
> 
> I would say that your clients own their names and those
> names are combined by the server into the URI namespace.
> In a content management situation it is only the human
> being doing the publishing who knows why they put it in
> /financial instead of /development. 
> 
Agreed.  The client owns some of the names, but I (the domain
name owner) am still saying how and where they can be used.

> > > >...
> > > > Problems I have with my own design:
> > > >
> > > >  - If I were a client I would expect to be able to send a
> > > >    whole profile and have everything provisioned at once.
> > > >    This is not insurmountable, just more effort (and some
> > > >    thinking about transactional guarantees, if any).
> > >
> > > POST can handle that.
> > >
> > I'm not sure how changing to a POST solves this one.  Perhaps
> > I should break the hierarchy out of the DTD and define everything
> > at the top level.
> 
> Sorry, I meant to say that a POST could actually create more than one
> resource. I don't think it violates HTTP semantics to have it 
> do so. We could probably argue about that though.
> 
> This issue of batch data sending has arisen before...there are three
> reasons to want it: 1. client convenience, 2. reducing network latency
> and 3. atomicity.
> 
Yes, but 1 and 3 mean more work for me.  But possibly not
as much as I first thought -- if I do the design right.

> >...
> > I think this is what I was missing, I was thinking at
> > the wrong level of identification because I had specific
> > ideas about how POST and PUT should be used.  I saw
> > adding a service as requiring a 201 (Created) response,
> > which I would get from a PUT.
> 
> Note that POST can generate a Created response too. 
> 
Yes, I saw that too late.  I'm now thinking in a sort of
directory and file (or SQL INSERT and UPDATE) analogy and
that's helped me get out of my PUT = create mindset.

Thanks very much for your comments, I very much feel like I'm
getting somewhere!

Regards,
  Andrew






-----------------------------------------------------------------------------------
Post ID:773
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-22 17:41:32
Subject:Re: [rest-discuss] Using the At Sign in HTTP URI
Message:


Mark Nottingham wrote:

> > *it doesn't appear from the grammar defined in 3.2.2 that an authority
> > component may be included.*
>
> Whoa; what makes you say that? 3.2.2 constructs the authority in,
> with
>   host [':' port ]
>
> I'd note that this BNF rule isn't used anywhere in 2616.

Sorry, I was a bit ambiguous...  the latter is what I meant.  This rule isn't
used and AFAICT there's no way to get to it from the rules that are directly
used in 2616, -wrt- path segments.

> That's a bit weird, but I imagine it's left as a hook for future use
> (Apache doesn't seem to support it, for example).

I think it's a bit underspecified.

> I don't understand what your concern above is, but my reading is that
> it's allowed, as per RFC2396 Section 3.3.

My concern is just that, strictly from the spec, it's difficult to tell
whether '@' is kosher in path segments.  AFAICT it is, but the way the
grammars interact between the two RFCs makes it difficult to give an
authoritative answer;  some regexp-based URI parsers I've seen get this
wrong.

Thanks for the comments, very helpful!

jb








-----------------------------------------------------------------------------------
Post ID:774
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-22 17:47:32
Subject:Re: [rest-discuss] REST made more concrete still
Message:

On that 'xml representation of http'...
If you convert an http request (blob of text+stuff) into a collection of
nodes that are addressable (ala groves) you can then point to different
parts - which helps identify where data comes from and where data
(parameters) go to.
Having headers and body accessible this way allows for a single mechanism to
do that addressing - you use xpath (or some other node addressing syntax) to
point to a header just like pointing to the uri or method or status or body
or whatever.
Downloading a description of how to construct a request sounds like what
wrdl is about - which to me is 'discovery' and really the only piece the
soap approach has over the pure http approach (assuming doing http+xml). I
don't know why http doesn't have this discovery piece - I hope wrdl becomes
workable and popular.

If a request or response blob is node addressable you can write simple maps
the extract interesting properties. If the content is xml, you can extract
them from the body as well. So on the server side, you can say 'username
comes from (in xpath syntax) /request/header/authentication/user or
/request/query/userid or wherever. This causes the set of names you want to
extract (like 'username' or 'resource') to become the interface for
interoperation and these little maps become mini-adapters. It'll only go so
far in capability, but will help cover many situations. You'll also get into
arguments about how fine grained to make the request and response.

So what I'm thinking is downloading a 'template' of an HTTP request, with
portions filled in (like the URL, etc.), and a separate 'interface def'
provides names and pointers within that template. The 'interface def' could
have 'username' (a mutually agreed upon set of names - probably from http
concepts itself) and point to where that particular service expects the
value to show up - sometimes people use HTTP auth, sometimes they use query
terms, sometimes they use URIs, etc.


Mike "on vacation sitting by the pool working through the glare" Dierken

----- Original Message -----
From: Paul Prescod <paul@...>
To: S. Mike Dierken <mdierken@...>
Sent: Tuesday, February 19, 2002 9:25 PM
Subject: Re: [rest-discuss] REST made more concrete still


> "S. Mike Dierken" wrote:
> >
> > Interesting...
> > I've always wanted an xml representation of HTTP requests and
responses...
> > I'd avoid inheritence-through-containment (instance inheritence)
initially -
>
> Don't follow.
>
> > I love the idea, but mutually exclusive options can pop up later.
>
> Don't follow.
>
> > --suggestion--
> > <purchaseOrder >
> > <request method='GET'>
> >  <input name='itemtypes' type='integer' target='query' />
> > </request>
> > <request method='POST' accepts="x-www-form-url-encoded"
returns="ebxmlpo">
> >  <input name='name' target='query' />
> >  <input name='items' type='integer' target='query' />
> > </request>
> > <request method='PUT' accepts='ebxmlpo cblpo'>
> > </request>
> > </purchaseOrder>
>
> I sort of understand this but don't understand any of your motivations.
> For instance are you trying to make an XML equivalent to an HTML form?
> That's quite different than what I'm after. In that the form is served
> up at runtime but this thing is more about declaring things in advance
> like a schema.
>
>  Paul Prescod
>






-----------------------------------------------------------------------------------
Post ID:775
Sender:Allan Doyle <adoyle@...>
Post Date/Time:2002-02-22 18:19:30
Subject:[xml-dev] New XPipe Presentation available
Message:

On Thursday 2002-02-21 at 08:40:51(+0000) Sean McGrath wrote:
 > I recently gave a talk about the XPipe appoach to XML processing
 > at the XML SIG of New York.
 > 
 > The slides from the talk are available on http://xpipe.sourceforge.net at
 > http://xpipe.sourceforge.net/BinaryStuff/xpipeny.ppt
 > 

Good stuff, thanks for sharing...

It strikes me that XPipe and REST are meant for each other.
Machine-to-machine REST is really about transformations on XML
documents.

	Allan

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle                         http://www.intl-interfaces.com
adoyle@...

                                                   







-----------------------------------------------------------------------------------
Post ID:776
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-23 20:57:36
Subject:Meerkat API in WRDL
Message:

New (rough!) WRDL DTD. I'm just using a DTD because it is convenient.
Eventually I will also provide schemas in various schema syntaxes once
everything is firmed up.

http://www.prescod.net/rest/wrdl.dtd

Description of some of Meerkat's inputs in WRDL:

http://www.prescod.net/rest/meerkat.wrdl

WRDL spec with a few bug fixes and the link to the DTD and schema:

http://www.prescod.net/rest/wrdl.html

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:777
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-02-24 00:07:25
Subject:Re: [rest-discuss] Meerkat API in WRDL
Message:

Very cool, Paul!

Does extension-method really need the "extension-" prefix? A simple "method"
name seems like it would convey the exact same information. Is HEAD an
extension method? It's defined in HTTP so I wouldn't think to call it that.

Do query elements always represent the parts of the URI after the question
mark? Even for POST? If so, that's why I was asking (in a previous message)
if there could be separate input elements (form? variable?) for form
variables that can be POSTed (using multipart/form-data) to a resource.

How is it possible to have query outputs? Or is that a typo in the DTD?

The content model for documentation and appinfo should be ANY so that we
could include structured content. Personally, though, I would prefer if
annotation's content model was ANY and there were no documentation or
appinfo elements. The distinction that XML Schema makes between human and
machine readable annotations seems entirely arbitrary to me. XML makes
content both human and machine readable at the same time!

It seems odd that representationType elements are contained by a
resourceTypes element.

You have some example representationType elements with match attributes. The
DTD says those should be called test.

I still think that the match attribute on reference elements should be
select. XSLT's match attribute defines a pattern that (usually) gets checked
as the processor recurses down the entire document. You could just as easily
extract the same information, albeit more efficiently, if you used normal
XPath expressions.

<representationType name="xslt" media-type="text/xsl"
        match="/*[@xsl:version or @version]">
    <reference name="includes" match="*/xsl:include/@href"
type="xsltResource"/>
    <reference match="*/xsl:import/@href" type="xsltResource"/>
</representationType>

(The * is there because XSLT document elements can be either xsl:stylesheet
or xsl:transform.)

If you still want to scan the entire document you could always use an XPath
like "//foo".

A more realistic example for different representation types might be for the
different types of schemas that are out there:

<representationType name="xsd" media-type="application/xml"
test="xsd:schema">
 <!-- ... -->
</representationType>
<representationType name="rng" media-type="application/xml" test="rng:*">
 <!-- ... -->
</representationType>
<representationType name="sch" media-type="application/xml"
test="sch:schema">
 <!-- ... -->
</representationType>

You say that WRDL doesn't care which representationType matches a
representation. Won't consumers of a WRDL-generated API want to know what
type of document was returned? Won't the WRDL-generated proxy want to know
so that it could validate the representation? It seems like things would be
easier all around if the first representationType that passed its XPath test
was the "winner".

Could you expound a little more on "the built-in support for navigation
through hyperlinks"? I don't follow that. How is that used in the API?

Thanks,
Jason

----- Original Message -----
From: Paul Prescod
To: rest-discuss@yahoogroups.com ; rael@...
Sent: Saturday, February 23, 2002 12:57 PM
Subject: [rest-discuss] Meerkat API in WRDL


New (rough!) WRDL DTD. I'm just using a DTD because it is convenient.
Eventually I will also provide schemas in various schema syntaxes once
everything is firmed up.

http://www.prescod.net/rest/wrdl.dtd

Description of some of Meerkat's inputs in WRDL:

http://www.prescod.net/rest/meerkat.wrdl

WRDL spec with a few bug fixes and the link to the DTD and schema:

http://www.prescod.net/rest/wrdl.html

Paul Prescod

Yahoo! Groups Sponsor
ADVERTISEMENT




To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.







-----------------------------------------------------------------------------------
Post ID:778
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-24 01:29:34
Subject:Re: [rest-discuss] Meerkat API in WRDL
Message:

Jason Diamond wrote:
> 
> Very cool, Paul!
> 
> Does extension-method really need the "extension-" prefix? A simple "method"
> name seems like it would convey the exact same information. Is HEAD an
> extension method? It's defined in HTTP so I wouldn't think to call it that.

Yeah, I haven't decided exactly what to do there. I don't want to
confuse the DTD with the HTTP methods that don't have logical
significance for a "web service." How about "other-method"? As this
should be rarely used I don't think that the verbosity is a problem.

> Do query elements always represent the parts of the URI after the question
> mark? 

Yes. I think so.

> ... Even for POST? If so, that's why I was asking (in a previous message)
> if there could be separate input elements (form? variable?) for form
> variables that can be POSTed (using multipart/form-data) to a resource.

I see. On the one hand it seems like once I get into helping people to
define the structure of the body I'm getting into a slippery slope. Next
I'll be embedding schemas in WRDL. On the other hand I can see how it
would be useful. I guess I'll add that. Should I call it
<form-parameter>?

> How is it possible to have query outputs? Or is that a typo in the DTD?

Typo.

> The content model for documentation and appinfo should be ANY so that we
> could include structured content. Personally, though, I would prefer if
> annotation's content model was ANY and there were no documentation or
> appinfo elements. The distinction that XML Schema makes between human and
> machine readable annotations seems entirely arbitrary to me. XML makes
> content both human and machine readable at the same time!

I'll think more about it. There is virtue in conforming to patterns set
elsewhere...but I find it somewhat verbose myself.

> It seems odd that representationType elements are contained by a
> resourceTypes element.

I guess I could call the top-level element "stuff". Or "wrdl". My
thinking is that the goal is defining resource types and the
representations are just a sort of property of the resources, like ports
in WSDL.  They aren't defined in the resources directly so they can be
used in multiple places.

> You have some example representationType elements with match attributes. The
> DTD says those should be called test.

True. Will fix.

> I still think that the match attribute on reference elements should be
> select. 

I see, you're thinking of the representationType as a template and using
that as the "current node". I'm more thinking that we visit every node
in the document and see if it matches any of the XPaths in any of the
references. I presume that you usually will NOT care about proximity to
the root so it should default to floating.

> ... XSLT's match attribute defines a pattern that (usually) gets checked
> as the processor recurses down the entire document. You could just as easily
> extract the same information, albeit more efficiently, if you used normal
> XPath expressions.

I think the efficiency is the same because any smart processor could
convert one form to the other.

>...
> If you still want to scan the entire document you could always use an XPath
> like "//foo".

I just feel like that will be the most common case so it should be the
default. If you have any other arguments for select I'm open to them,
though. I don't feel strongly about it.

> A more realistic example for different representation types might be for the
> different types of schemas that are out there:

Good idea.

> You say that WRDL doesn't care which representationType matches a
> representation. Won't consumers of a WRDL-generated API want to know what
> type of document was returned? 

That's why I wrote that bit about "This may change in the future.". I
need to think about it more. What if a representation matches two
representationTypes. Do I have to signal an error? Choose the first? Add
priority attributes?

> ... Won't the WRDL-generated proxy want to know
> so that it could validate the representation? It seems like things would be
> easier all around if the first representationType that passed its XPath test
> was the "winner".

Maybe that's simplest. XSLT throws an error. I'll have to think about it
more.

> Could you expound a little more on "the built-in support for navigation
> through hyperlinks"? I don't follow that. How is that used in the API?

"CustomerResource cust = por.references.customer()"

What's happened there is that there was some XML that looked like
<purchaseOrder>
  <customerURI href="http://...."/> or something like that.
...
</purchaseOrder>

Then there was a reference with the name "customer" that matched
//customerURI/@href. And the referent was declared to be of type
CustomerResource. So you navigated from the purchase order to the
customer. And then you get a representation of the customer like this:

DOMDocument cust = por.GET()

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:779
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-24 01:32:39
Subject:Re: [rest-discuss] Meerkat API in WRDL
Message:

Jason Diamond wrote:
> 
>...
> 
> It seems odd that representationType elements are contained by a
> resourceTypes element.

How about just "types".

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:780
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-02-24 02:18:03
Subject:Re: [rest-discuss] Meerkat API in WRDL
Message:

Hi.

> I see. On the one hand it seems like once I get into helping people to
> define the structure of the body I'm getting into a slippery slope. Next
> I'll be embedding schemas in WRDL. On the other hand I can see how it
> would be useful. I guess I'll add that. Should I call it
> <form-parameter>?

Don't add it for me. I was only asking out of curiosity. If you restrict the
scope of WRDL to XML-based representations (which multi-part/form-data is
not) then I think it will be a much simpler and manageable spec.

> > ... XSLT's match attribute defines a pattern that (usually) gets checked
> > as the processor recurses down the entire document. You could just as
easily
> > extract the same information, albeit more efficiently, if you used
normal
> > XPath expressions.
>
> I think the efficiency is the same because any smart processor could
> convert one form to the other.

The processor would have to have detailed knowledge of the representation
type. How would it know to only look at the children of the document element
for xsl:include elements (that's the only place they can appear)?

Hmm. Now that I think about it, patterns like /*/xsl:include could easily be
optimized. I'm with you now.

> >...
> > If you still want to scan the entire document you could always use an
XPath
> > like "//foo".
>
> I just feel like that will be the most common case so it should be the
> default. If you have any other arguments for select I'm open to them,
> though. I don't feel strongly about it.

I take back what I said. I was trying to optimize prematurely. Using match
is somewhat akin to XSLT's keys.

Hmm. Now that I've said that, I think I really like it. In XSLT, you specify
what pattern you should look for (with a match attribute) and what value
(relative to each node that matched the pattern) is the "key" or name for
that node (with a use attribute).

By following that example, WRDL can have named sets of references where the
names are stored in the representations so they don't have to be hardcoded
in the WRDL file!

> > ... Won't the WRDL-generated proxy want to know
> > so that it could validate the representation? It seems like things would
be
> > easier all around if the first representationType that passed its XPath
test
> > was the "winner".
>
> Maybe that's simplest. XSLT throws an error. I'll have to think about it
> more.

Are you talking about what XSLT does when matching templates? The spec says
that a processor can throw an error when multiple templates match a pattern
with the same priority _or_ it can choose the last template that appears in
the stylesheet.

I think it'd be simplest to treat testing for multiple representation types
like a xsl:choose/xsl:when. The first test that results in true gets
evaluated.

> > Could you expound a little more on "the built-in support for navigation
> > through hyperlinks"? I don't follow that. How is that used in the API?
>
> "CustomerResource cust = por.references.customer()"
>
> What's happened there is that there was some XML that looked like
> <purchaseOrder>
>   <customerURI href="http://...."/> or something like that.
> ...
> </purchaseOrder>
>
> Then there was a reference with the name "customer" that matched
> //customerURI/@href. And the referent was declared to be of type
> CustomerResource. So you navigated from the purchase order to the
> customer. And then you get a representation of the customer like this:
>
> DOMDocument cust = por.GET()

So references are always URIs? Now I get it!

> > It seems odd that representationType elements are contained by a
> > resourceTypes element.
>
> How about just "types".

I like it. And if you decide to put your elements in a namespace then it
could be wrdl:types.

Thanks,
Jason








-----------------------------------------------------------------------------------
Post ID:781
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-02-24 12:52:38
Subject:Fw: WRDL
Message:

Is it appropriate to send attachments to the list? If anybody's interested
in seeing the code, just let me know.

----- Original Message -----
From: "Paul Prescod" <paul@...>
To: "Jason Diamond" <jason@...>
Sent: Sunday, February 24, 2002 4:22 AM
Subject: Re: WRDL


> I'll respond now and then we can forward the messages to the mailing
> list if we decide to.
>
> Jason Diamond wrote:
> >
> > Hi, Paul.
> >
> > I'm sick so am stuck at home and thought I would take advantage of it
and do
> > some experimentation. I don't really start to understand something until
I
> > use it. And REST/WRDL is hard enough without something concrete for me
to
> > play with as it is. :-)
> >
> > I've hacked together some XSLT/C# to generate a proxy class from your
> > meerkat.wrdl file. It doesn't do much yet but that will change.
>
> Great stuff! I don't suppose you'll buy my suggestion that you should
> "regress" to Java for portability and popularity reasons. ;) Either way,
> I'm very happy because I would want to see C# support eventually anyhow.
>
> > I don't know if you have the .NET Framework installed (or even if you
run
> > Windows) but if you do, you should be able to type nmake in the
directory
> > containing my attached files and it will generate the proxy
(meerkat.cs),
> > build a test executable that fetches the Eclectic XML posts for the past
> > seven days, and then saves it to a file called response.xml. All the
> > generated files are included just in case you can't build them.
>
> Seems logical to me. One virtue of the .NET framework is that it has
> XPath built in. XPath would have to be an extra dependency in Java. But
> you haven't gotten to the references bit yet...
>
> > >From an RPC point-of-view, I don't think that meerkat makes a really
usable
> > API. There's too many (mutually exclusive) parameters for the same
endpoint.
> > I suspect that it doesn't make a good REST service, either. Shouldn't
each
> > channel, mob, and profile have its own URI?
>
> Yes. At this point I'm just happy that there is any openly available
> XML/URI/HTTP-based service, whether ot not it is well designed from a
> REST point of view. Google had an XML service for a while but it's gone.
>
> One could also imagine talking to HTML, as it is possible to make a DOM
> from HTML and in most toolkits it should be possible to search it with
> an XPath. The tricky bit of course is distinguishing one href from
> another. It looks to extract referenced links in Google it is relatively
> safe to use this pattern:
>
> "<p><a href="
>
> which would be an XPath like "the first node children of paragraphs
> where the node is an 'a'" (as opposed to the first "a" children of
> paragraphs). Some of Google's other href's have class attributes.
> And of course the cache link always has the text "Cached".
>
> It would be really great to have a read-write web service but there are
> reasons that people don't tend to open up read-write access to websites.
> ;) I've been toying with the idea of a UDDI bridge.
>
> Looking at your home page you might consider REST services for POP3 or
> DNS. Those would be really cool. POP3 especially, because there are many
> people with a reverence for the mail system so over a few years I'd like
> to recreate much of its infrastructure based on HTTP, not because I
> really think HTTP will compete with SMTP/IMAP/POP commercially
> (installed base is too large) but to show people who are building apps
> that are "mail-like" that they can use HTTP.
>
> > By the way, the correct query name for the "flavor" parameter is "_fl".
And
> > shouldn't the value of that parameter be fixed to "xml" somehow so that
we
> > can always do XPath on the response?
>
> Good point. And yes.
>
> > Take a look at meerkat.cs. That's the file that was generated. The first
> > thing that jumps out at me is that the query parameter names are
extremely
> > terse. Would an optional parameter to specify a more programmer-friendly
> > name be appropriate?
>
> I considered that and then thought: "maybe we should just push this back
> on service developers to make nicer URI parameter names." After all, _fl
> isn't very friendly even in your browser bar. Still, your next point is
> very important:
>
> > ... It might be more important for header inputs since
> > those tend to have dashes in them and most programming languages don't
> > support those in identifiers.
>
> Agreed.
>
> "friendly-name"? "api-name"? If api-names were required to be unique
> across queries and headers then we could unify the queries and header
> namespaces for languages where parameters matter (e.g. those with
> optional arguments).
>
> Don't forget to provide an API for extra query and header parameters.
>
> > Do you have any ideas on how optional parameters could be handled for
> > languages that don't support them (like C#)? I hacked in some checks for
> > null and 0 but don't like that because with that we can never pass in
null
> > or 0 to a resource that allows those values.
>
> Yeah, 0 is a problem.
>
> > ... I can think of three other ways
> > to get around this but they all involve a lot of work:
> >
> > - Add a boolean parameter for each optional parameter to the method
> > signature. If false, the optional parameter is ignored.
> >
> > - Generate lots of overloads. (This doesn't seem usable, though.)
> >
> > - Generate some sort of "parameters" class. Like MeerkatGetInputs,
perhaps.
> > It could have getters, setters, and clearers for each parameter. It
would
> > keep track of which parameters were never set internally. An instance of
> > that class would be passed into the method instead of all the parameters
> > individually.
> >
> > These are all just implementation details and don't really affect WRDL
but
> > it's something to think about.
>
> The parameters class is not unlike the sort of message you have to build
> to use .NET My services. As web services move more and more to
> "messaging" style it will be pretty common. MeerkatPOSTInputs could also
> hold the DOM for any XML inputs to POST or PUT. i.e. one property per
> parameter/header and one for the bound XML document.
>
> <aside>There is a fundamental disconnect between languages that only
> support ordered-parameter arguments and good networking "best practice"
> where extensibility is paramount. RPC is bad enough architecturally
> without making it even worse by making parameter orders significant as
> SOAP and (especially!) XML-RPC services tend to. I don't really
> understand why in this day and age, optional and named parameters are
> considered a fancy language feature. IIRC, Ada had them in the
> 80s.</aside>
>
> > I'm not doing anything with representations yet. I'm just returning a
> > generic WebResponse. But I want to be able to extract the links from the
> > response. In your meerkat.wrdl file, you have two references with the
same
> > names and patterns. Is that a mistake? And should they not have the
leading
> > slash?
>
> Right. Meerkat has a link and a url. I have a typo in the meerkate.wrdl.
>
> DTD is here:
>
>  * http://www.oreillynet.com/meerkat/dtd/meerkat_xml_flavour.dtd
>
> You might as well send me Meerkat.wsdl when you've observed it to work.
> ;)
>
> > This is what I suspect the reference for story links should look like:
> >
> > <reference name="story" match="story/link" resourceType="ANY" />
> >
> > The problem is that there are multiple stories and, hence, multiple
links.
> > So I can return a collection of resources. But what if I wanted to
extract a
> > specific one? This is where I think my XSLT key analogy would be
perfect.
> >
> > <reference name="story" match="story/link"
use="preceding-sibling::title"
> > resourceType="ANY" />
>
> Now I get it. Excellent idea! You could even index the same URI by
> multiple keys. It's a little bit more complicated than what I was
> thinking but much more useful.
>
> BTW, I'd spell that "../title" The abbreviated form is a little bit more
> readable and it's a little bit less dependent on ordering (in case the
> DTD ever changes).
>
> >...
> > Regarding representations: Generating code like your sample API might be
> > difficult for type-safe languages. If multiple representationTypes can
be
> > returned from a method then we might be forced to have those methods
return
> > something like System.Object (C#) or java.lang.Object and have the
> > programmers cast down to whatever they think the correct representation
is.
> > I hate that.
>
> I think your idea of specifying the representation type to get in the
> method name is a good one. It's just a way of triggering the content
> negotiation in a static-type-safe way.
>
> > Why exactly would you want to allow methods to return different types of
> > representations anyways? The programmer probably knows exactly what type
he
> > wants, wouldn't you think?
>
> Which programmer are you talking about? The web service provider might
> allow fetching data in RSS 0.9 versus RSS 1.0 versus XMLNews. Or they
> might have a a biztalk PO versus an ebxml versus rosettanet. It is
> probably useful for the semantic web not to give them all unique URIs
> otherwise you need to somehow broadcast that they are "really" the same
> thing (which you can do with RDF but still...).
>
> > ... I suppose that we could generate a separate
> > method for each representation type that was possible. So the meerkat
proxy
> > might have GetXML, GetRSS, etc. We would just combine the method name
with
> > the representationType name.
>
> Yes, I like that idea.
>
> > OK, I think I've babbled for long enough. I hope you find these comments
> > helpful.
>
> Very helpful! I appreciate all of your effort. The fact that our
> instincts line up so well reinforces my believe that WRDL is pretty
> logical -- it's like we're discovering it instead of creating it.
> Basically it is just a concrete syntax for statically type declaring
> bits of the existing web architecture.
>
>  Paul Prescod
>







-----------------------------------------------------------------------------------
Post ID:782
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-24 12:53:32
Subject:Re: [rest-discuss] Meerkat API in WRDL
Message:

Jason Diamond wrote:
> 
>...
> 
> Don't add it for me. I was only asking out of curiosity. If you restrict the
> scope of WRDL to XML-based representations (which multi-part/form-data is
> not) then I think it will be a much simpler and manageable spec.

Well there are only two "standardized" representations (other than
HTML), XML and form parameters so I think it may make sense to support
them both directly. I am thinking about a simple templating feature for
XML:

<foo bar="{height}">
  <width>{width}</width>
</foo>

It probably doesn't make much sense to go beyond that. 

>...
> Hmm. Now that I've said that, I think I really like it. In XSLT, you specify
> what pattern you should look for (with a match attribute) and what value
> (relative to each node that matched the pattern) is the "key" or name for
> that node (with a use attribute).
> 
> By following that example, WRDL can have named sets of references where the
> names are stored in the representations so they don't have to be hardcoded
> in the WRDL file!

I didn't understand this the first time I read it, but I do now. You
want to allow the WRDL file to set up hashtables for the programmer
where the keys are generated from the XML (e.g. "title" elements for
Meerkat topics) and the values are references to resource objects. Good
idea!

I think I will also rename it to reference-type, because really we're
classifying references. Make sense to you?

<!ELEMENT reference-type (documentation?, appinfo?)>

<!ATTLIST reference-type name %Name; #REQUIRED 
                    match %XPath; #REQUIRED
                    use %XPath; #REQUIRED
                    resourceType %QName; #REQUIRED>

>...
> Are you talking about what XSLT does when matching templates? The spec says
> that a processor can throw an error when multiple templates match a pattern
> with the same priority _or_ it can choose the last template that appears in
> the stylesheet.
> 
> I think it'd be simplest to treat testing for multiple representation types
> like a xsl:choose/xsl:when. The first test that results in true gets
> evaluated.

In our other (offlist) discussion we agreed that the client should
explicitly ask for a representation. So I don't think we have to answer
this question. The test is almost superfluous...sanity checking at best,
cruft at worst. Originally the model was you'd get something back and
figure out what it was. But it's better to say what you want and be
confident you're going to get it. 

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:783
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-24 13:02:57
Subject:Re: [rest-discuss] Fw: WRDL
Message:

Jason Diamond wrote:
> 
> Is it appropriate to send attachments to the list? 

Probably not.

> ... If anybody's interested in seeing the code, just let me know.

I think these bits are especially interesting. First there is a test
file. Second is a generated proxy. Obviously still only
preliminary...Jason hasn't done the references feature yet which is a
big one. And we've discussed pretty big API changes. Still cool to see
something runnable coming together.

Test file:

using System;
using System.IO;
using System.Net;

public class Test
{
	static void Main()
	{
		meerkat m = new meerkat("http://meerkat.oreillynet.com/");

		WebResponse webResponse = m.GET(
			"xml", // flavor
			null, // search for
			null, // search what
			555, // channel
			"7DAY", // time period
			0, // profile
			0, // mob
			0 // id
		);

		WriteResponse(webResponse, Console.Out);
	}
}

API generated from (a bug-fixed version of) meerkat.wrdl with Jason's
XSLT:

using System;
using System.Net;

public class meerkat : WrdlResource
{
	public meerkat(string uri) : base(uri)
	{
	}

	public WebResponse GET(
		string _fl,
		string s,
		string sw,
		int c,
		string t,
		int p,
		int m,
		int i)
	{
		if (_fl != null) AddQuery("_fl", _fl);
		if (s != null) AddQuery("s", s);
		if (sw != null) AddQuery("sw", sw);
		if (c != 0) AddQuery("c", c);
		if (t != null) AddQuery("t", t);
		if (p != 0) AddQuery("p", p);
		if (m != 0) AddQuery("m", m);
		if (i != 0) AddQuery("i", i);

		Console.Error.WriteLine(Uri);

		WebRequest webRequest = WebRequest.Create(Uri);
		WebResponse webResponse = webRequest.GetResponse();

		return webResponse;
	}
}

public class WebPage : WrdlResource
{
	public WebPage(string uri) : base(uri)
	{
	}
}






-----------------------------------------------------------------------------------
Post ID:784
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-02-24 13:30:17
Subject:Re: [rest-discuss] Fw: WRDL
Message:

> > Great stuff! I don't suppose you'll buy my suggestion that you should
> > "regress" to Java for portability and popularity reasons. ;) Either way,
> > I'm very happy because I would want to see C# support eventually anyhow.

If nobody steps up to do a Java version than I coud take a crack at that,
too. I only chose C# since it comes with XPath support out of the box. I
need an excuse to learn Jaxen, anyways.

> > It would be really great to have a read-write web service but there are
> > reasons that people don't tend to open up read-write access to websites.
> > ;) I've been toying with the idea of a UDDI bridge.

I'm working on one and will probably need help from the list to make sure I
get it right. Think Radio meets REST. :-)

> > I considered that and then thought: "maybe we should just push this back
> > on service developers to make nicer URI parameter names." After all, _fl
> > isn't very friendly even in your browser bar. Still, your next point is
> > very important:
> >
> > > ... It might be more important for header inputs since
> > > those tend to have dashes in them and most programming languages don't
> > > support those in identifiers.
> >
> > Agreed.
> >
> > "friendly-name"? "api-name"? If api-names were required to be unique
> > across queries and headers then we could unify the queries and header
> > namespaces for languages where parameters matter (e.g. those with
> > optional arguments).

I don't know. I could go either way on this. It seems like an implementation
detail that the spec shouldn't care about. Proxy generators could
automatically transform names so that they're legal. Or developers could
sneak in some qualified attributes on those elements with the names they
prefer. Or they could support some sort of configuration that lets you
rename inputs without modifying the WRDL.

> > Don't forget to provide an API for extra query and header parameters.

Good point. This is a good argument for the "Inputs" class we talk about
below.

> > The parameters class is not unlike the sort of message you have to build
> > to use .NET My services. As web services move more and more to
> > "messaging" style it will be pretty common. MeerkatPOSTInputs could also
> > hold the DOM for any XML inputs to POST or PUT. i.e. one property per
> > parameter/header and one for the bound XML document.
> >
> > <aside>There is a fundamental disconnect between languages that only
> > support ordered-parameter arguments and good networking "best practice"
> > where extensibility is paramount. RPC is bad enough architecturally
> > without making it even worse by making parameter orders significant as
> > SOAP and (especially!) XML-RPC services tend to. I don't really
> > understand why in this day and age, optional and named parameters are
> > considered a fancy language feature. IIRC, Ada had them in the
> > 80s.</aside>

Well, VB has them but you're not going to make me code in that, are you? ;-)

It seems that the "Inputs" class is the best and most flexible approach. Not
only does it support optional parameters which you can set in any order but
you could also add arbitrary queries or headers.

> > > <reference name="story" match="story/link"
> use="preceding-sibling::title"
> > > resourceType="ANY" />
> >
> > Now I get it. Excellent idea! You could even index the same URI by
> > multiple keys. It's a little bit more complicated than what I was
> > thinking but much more useful.

It does seem a tiny bit more complicated but I think a lot of flexibility is
gained from it. With the match attribute, we'll probably have to process the
entire tree anyways. The value grabbed using the use attribute just makes it
easier for us to actually use that data once it's extracted.

> > BTW, I'd spell that "../title" The abbreviated form is a little bit more
> > readable and it's a little bit less dependent on ordering (in case the
> > DTD ever changes).

Good point.

> > > Why exactly would you want to allow methods to return different types
of
> > > representations anyways? The programmer probably knows exactly what
type
> he
> > > wants, wouldn't you think?
> >
> > Which programmer are you talking about? The web service provider might
> > allow fetching data in RSS 0.9 versus RSS 1.0 versus XMLNews. Or they
> > might have a a biztalk PO versus an ebxml versus rosettanet. It is
> > probably useful for the semantic web not to give them all unique URIs
> > otherwise you need to somehow broadcast that they are "really" the same
> > thing (which you can do with RDF but still...).

OK, I see what you're saying. These examples would surely be restricted to
one representationType per representation, no? Would there be any cases
where a single representation could match more than one?

> > Very helpful! I appreciate all of your effort. The fact that our
> > instincts line up so well reinforces my believe that WRDL is pretty
> > logical -- it's like we're discovering it instead of creating it.
> > Basically it is just a concrete syntax for statically type declaring
> > bits of the existing web architecture.

I was throwing around some ideas privately with Mark Baker a few months ago
and some of them were very similar to yours. I was calling it HTTP-IDL
(which I realize now is way to RPC-ish) but it was nowhere near as elegant
as WRDL.

Jason








-----------------------------------------------------------------------------------
Post ID:785
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-02-24 13:47:31
Subject:Re: [rest-discuss] Meerkat API in WRDL
Message:

> Well there are only two "standardized" representations (other than
> HTML), XML and form parameters so I think it may make sense to support
> them both directly. I am thinking about a simple templating feature for
> XML:
>
> <foo bar="{height}">
>   <width>{width}</width>
> </foo>
>
> It probably doesn't make much sense to go beyond that.

This almost looks like XForms. They have an element that lets you specify
model instance data where elements get replaced with the actual form values
when the form gets submitted.

Would these be different kinds of inputs? You can certainly still have query
and header inputs. Maybe you don't need the {variables} in your template if
you put XPath expressions on the elements (variable? parameter?) that
specify these.

Would you be able to specify an output template as well?

I think this is really cool but I'm not sure if it's really necessary for
WRDL. At least for an initial release. By the way, do you have a list of
goals or requirements for the first release of WRDL? We certainly don't want
to succumb to feature creep or we might have to change the R to an S. ;-)

> I think I will also rename it to reference-type, because really we're
> classifying references. Make sense to you?

Sounds good. Are you switching to lisp-style identifiers instead of
camelCase? I don't care which one you use but they should probably be
consistent.

> <!ELEMENT reference-type (documentation?, appinfo?)>
>
> <!ATTLIST reference-type name %Name; #REQUIRED
>                     match %XPath; #REQUIRED
>                     use %XPath; #REQUIRED
>                     resourceType %QName; #REQUIRED>

Maybe the use attribute should be optional. I can imagine some resources
containing a list of references with no obvious key. And perhaps some
applications won't care about the keys.

Will the spec specify any sort of rules for compliant APIs? The question I
have now is this: should the collection of references maintain the same
order they were found in even if keyed? If so, we'd have to use a fancier
data structure than a Hashtable or Map since those usually destroy the
ordering. I would tend to think that the answer to this would be use but I
don't have any particular use cases to justify it.

Jason








-----------------------------------------------------------------------------------
Post ID:786
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-24 23:24:19
Subject:Re: [rest-discuss] Meerkat API in WRDL
Message:

This message is dedicated to the Canadian hockey teams. ;)

Jason Diamond wrote:
> 
> > Well there are only two "standardized" representations (other than
> > HTML), XML and form parameters so I think it may make sense to support
> > them both directly. I am thinking about a simple templating feature for
> > XML:
> >
> > <foo bar="{height}">
> >   <width>{width}</width>
> > </foo>
> >
> > It probably doesn't make much sense to go beyond that.
> 
> This almost looks like XForms. They have an element that lets you specify
> model instance data where elements get replaced with the actual form values
> when the form gets submitted.

I could be wrong but I think their model is more complex and requires
sort of modifications to be made to the instance data. I was thinking
more about a bunch of named replacement parameters. Still it might make
sense to make reference to XForms somehow as an optional extra feature.

I'll delay the addition of both features to judge the need more.

> Would these be different kinds of inputs? You can certainly still have query
> and header inputs. Maybe you don't need the {variables} in your template if
> you put XPath expressions on the elements (variable? parameter?) that
> specify these.

Don't follow what you would do to put a "foo" attribute with value
extracted from a user-supplied variable called "bar" in the element
"blah" using XPaths. Here's what it looks like in my proposed model:

<blah foo="{bar}"/>

The thing that worries me is how to generate repeating structures.
Examplotron has an eg:occurs="+" attribute that says that a particular
structure is repeatable. But how does that translate into an API, as a
list of hashtables for that structure? I'll probably add this feature if
either a) I decide that the fixed-structure case is the common one,
rather than a repeating-structure case or b) I can find a clean, simple
way to handle the repeating structure case both in WRDL and the API.

> Would you be able to specify an output template as well?

It sort of makes sense. It might be a cheap, simple way of doing parsing
and data binding to hashtables or lists of hashtables. Maybe the
template parsing/serialization language is a different but related
language.

> I think this is really cool but I'm not sure if it's really necessary for
> WRDL. At least for an initial release. By the way, do you have a list of
> goals or requirements for the first release of WRDL? We certainly don't want
> to succumb to feature creep or we might have to change the R to an S. ;-)

The goal is to make it easy to statically pre-declare the structure of
XML and XHTML-based web services 

> > I think I will also rename it to reference-type, because really we're
> > classifying references. Make sense to you?
> 
> Sounds good. Are you switching to lisp-style identifiers instead of
> camelCase? I don't care which one you use but they should probably be
> consistent.

Good point. I guess camelCase is a little more compatible with non-lisp
languages. 

> > <!ELEMENT reference-type (documentation?, appinfo?)>
> >
> > <!ATTLIST reference-type name %Name; #REQUIRED
> >                     match %XPath; #REQUIRED
> >                     use %XPath; #REQUIRED
> >                     resourceType %QName; #REQUIRED>
> 
> Maybe the use attribute should be optional. I can imagine some resources
> containing a list of references with no obvious key. And perhaps some
> applications won't care about the keys.

True enough.

> Will the spec specify any sort of rules for compliant APIs? The question I
> have now is this: should the collection of references maintain the same
> order they were found in even if keyed? If so, we'd have to use a fancier
> data structure than a Hashtable or Map since those usually destroy the
> ordering. I would tend to think that the answer to this would be use but I
> don't have any particular use cases to justify it.

There should be some way to order them by position but it may not
require a special data structure. If you put a "documentPosition"
attribute on each reference/resource object then the application could
sort on that.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:787
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-25 02:14:37
Subject:WRDL DTD changes
Message:

1. Namespace attribute added.

2. extension-method -> otherMethod, media-type to mediaType

3. content models that had "annotation" before now have just
"documentation" and "appinfo". "documentation" is a subset of HTML (real
HTML probably eventually)

4.representationType elements now have a "namespace" attribute and
"schema" sub-element. They have experimentally lost the "test"
attribute.

5. referenceType elements now have a "key" attribute which is like
xsl:key/@use in XSLT.

Diff:

 <!ENTITY % Name "NMTOKEN">

 <!ELEMENT types (resourceType|representationType)*>
+<!ATTLIST types xmlns CDATA #FIXED "http://www.prescod.net/rest/wrdl">

-<!ENTITY % methods "(GET?,POST?,PUT?,DELETE?,extension-method?)">
+<!ENTITY % methods "(GET?,POST?,PUT?,DELETE?, otherMethod?)">


 <!ELEMENT GET (input?)>
 <!ELEMENT POST (input?, output?)>
 <!ATTLIST POST createdResourceType %QName; #IMPLIED>
 <!ELEMENT PUT (input?, output?)>
 <!ELEMENT DELETE (input?, output?)>
-<!ELEMENT extension-method (input?, output?)>
-<!ATTLIST extension-method name %Name; #REQUIRED
+<!ELEMENT otherMethod (input?, output?)>
+<!ATTLIST otherMethod name %Name; #REQUIRED
                 createdResourceType %QName; #IMPLIED>

 <!ELEMENT input (query*, header*)>
 <!ATTLIST input representations %QNames; #IMPLIED>

-<!ELEMENT query (annotation?)>
+<!ELEMENT query (documentation?, appinfo?)>
 <!ATTLIST query name %Name; #IMPLIED
                 type %QName; #IMPLIED
                 default CDATA #IMPLIED
                 use (optional|prohibited|required) "optional">

-<!ELEMENT header (annotation?)>
+<!ELEMENT header (documentation?, appinfo?)>
 <!ATTLIST header name  %Name; #IMPLIED
                 type %QName; #IMPLIED
                 default CDATA #IMPLIED
                 use (optional|prohibited|required) "optional">

-<!ELEMENT representationType (reference*)>
+<!ELEMENT representationType (reference|schema)*>
 <!ATTLIST representationType
             name %Name; #IMPLIED
-            media-type CDATA #IMPLIED
-            test CDATA #IMPLIED>
+            namespace CDATA #IMPLIED
+            mediaType CDATA #IMPLIED>

-<!ELEMENT reference (annotation?)>
+<!ELEMENT referenceType (documentation?, appinfo?)>

-<!ATTLIST reference name %Name; #REQUIRED
-                    match CDATA #REQUIRED
+<!ATTLIST referenceType name %Name; #REQUIRED
+                    match %XPath; #REQUIRED
+                    key %XPath; #IMPLIED
                     resourceType %QName; #REQUIRED>

-<!ELEMENT annotation (appinfo|documentation)+>
-<!ELEMENT documentation (#PCDATA)>
-<!ELEMENT appinfo (#PCDATA)>
+<!ELEMENT documentation (#PCDATA|p|b|a)>
+<!-- in the future, just refer to HTML -->
+<!ELEMENT appinfo (ANY)>
+<!ELEMENT p (#PCDATA|b|a)>
+<!ELEMENT b (#PCDATA|a)>
+<!ELEMENT a (#PCDATA|b)>
+<!ATTLIST a href CDATA #REQUIRED>






-----------------------------------------------------------------------------------
Post ID:788
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-25 21:00:05
Subject:REST and event based integration
Message:

Just noticed this in The Dissertation:

http://www1.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

"The interaction method of sending representations of resources to consuming
components has some parallels with event-based integration (EBI) styles. The
key difference is that EBI styles are push-based. The component containing
the state (equivalent to an origin server in REST) issues an event whenever
the state changes, whether or not any component is actually interested in or
listening for such an event. In the REST style, consuming components usually
pull representations. Although this is less efficient when viewed as a
single client wishing to monitor a single resource, the scale of the Web
makes an unregulated push model infeasible."

The part with 'whether or not any component is actually interested in or
listening' would seem to be dealt with through subscriptions - which might
imply that a regulated push model might be feasible.








-----------------------------------------------------------------------------------
Post ID:789
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-22 17:52:00
Subject:Re: [rest-discuss] Re: [XML-SIG] REST made more concrete still
Message:

>
>  * ?-parameters are not opaque. You're saying that it's okay for the
> client to try to understand tha part of the URI and fiddle with the part
> after the ? mark.
Is this true?
I thought even the ?query parts of the URI were opaque. With a POST you can
have a URI with ?query as well as a body composed of name=value pairs - with
overlapping names between the URI and body.

Perhaps I'm just confused whether the 'resource' is identified ONLY by the
uri 'path' or if it identified by the path+query. (and in html forms you
can't specify whether some inputs are inserted into the uri or into the
body)

Mike "margarita anyone?" Dierken









-----------------------------------------------------------------------------------
Post ID:790
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-25 23:33:48
Subject:Re: [rest-discuss] Re: [XML-SIG] REST made more concrete still
Message:

"S. Mike Dierken" wrote:
> 
> >
> >  * ?-parameters are not opaque. You're saying that it's okay for the
> > client to try to understand tha part of the URI and fiddle with the part
> > after the ? mark.
> Is this true?
> I thought even the ?query parts of the URI were opaque. 

Well they aren't opaque to the client, because the client had to
generate them (e.g. an HTML form). And they aren't opaque to the
servier, because the server has to interpret them. They probably should
be opaque to most intermediaries.

> ... With a POST you can
> have a URI with ?query as well as a body composed of name=value pairs - with
> overlapping names between the URI and body.

The ones in the body are opaque to HTTP implementations by virtue of the
fact that they are in the body. An HTTP implementation shouldn't be any
more interested in the body than if it was PDF. IMHO.
 
> Perhaps I'm just confused whether the 'resource' is identified ONLY by the
> uri 'path' or if it identified by the path+query. (and in html forms you
> can't specify whether some inputs are inserted into the uri or into the
> body)

The resource is identified by whatever goes after the method name.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:791
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-25 23:56:16
Subject:Re: [rest-discuss] REST and event based integration
Message:

"S. Mike Dierken" wrote:
> 
>...
> 
> The part with 'whether or not any component is actually interested in or
> listening' would seem to be dealt with through subscriptions - which might
> imply that a regulated push model might be feasible.

I agree. In fact I think it *is* feasible, until proven otherwise. ;)

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:792
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-26 01:54:15
Subject:WRDL change
Message:

I have been thinking about the relationship between representation types
and resource types. I believe that a resource type should entirely own a
representation type. One shouldn't think of RSS as a representation, one
should think of RSS_SiteSummary as a representation *of* the SiteSummary
resource type. And therefore RSS_SiteSummary should be a sub-element of
SiteSummary, not an independent element.

Rationale: The primary purpose of representation types is to extract
links for the resource type. It doesn't make sense to do this in the
abstract. A particular representation needs to extract its links for a
particular resource type. If the representation type is "purchase order"
and the references it is expecting are "acceptance_URI, customer_URI and
cancellation_URI" then the WRDL representation type needs to have
exactly those reference types...like a Java implementation of an
interface. Maybe the same concrete syntax (text/ebxmlpo+xml) is used as
a representation of another resource. In that context it will have
different reference types so it will be for all intents and purposes a
new representation.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:793
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-26 02:15:28
Subject:Re: [rest-discuss] WRDL change
Message:

Does this still support re-using a representation between different resource
types?

I may have have a "folder" resources that I want represented with rss, or
cdf voxml, or html or something else.
I may have "bookmarks" resources that I want represented as rss, cdf, html,
voxml, or something else.
I may have have "news" resources that I want represented with rss, or cdf
voxml, or html or something else.
I may have "weblog" resources that I want represented as rss, cdf, html,
voxml, or something else.



----- Original Message -----
From: "Paul Prescod" <paul@...>
To: "Jason Diamond" <jason@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Monday, February 25, 2002 5:54 PM
Subject: [rest-discuss] WRDL change


> I have been thinking about the relationship between representation types
> and resource types. I believe that a resource type should entirely own a
> representation type. One shouldn't think of RSS as a representation, one
> should think of RSS_SiteSummary as a representation *of* the SiteSummary
> resource type. And therefore RSS_SiteSummary should be a sub-element of
> SiteSummary, not an independent element.
>
> Rationale: The primary purpose of representation types is to extract
> links for the resource type. It doesn't make sense to do this in the
> abstract. A particular representation needs to extract its links for a
> particular resource type. If the representation type is "purchase order"
> and the references it is expecting are "acceptance_URI, customer_URI and
> cancellation_URI" then the WRDL representation type needs to have
> exactly those reference types...like a Java implementation of an
> interface. Maybe the same concrete syntax (text/ebxmlpo+xml) is used as
> a representation of another resource. In that context it will have
> different reference types so it will be for all intents and purposes a
> new representation.
>
>  Paul Prescod
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:794
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-26 15:13:21
Subject:Re: [rest-discuss] WRDL change
Message:

"S. Mike Dierken" wrote:
> 
> Does this still support re-using a representation between different resource
> types?
> 
> I may have have a "folder" resources that I want represented with rss, or
> cdf voxml, or html or something else.
> I may have "bookmarks" resources that I want represented as rss, cdf, html,
> voxml, or something else.
> I may have have "news" resources that I want represented with rss, or cdf
> voxml, or html or something else.
> I may have "weblog" resources that I want represented as rss, cdf, html,
> voxml, or something else.

My argument is that rss_as_represntation_for_weblog is a different
representation than rss_as_representation_for_news. Of course it is the
same content-type. But in WRDL representations are more than content
types. They also extract links (called "references") in the manner
"expected" by the resource type. If your news and weblog resources have
all of the same logical links to all of the same other types then they
are probably actually the same resource type (or have some subtyping
relationship which WRDL does not handle right now).

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:795
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-26 15:19:57
Subject:WRDL status
Message:

I haven't done the representsations change I discussed before yet, but I
have got a preliminary WRDL implementation in Python[1]. It implements
enough of WRDL to talk to babelfish and Meerkat. Unfortunately there are
very few public, read/write, REST-based, XML-based web services so I
haven't bothered with PUT and DELETE yet. Input and output type checking
is also unimplemented. The code just trusts you.

One neat thing that IS implemented is input argument (paramter or
header) renaming and defaulting. This means that the programmer's API
can be much cleaner and easier to read than the stuff going across the
wire. The WRDL file does the translation from "language=en_es" to
"&l=en_es". Here's some sample Python code:


def main(url):
    wrdl = Wrdl("meerkat.wrdl")

    # bind a resource type to a URI
    r = wrdl.newResource("meerkat", 
             "http://www.oreillynet.com/meerkat/")

    # now GET that resource...any representation
    res = r.GET_meerkat_xml_flavour( channel=555,
                    timePeriod="7DAY", search="Prescod") 

    # alternately, GET a particular representation
    # (in this case "meerkat_xml_flavour")
    res = r.GET_meerkat_xml_flavour( channel=555,
                    timePeriod="7DAY", search="Prescod") 

    text = res.body() # get resource body 
    assert text.find("Prescod")>0 # vanity assertion

    # get a list of references (XML or HTML hyperlinks)
    links = res.references("link")
    assert len(links)>1 # sanity check

    # download representation of first link
    newres = links[0].GET() 

    # get the resource body for that link
    text = newres.body()
    assert text.find("Prescod")>0 #vanity assertion

    wrdl = Wrdl("babelfish.wrdl")
    s = wrdl.newResource("babelfish", 
            "http://babelfish.altavista.com/tr")

    # do a POST
    res = s.POST(text="Hello world", languages="en_es")
    assert res.body().find("Hola")>0

    # more specific way of POSTing:
    res = s.POST_babelFormData_RETURNING_html(
                text="Hello world", languages="en_es")

On the wire:
GET /meerkat/?_fl=xml&t=7DAY&c=555&s=Prescod HTTP/1.1\r\n'
Host: www.oreillynet.com\r\n'
Accept-Encoding: identity\r\n'
Accept: text/xml\r\n'
Content-type: */*\r\n'
\r\n'
GET /meerkat/?_fl=xml&t=7DAY&c=555&s=Prescod HTTP/1.1\r\n'
Host: www.oreillynet.com\r\n'
Accept-Encoding: identity\r\n'
Accept: text/xml\r\n'
Content-type: */*\r\n'
\r\n'
GET /archives/xml-dev/200202/msg01225.html HTTP/1.1\r\n'
Host: lists.xml.org\r\n'
Accept-Encoding: identity\r\n'
Accept: */*\r\n'
Content-type: */*\r\n'
\r\n'
POST /tr HTTP/1.1\r\n'
Host: babelfish.altavista.com\r\n'
Accept-Encoding: identity\r\n'
Content-Length: 49\r\n'
Accept: text/html\r\n'
Content-type: application/x-www-form-urlencoded\r\n'
\r\n'
lp=en_es&tt=urltext&urltext=Hello+world&doit=done'
POST /tr HTTP/1.1\r\n'
Host: babelfish.altavista.com\r\n'
Accept-Encoding: identity\r\n'
Content-Length: 49\r\n'
Accept: text/html\r\n'
Content-type: application/x-www-form-urlencoded\r\n'
\r\n'
lp=en_es&tt=urltext&urltext=Hello+world&doit=done'

 [1] http://www.prescod.net/rest/wrdl.html






-----------------------------------------------------------------------------------
Post ID:796
Sender:Andrew Kuchling <akuchlin@...>
Post Date/Time:2002-02-26 17:13:10
Subject:Re: [rest-discuss] WRDL status
Message:

On Tue, Feb 26, 2002 at 07:19:57AM -0800, Paul Prescod wrote:
>    # now GET that resource...any representation
>    res = r.GET_meerkat_xml_flavour( channel=555,
>                    timePeriod="7DAY", search="Prescod") 

Is that intended to be r.GET(channel=...)?

Looks very cool.  If you want a public CVS repository for it, I'd
suggest using the pyxml.sourceforge.net one.

--amk








-----------------------------------------------------------------------------------
Post ID:797
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-02-26 17:17:03
Subject:Re: [rest-discuss] WRDL change
Message:

I think I understand what you're saying and it does make sense. It might
actually simplify things, too. Would you just move the reference elements to
the content of the output element?

Jason

----- Original Message -----
From: "Paul Prescod" <paul@...>
To: "Jason Diamond" <jason@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Monday, February 25, 2002 5:54 PM
Subject: [rest-discuss] WRDL change


> I have been thinking about the relationship between representation types
> and resource types. I believe that a resource type should entirely own a
> representation type. One shouldn't think of RSS as a representation, one
> should think of RSS_SiteSummary as a representation *of* the SiteSummary
> resource type. And therefore RSS_SiteSummary should be a sub-element of
> SiteSummary, not an independent element.
>
> Rationale: The primary purpose of representation types is to extract
> links for the resource type. It doesn't make sense to do this in the
> abstract. A particular representation needs to extract its links for a
> particular resource type. If the representation type is "purchase order"
> and the references it is expecting are "acceptance_URI, customer_URI and
> cancellation_URI" then the WRDL representation type needs to have
> exactly those reference types...like a Java implementation of an
> interface. Maybe the same concrete syntax (text/ebxmlpo+xml) is used as
> a representation of another resource. In that context it will have
> different reference types so it will be for all intents and purposes a
> new representation.
>
> Paul Prescod
>
>       Yahoo! Groups Sponsor
>             ADVERTISEMENT
>
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>







-----------------------------------------------------------------------------------
Post ID:798
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-02-26 17:53:10
Subject:[mnot@mnot.net: [Internet-Drafts@ietf.org: I-D ACTION:draft-nottingham-webi-warm-00.txt]]
Message:

----- Forwarded message from Mark Nottingham <mnot@...> -----

Date: Mon, 25 Feb 2002 09:58:54 -0800
From: Mark Nottingham <mnot@...>
To: Web Intermediaries List <webi@...>
Subject: [Internet-Drafts@...: I-D ACTION:draft-nottingham-webi-warm-00.txt]
User-Agent: Mutt/1.3.23i


I'll reiterate the abstract; this is a straw-man proposal, to get
discussion going.

Cheers,



----- Forwarded message from Internet-Drafts@... -----

Date: Mon, 25 Feb 2002 06:24:02 -0500
From: Internet-Drafts@...
Reply-To: Internet-Drafts@...
To: IETF-Announce: ;
Subject: I-D ACTION:draft-nottingham-webi-warm-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Web Active Resource Monitoring
	Author(s)	: M. Nottingham
	Filename	: draft-nottingham-webi-warm-00.txt
	Pages		: 13
	Date		: 22-Feb-02
	
WARM is a straw-man proposal for a solution to the RUP requirements
of the WEBI WG which reuses the Web Architecture (and HTTP).  In
particular, it provides a mechanism for distributing cache
invalidations from HTTP servers to clients.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nottingham-webi-warm-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nottingham-webi-warm-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@....
In the body type:
	"FILE /internet-drafts/draft-nottingham-webi-warm-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



----- End forwarded message -----

-- 
Mark Nottingham
http://www.mnot.net/
 

----- End forwarded message -----

-- 
Mark Nottingham
http://www.mnot.net/
 






-----------------------------------------------------------------------------------
Post ID:799
Sender:Jim Ancona <jim@...>
Post Date/Time:2002-02-26 18:08:28
Subject:Don Box predicts death of HTTP, film at 11
Message:

http://zdnet.com.com/2100-1105-845220.html

=====
Jim Ancona
jim@...                     jancona@...








-----------------------------------------------------------------------------------
Post ID:800
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-26 18:12:43
Subject:Re: [rest-discuss] WRDL change
Message:

Jason Diamond wrote:
> 
> I think I understand what you're saying and it does make sense. It might
> actually simplify things, too. Would you just move the reference elements to
> the content of the output element?

Let's invent some terminology. There are reference slots, which are
abstract, like abstract methods in a programming language, and there are
reference implementations, which are concrete and have XPaths into a
particular XML or XHTML format. So the abstract slots should be
associated with the output element. And the concrete implementations
should be associated with the representations. I haven't spec'ed any of
this but I'm guessing:

<output>
  <references> <!-- abstract references -->
    <referenceType 
	name="images" 
	type="graphicResourceType"
	keyed="false"/>
    <referenceType name="po"
	type="purchaseOrderResourceType"
        keyed="true"/>
  </references>

  <representation name="ebxml_transaction_catalog">
    <reference name="images" match="img/@href"/>
    <reference name="purchase_orders" match="/ebxmlpo"
key="../@number"/>
  </representation>
</output>

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:801
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-02-26 18:13:03
Subject:Re: [rest-discuss] Don Box predicts death of HTTP, film at 11
Message:

On Tue, Feb 26, 2002 at 10:08:28AM -0800, Jim Ancona wrote:
> http://zdnet.com.com/2100-1105-845220.html

Hmph. The technical details of this are a bit over my head, but it's
interesting to see one of the inventors of SOAP saying that

   Among the problems with HTTP, ... is the fact that it is a Remote 
   Procedure Call (RPC) protocol .... 

   This works for small transactions asking for Web pages, but when Web
   services start running transactions that take some time to complete over the
   protocol, the model fails.

So has he now decided that SOAP was a bad idea too? If so, he doesn't
say it. 

Also interesting:

   Microsoft has some ideas (on how to break the independence on HTTP)...

Hmm, was Bob Cringely right (or close) when he predicted "The Death of
TCP/IP?"

   http://www.pbs.org/cringely/pulpit/pulpit20010802.html

Ah, but [Box again]:

   IBM has some ideas, and others have ideas. We'll see," he said. 
   But, he added, "if one vendor does it on their own, it will simply
   not be worth the trouble." 

Of course not. Especially when it's a tiny, powerless vendor like 
Microsoft. Is it paranoid to smell a hidden agenda here?
-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:802
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-26 18:36:27
Subject:Re: [rest-discuss] WRDL status
Message:

Andrew Kuchling wrote:
> 
> On Tue, Feb 26, 2002 at 07:19:57AM -0800, Paul Prescod wrote:
> >    # now GET that resource...any representation
> >    res = r.GET_meerkat_xml_flavour( channel=555,
> >                    timePeriod="7DAY", search="Prescod")
> 
> Is that intended to be r.GET(channel=...)?

Yeah, I'll fix that. 

> Looks very cool. If you want a public CVS repository for it, I'd
> suggest using the pyxml.sourceforge.net one.

I'll probably do that when it settles down enough to have documentation
etc.

When you're done, will a demo version of your service be publicly
available for me to try testing a WRDL against?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:803
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-26 20:07:16
Subject:Re: [rest-discuss] Don Box predicts death of HTTP, film at 11
Message:

Let's attribute it to ignorance FIRST and then malice later.

Don's saying about HTTP what a lot of people are saying and thinking.
What he doesn't realize is that the issues he has with HTTP are easy to
solve but the solutions just aren't standardized. HTTPEvents deals with
his complaint about long-running transactions and the concern about
assymmetry isn't really thought through. 

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:804
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-02-26 20:38:04
Subject:Re: [rest-discuss] WRDL change
Message:

Hello.

> <output>
>   <references> <!-- abstract references -->
>     <referenceType
>       name="images"
>       type="graphicResourceType"
>       keyed="false"/>
>     <referenceType name="po"
>       type="purchaseOrderResourceType"
>         keyed="true"/>
>   </references>
>
>   <representation name="ebxml_transaction_catalog">
>     <reference name="images" match="img/@href"/>
>     <reference name="purchase_orders" match="/ebxmlpo"
> key="../@number"/>
>   </representation>
> </output>

I don't think the extra indirection is necessary. In fact, what I liked most
about your change was that it removed a level of indirection which is very
un-WSDL-like (which is good!).

The presence of the key attribute could indicate whether the reference is
keyed or not. The resourceType that the reference resolves to might as well
be on the reference element.

<output>
  <referenceType
    name='images'
    resourceType='graphicResourceType'
    match='img/@href'
  />
  <referenceType
    name='purchase_orders'
    resourceType='purchaseOrderResourceType'
    match='/ebxmlpo'
    key='../@number'
  />
</output>

If resources can "return" multiple representations then you maybe you can do
this instead:

<output>
  <representationType name='xhtml' test='/xhtml:html'>
    <referenceType
      name='images'
      resourceType='graphicResourceType'
      match='img/@href'
    />
  </representationType>
  <representation name='ebxmlpo' test='/ebxmlpo'
    <referenceType
      name='purchase_orders'
      resourceType='purchaseOrderResourceType'
      match='/ebxmlpo'
      key='../@number'
    />
  </representationType>
</output>

Of course, in the interest of modularity and reusability, I would think
about allowing you to define both representationTypes and referenceTypes as
children of the types document element.

<types>

  <resourceType name='someResourceType'>
    <output>
      <representation ref='xhtml' name='web_page' />
      <representation ref='ebxmlpo' />
    </output>
  </resourceType>

  <representationType name='xhtml' test='/xhtml:html'>
    <referenceType
      name='images'
      resourceType='graphicResourceType'
      match='img/@href'
    />
  </representationType>

  <representation name='ebxmlpo' test='/ebxmlpo'
    <reference ref='purchase_orders' name='purchase_orders' />
  </representationType>

  <referenceType
    name='purchase_orders'
    resourceType='purchaseOrderResourceType'
    match='/ebxmlpo'
    key='../@number'
  />

</types>

OK, so I went in re-added some extra indirection but it's strictly
syntactic. Notice that by making the type definitions and type references
different element types they can still be validated using a DTD or XML
Schema (unlike XML Schema until it gets co-constraints).

These are just rough ideas so feel free to tear them apart. :-)

Jason








-----------------------------------------------------------------------------------
Post ID:805
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-26 20:46:37
Subject:Re: [rest-discuss] Don Box predicts death of HTTP, film at 11
Message:

What a tool.  Here's one:  "REST Discussion List Predicts Death of XML-RPC,
SOAP-as-RPC, .NET, First-Gen Web Services, and Don Box's Career."  It's
amazing that otherwise apparently-smart people can fail to learn the same
lessons over, and over... and over...  and over...

jb


Jim Ancona wrote:

> http://zdnet.com.com/2100-1105-845220.html
>
> =====
> Jim Ancona
> jim@...                     jancona@...
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:806
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-26 21:40:18
Subject:Re: [rest-discuss] Don Box predicts death of HTTP, film at 11
Message:


"We have to do something to make it (HTTP) less important," said Box. "If we
rely on HTTP we will melt the Internet. We at least have to raise the level
of abstraction, so that we have an industry-wide way to do long-running
requests--I need a way to send a request to a server and not the get result
for five days."

That's what the response status of "Accepted" is meant for. Since there is
currently no common way of getting the final response people think it can't
be done. It can, but few other than Paul/etc. have blazed the trail.

If we play our cards right with asynch http we can fill in the missing piece
that the soap builders think requires a new protocol, and perhaps pop the
hype bubble surrounding soap. Resource modelling applied to asynch
communication isn't all that hard - put together some client and server apis
and a few whitepapers and let technology evolution take its course.

mike
PS
I'm not sure '...industry wide way...' is required or even good for a
decentralized/evolutionary system like the Web. A few large pockets that are
interoperable sounds good to me.


----- Original Message -----
From: "Jim Ancona" <jim@...>
To: <rest-discuss@yahoogroups.com>
Sent: Tuesday, February 26, 2002 10:08 AM
Subject: [rest-discuss] Don Box predicts death of HTTP, film at 11


> http://zdnet.com.com/2100-1105-845220.html
>
> =====
> Jim Ancona
> jim@...                     jancona@...
>
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:807
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-26 22:05:40
Subject:Re: [rest-discuss] Don Box predicts death of HTTP, film at 11
Message:

Jeff Bone wrote:
> 
> What a tool.  Here's one:  "REST Discussion List Predicts Death of XML-RPC,
> SOAP-as-RPC, .NET, First-Gen Web Services, and Don Box's Career."  It's
> amazing that otherwise apparently-smart people can fail to learn the same
> lessons over, and over... and over...  and over...

It boils down to this: very few people know how protocols work or how to
design them. If a protocol doesn't have a gadget called "long-lived
transactions" then clearly it can't do them. 

That's precisely why RPC is the wrong strategy. We will turn *everybody*
into a protocol designers. A year ago I said that we need SOAP because
it allows us to build protocols faster and we need more protocols for
all of these new problem domains. I was totally wrong.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:808
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-26 22:55:46
Subject:Re: [rest-discuss] Don Box predicts death of HTTP, film at 11
Message:


Paul Prescod wrote:

> That's precisely why RPC is the wrong strategy. We will turn *everybody*
> into a protocol designers. A year ago I said that we need SOAP because
> it allows us to build protocols faster and we need more protocols for
> all of these new problem domains. I was totally wrong.

Ditto, almost exactly.  The amazing thing is how *clearly* that POV is wrong,
post-facto.  Hindsight's usually 20-20 (x 20-20), but in this case it's more like
20-5 (x 20-5).  Or so it seems to me,

jb








-----------------------------------------------------------------------------------
Post ID:809
Sender:Michael Brennan <michael_brennan@...>
Post Date/Time:2002-02-27 01:23:53
Subject:RE: [rest-discuss] WRDL status
Message:

> From: Andrew Kuchling [mailto:akuchlin@...]

<snip/>

> Looks very cool.  If you want a public CVS repository for it, I'd
> suggest using the pyxml.sourceforge.net one.

How about a language-neutral repository, instead? Maybe start a "REST tools"
project at sourceforge and let people contribute implementations for
different languages, rather than tying this completely to Python. I, for
one, am a Java and COM/C++ developer.






-----------------------------------------------------------------------------------
Post ID:810
Sender:akuchlin@...
Post Date/Time:2002-02-27 04:06:48
Subject:Re: [rest-discuss] WRDL status
Message:

On Tue, Feb 26, 2002 at 10:36:27AM -0800, Paul Prescod wrote:
>When you're done, will a demo version of your service be publicly
>available for me to try testing a WRDL against?

If I decide to try the REST approach, then sure, I'll try to arrange
that.  The choice between REST and XML-RPC hasn't really been made in
my head yet, though.  (But the existence of running WRDL toolkits in
Python, Java, &c., would certainly swing the odds in one direction,
though.)

--amk                                                  (www.amk.ca)
A burden shared is a ... something or other.
    -- Bor, in "Terminus"






-----------------------------------------------------------------------------------
Post ID:811
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-02-27 07:44:13
Subject:Re: [rest-discuss] Don Box predicts death of HTTP, film at 11
Message:

> Ditto, almost exactly.  The amazing thing is how *clearly* that POV is wrong,
> post-facto.  Hindsight's usually 20-20 (x 20-20), but in this case it's more like
> 20-5 (x 20-5).  Or so it seems to me,

Don't tell that to BEEP promoters. 8-)

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:812
Sender:Allan Doyle <adoyle@...>
Post Date/Time:2002-02-27 21:37:08
Subject:PUT vs. POST
Message:

This message concerns itself with the issue of PUT vs. POST for
creating/updating resources. I'm trying to get a handle on some rules
of thumb for the time I want to actually apply REST...

Image the resource identified as http://foo.org/bar

Case 1. There is only a text/html representation and it's
        static. There are no other representations. It's ok to PUT an
        update to it. In fact you SHOULD or even MUST use PUT.

Case 2. There are 3 representations that can be retrieved using
        conneg: text/html, image/jpeg, or text/xml, and you somehow
        know that the html and jpeg representations are actually
        mapped from the xml representation. Let's call this the
        "ur-representation". Then you could conceivably PUT the xml
        representation. But it would not be sufficient to PUT the
        image or html representation since the underlying resource
        would be unable to generate the other representations from
        either the image or the html.

Case 3. The client knows nothing about the resource's static nature nor about
        its ur-representation. You can't PUT to it. You MUST use
        POST. In fact, this kind of resource can't be created without
        a "Processing Block" [1] which implies an already existing
        resource.

So perhaps the rules or thumb (ROT) are:

ROT 1. "To update/create a resource having only a single exposed
        representation, your design MUST allow for PUT of the
        ur-representation."

ROT 2. "To update/create a resource having multiple exposed
        representations, your design SHOULD allow for PUT of the
        ur-representation"

However in case 2/rule 2 aren't we violating the implicit contract of
PUT which is that there is no significant transformational process
involved? RFC 2616 Section 9.6 [2] says

  "The PUT method requests that the enclosed entity be stored under
  the supplied Request-URI."

So perhaps the conclusion really is that you can only PUT to a static
resource that exposes only a single representation.

Interestingly, 2616 leaves a back door open: 

  "A single resource MAY be identified by many different URIs. For
   example, an article might have a URI for identifying "the current
   version" which is separate from the URI identifying each particular
   version. In this case, a PUT request on a general URI might result
   in several other URIs being defined by the origin server."

I.e. the PUT could cause a "shift" of resource identifiers like
"http://foo.org/bar-current" and/or the creation of identifiers like
"http://foo.org/bar-previous".  Then that implies that it's OK to have
a higher-order process do stuff in response to a PUT. That leaves me
back at the stage where use of PUT or POST are equally defensible in
Case 2.

Some other material that might help with this conclusion seems only to
keep things as muddy:

Let's look at something most people are probably familiar with by now,
the REST Wiki [3]. There have been discussions about how it would be
good to be able to apply REST to maintaing a Wiki [4].

I read the arguments on that page about PUT vs. POST but am still left
with some vague uneasiness. It seems to me that the debate hinges on
the definition of resource and representation and on what I believe is
ambiguous treatment of the topic in Fielding's dissertation [5]. The
crux of the debate seems to be based on the fact that GET returns
representations and PUT was originally designed to create/replace
representations; but things like Wikis require a processing block
(c.f. [1] - Section 3.) to stitch the new/changed page back into the
Wiki. Someone (it's a bit hard to follow attribution) on [4] states

  "The entity in the PUT request may be the response to a later GET
  request, but if not, it is an alternate representation of the same
  resource, which is the important thing from a REST POV"

But that seems to me to sidestep the issue. Can updating/creating an
alternate representation of a resource cause all other representations
of that resource to change? Wishful thinking says "yes" because we
want the beneficial side-effect of PUTting a representation to a
resource to include the cache invalidation of previous GETs from that
resource.

Lets see what Fielding has to say. Fielding defines the term resource
in [6]

  "More precisely, a resource R is a temporally varying membership
  function MR(t), which for time t maps to a set of entities, or
  values, which are equivalent. The values in the set may be resource
  representations and/or resource identifiers."

He goes on to say

  "REST components perform actions on a resource by using a
  representation to capture the current or intended state of that
  resource and transferring that representation between components."

That sure does sound like PUTting "intended state" should affect the
resource itself. Next he says

  "For example, remote authoring of a resource requires that the
  author send a representation to the server, thus establishing a
  value for that resource that can be retrieved by later requests. If
  the value set of a resource at a given time consists of multiple
  representations, content negotiation may be used to select the best
  representation for inclusion in a given message."

This is all tantalizingly vague. He does not connect the dots between
the two sentences. I.e. what happens to the representation to affect
the resource and its subsequent exposed representations. And is
further complicated by some statements near the end of section 5.4.

  "The interaction method of sending representations of resources to
  consuming components has some parallels with event-based integration
  (EBI) styles. The key difference is that EBI styles are push-based."

Then he goes on to talk about how C2 "could operate in REST's pull
style". Is not a PUT of a representation a push? If so, then we're
still left wondering.

Moving along to Section 6 [7] we find out that all the representations
you can GET from a web server do not suffice to recreate a
resource. (He certainly does not talk about ur-resources.)

  "attempts to mirror the content of a Web server as files will fail
  because the resource interface does not always match the semantics
  of a file system, and because both data and metadata are included
  within, and significant to, the semantics of a representation. Web
  server content can be replicated at remote sites, but only by
  replicating the entire server mechanism and configuration, or by
  selectively replicating only those resources with representations
  known to be static"

When he talks about caching in Section 6.3.3.2, we find out that maybe
something can be PUT, but that representation cannot simply be picked
up by an intermediary cache. The implication is that the cache should
flag its content as invalid because

 "An HTTP cache cannot assume that what gets written through it is the
  same as what would be retrievable from a subsequent request for that
  resource, and thus it cannot cache a PUT request body and reuse it
  for a later GET response. There are two reasons for this rule: 1)
  metadata might be generated behind-the-scenes, and 2) access control
  on later GET requests cannot be determined from the PUT request."

He does not mention that alternate representations may be generated by
the PUT.

I'm also a bit curious about all the emphasis on cacheability. I
understand the need for caching. I understand why GET should be
idempotent. But given that we know nothing about the actual cache
topologies being deployed, it's a little hard to figure out how
effectively a single PUT from a single client to a resource can
invalidate more than a fraction of the cached representations of that
resource. It would seem more logical to me that caching services would
have to develop some additional handshaking to ensure timely cache
coherence. And I suspect that there are often caches from competing
cache service providers in play. It's unlikely they will talk to each
other as they see random "PUT"s flying by.

So the bottom line is that I'm still at odds with when to PUT and when
to POST, but I'm leaning towards my rules of thumb above.

Thanks for listening...

====
[1] http://www.ietf.org/internet-drafts/draft-baker-http-resource-state-model-01.txt 
[2] http://www.ietf.org/rfc/rfc2616.txt?number=2616
[3] http://internet.conveyor.com/RESTwiki/moin.cgi
[4] http://internet.conveyor.com/RESTwiki/moin.cgi/HowWikiComparesToRest
[5] http://www.ebuilt.com/fielding/pubs/dissertation/abstract.htm
[6] http://www.ebuilt.com/fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2
[7] http://www.ebuilt.com/fielding/pubs/dissertation/evaluation.htm

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle                         http://www.intl-interfaces.com
adoyle@...

                                                   







-----------------------------------------------------------------------------------
Post ID:813
Sender:Andrew Kuchling <akuchlin@...>
Post Date/Time:2002-02-27 23:07:06
Subject:Re: [rest-discuss] PUT vs. POST
Message:

On Wed, Feb 27, 2002 at 04:37:08PM -0500, Allan Doyle wrote:
>ROT 2. "To update/create a resource having multiple exposed
>        representations, your design SHOULD allow for PUT of the
>        ur-representation"
>
>However in case 2/rule 2 aren't we violating the implicit contract of
>PUT which is that there is no significant transformational process
>involved? RFC 2616 Section 9.6 [2] says
>
>  "The PUT method requests that the enclosed entity be stored under
>  the supplied Request-URI."

But the XML and GIF representations *are* the same resource; they must
be because they're given the same URI.  I don't interpret RFC2616 as
saying anything about no transformation being involved.  (For example,
the entity might be stamped with the ID of the user PUTting it; that's
certainly a transformation, though not a particularly complicated
one.)

XML-to-GIF is an extreme example, and I think the identity is more
obvious in less extreme cases.  For example,
http://www.novels.com/novel/The_Manticore might identify one
particular novel, and accessing that URL might get you plain ASCII,
HTML, PDF, or Braille; yet it's the same book no matter what
representation it's in.

--amk                                                  (www.amk.ca)
Homological algebra beckons -- brain relief in this context!
    -- Michael Hudson, 07 Nov 2001, in a discussion of Stackless Python






-----------------------------------------------------------------------------------
Post ID:814
Sender:Michael Brennan <michael_brennan@...>
Post Date/Time:2002-02-28 01:27:50
Subject:What's http://www.constantrevolution.com/ns/dtd?
Message:

I'm behind the curve on this discussion and trying to catch up. Sorry if
this is an ignorant question. 

Looking at the WRDL DTD at http://www.prescod.net/rest/wrdl.dtd I see
reference to a schema type called
"http://www.constantrevolution.com/ns/dtd". What is this?

Is this just intended to designate an XML DTD? If so, I'd prefer the RDDL
approach -- i.e. use
"http://www.isi.edu/in-notes/iana/assignments/media-types/application/xml-dt
d". If, on the other hand, this is some schema language I haven't heard of
before, where can I find info?

Thanks.






-----------------------------------------------------------------------------------
Post ID:815
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-28 02:59:10
Subject:Re: [rest-discuss] What's http://www.constantrevolution.com/ns/dtd?
Message:

Michael Brennan wrote:
> 
>...
> 
> Is this just intended to designate an XML DTD? If so, I'd prefer the RDDL
> approach -- i.e. use
> "http://www.isi.edu/in-notes/iana/assignments/media-types/application/xml-dt
> d". If, on the other hand, this is some schema language I haven't heard of
> before, where can I find info?

Sure, that would be fine. I just put it in as a placeholder while I
considered a better URI.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:816
Sender:Michael Brennan <michael_brennan@...>
Post Date/Time:2002-02-28 03:06:07
Subject:WRDL, SOAP and SOAP-Encoding
Message:

I'm still coming up to speed on this discussion, but I thought I'd chime in
with a few thoughts. Hopefully, I'm not misreading WRDL (or REST), but if I
am, I'm sure someone will correct me.  :-)

I also posted a fairly long message on the xml-dev list [1]. I didn't want
to cross-post, but I'd be happy to hear comments from folks on this list
regarding the thoughts I offered.

Everyone keeps fixating on the RPC aspects of SOAP. There seems to be this
implicit assumption that once you've debunked SOAP-RPC, SOAP has nothing to
offer. I disagree, and although I find these discussions about WRDL
interesting, I think it still fails to offer the sort of appeal that could
win some mindshare from the SOAP/WSDL crowd.

The simple XPath reliance is one notable example. Many SOAP toolkits are
intentionally quite lean. Many use SAX, or use a pull-based variant of SAX.
XPath matching is obviously problematic in such implementations.

Another thing to keep in mind is that SOAP Encoding can be useful even if
you are not using RPC. SOAP Encoding has an implicit data model that is
simple, yet expressive; it can be easily mapped into the native data
structures of just about any programming language, and it is easy to
serialize as XML. For those who are interested in exchanging *information*
between applications and are more interested in the data model than its
serialization format, SOAP Encoding can be quite convenient. It makes
implementation considerably easier when you want to model the messages with
high-level APIs that are a natural fit for the programming language of
choice. I don't think this is a bad thing. It's essentially no different
from what the RDF crowd is doing.

I'm thinking that WRDL needs something like a profile (or something similar)
for a certain class of web service that abides by some well defined rules to
ease implementations. This could offer similar benefits to the SOAP Envelope
and Encoding rules. The profile could be designated by a well-known URI,
just like SOAP Encoding. Implementations that are content to deal with just
that certain class of web service could easily round-trip between
programming language constructs and the XML syntax without having to offer
sophisticated schema-driven data-binding. Also, implementations could
recognize resource references and, ideally, differentiate between references
to shared context vs. resources pertinent to the operation performed or the
resource being addressed without having to support arbitrary XPath-based
addressing into the message.

These are just preliminary thoughts, but I thought I'd toss them out here
and see what people think. Don't get me wrong, though. WRDL looks
interesting, and I'm won to the notion that WSDL got it all wrong and that
the WRDL approach is on the right track. I just think that people are
missing the things about SOAP that genuinely appeal to many developers, and
I think its worth addressing these things head-on and try to win some
mindshare from the web service community.

[1] http://lists.xml.org/archives/xml-dev/200202/msg01393.html






-----------------------------------------------------------------------------------
Post ID:817
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-28 03:10:25
Subject:Re: [rest-discuss] PUT vs. POST
Message:

Andrew Kuchling wrote:
> 
>...
> 
> But the XML and GIF representations *are* the same resource; they must
> be because they're given the same URI.  I don't interpret RFC2616 as
> saying anything about no transformation being involved.  

I agree. I would say that it would be good form to say that if you do a
PUT to a particular resource with a particular content-type that a GET
to that same resource with the same content-type would get back the same
thing. But allowing alternate content-type representations is not really
considered a transformation.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:818
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-02-28 05:08:21
Subject:Re: [rest-discuss] PUT vs. POST
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>
> But allowing alternate content-type representations is not really
> considered a transformation.
>
Really? Why not? I would think just the opposite - alternate representations
are nothing but a transformation of a resource.






-----------------------------------------------------------------------------------
Post ID:819
Sender:"rdilipk" <rdilipk@...>
Post Date/Time:2002-02-28 18:52:17
Subject:Re: Don Box predicts death of HTTP, film at 11
Message:

not sure how many of you guys were at DevWeek - but somebody who was 
there has posted a first account summary [1] of exactly what Don said 
in his key note speech.  maybe reading this would avoid 
misunderstandings?

http://www.razorsoft.net/weblog/stories/2002/02/28/thatKeynoteyouKnowT
heOne.html

thanks
--Dilip


--- In rest-discuss@y..., Jim Ancona <jim@a...> wrote:
> http://zdnet.com.com/2100-1105-845220.html
> 
> =====
> Jim Ancona
> jim@a...                     jancona@x...







-----------------------------------------------------------------------------------
Post ID:820
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-28 20:25:14
Subject:Re: [rest-discuss] Re: Don Box predicts death of HTTP, film at 11
Message:

rdilipk wrote:
> 
> not sure how many of you guys were at DevWeek - but somebody who was
> there has posted a first account summary [1] of exactly what Don said
> in his key note speech.  maybe reading this would avoid
> misunderstandings?

Unfortunately this summary hardly touches upon what Don said about HTTP.
The zdnet article was actually more technical.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:821
Sender:"rdilipk" <rdilipk@...>
Post Date/Time:2002-02-28 20:55:58
Subject:Re: Don Box predicts death of HTTP, film at 11
Message:

--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
> Unfortunately this summary hardly touches upon what Don said about 
HTTP.
> The zdnet article was actually more technical.
> 
>  Paul Prescod

then how about this?
http://www.sellsbrothers.com/spout/#httpIsDead

--Dilip








-----------------------------------------------------------------------------------
Post ID:822
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-02-28 21:22:45
Subject:Re: [rest-discuss] Re: Don Box predicts death of HTTP, film at 11
Message:

rdilipk wrote:
> 
> --- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
> > Unfortunately this summary hardly touches upon what Don said about
> HTTP.
> > The zdnet article was actually more technical.
> >
> >  Paul Prescod
> 
> then how about this?
> http://www.sellsbrothers.com/spout/#httpIsDead

That article makes all of the points that we've been making in the
rest-discuss list for months (but in excellent detail and with clear
presentation). Don Box should have thought these issues through himself
before he gave the talk:

"The problems raised in the ZDnet article can essentially be summed up
thus: clients can't expose endpoints. To me, this doesn't look like a
problem with HTTP, it's a problem with the infrastructure. Changing the
protocol is certainly not sufficient to fix the infrastructure problems;
it's not clear to me that it is even necessary."

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:823
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-02-28 21:37:08
Subject:Re: [rest-discuss] Re: Don Box predicts death of HTTP, film at 11
Message:


rdilipk wrote:

> then how about this?
> http://www.sellsbrothers.com/spout/#httpIsDead

Let's not mince words:  Don views HTTP as "the cockroach of the Internet" ---
his own words.  Don's perfect world is one where the Internet is a universal
bus on which type-specific objects communicate.  That's a nice vision, but
one that is technically flawed in a very obvious way:  all attempts to build
such universal buses for type-specific objects or components has failed.

Agreement and problems with Don's POV:

(1)  Asymmetry of HTTP is a problem.  No doubt, I am in total agreement.  But
the problem can be solved in numerous HTTP-friendly ways, many of which have
been discussed on this list, more elsewhere.  That asymmetry doesn't mean we
have to chuck HTTP, though;  there's exponential value in putting an HTTP
listener everywhere there are resources of interest, exposing those resources
through HTTP.  Dealing with the firewall is simply a matter of standardizing
generic rendezvous intermediaries and how they interact with domain naming.

(2)  His concern over long-running transactions is a red herring.  Think
about it this way:  existting client-server DB connection protocols support
transactions --- even long-running ones --- and transaction management at a
semantic level.  However, these things are modeled on top of RPCs, which are
1-shot, synchronous, and provide no transactional semantics.  HTTP doesn't
directly model transactions, but that doesn't mean you can't build
transactional systems on top of it.  It's simply a matter of modeling your
"application" (i.e., resources or domain objects and their interactions)
appropriately.

(3)  He fails to factor out the need for long-running "transactions" and
asynchronous messaging.  They are related but different.  Again, HTTP's
fundamentally synchronous nature doesn not prevent asynchronous
communications patterns from being used.  Paul's HttpEvents spec, Mark
Nottingham's WARM / RUP work, and so on are nascent attempts to define how to
do asynchronous communications in a manner that fits with the current Web
architecture.

(4)  Fundamentally, Don's got a very deep vested interest in seeing RPC-style
SOAP interfaces deployed universally;  this interest is rooted in Microsoft's
own deeply vested interest in maintaining balkanization of data and systems
and integration friction.  To the extent that the Web architecture succeeds,
it strategically devalues Microsoft.

(5)  Don and the rest of the SOAP-RPC camp are suffering from yet another
iteration of a fundamental failure of software engineering and design.  Our
industry was sold a bill of goods about "reuse," productivity gains, etc.
-wrt- OO 10-15 years ago.  In the process of buying into the OO religion, we
failed to learn an important lesson:  OO rarely works as a large-scale
integration methodology.  Generic interfaces and generic composition
frameworks have always demonstrated better scalability, reusablility,
simplicity, economics, etc. than OO.  Cases in point:  UNIX, Plan 9, the Web,
Linda.  Until we as an industry learn the lessons these examples pose, we're
doomed to fail over and over again, developing technologies that cannot
withstand the test of time and ubiquity:  ONC and DCE RPC, CORBA, DCOM, etc.

jb









-----------------------------------------------------------------------------------
Post ID:824
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-03-01 00:01:11
Subject:WRDL Notes
Message:

Hi, Paul.

I see you have a new draft up! Would it be possible to put the date of each
draft at the top so that we can tell when you've made changes?

The DTD has a bad mixed content model for the documentation element (you
need a * at the end). Wouldn't making it ANY be easier? What if I want to
use DocBook for my documentation? (This is why I prefer a single annotation
element with a content model of ANY--I could then put multiple elements in
there with different names or attributes to indicate mediaType or language
or anything else I wanted.)

The links to the Babelfish example and Python implementation are broken.

Regarding the new namespace attribute on representationType elements: My
faith in being able to use namespaces to reliably identify a document is
very slim. I see them (as Patrick Stickler recently pointed out) as merely
punctuation. The mediaType attribute seems much more capable of identifying
a representation. What would we use the namespace attribute for?

Regarding the new schema elements: Do we really want to embed schemas in
WRDL documents? Wouldn't it be more maintainable if we could reference them?

Regarding the occurs attribute on reference elements: Should there be a way
for the generated proxies to require that a reference appears? I might
suggest regular expression-like values "?" for zero or one, "*" for zero or
more, and "+" for one or more. The absence of an occurs attribute could
imply that only one reference is required (what happens if there's more than
one? Does it only match the first?). This makes it possible for proxies to
throw exceptions if a required reference is missng.

Regarding the key attribute: You don't mention it but I assume that it's
implied, does the presence of a key attribute always indicate that multiple
references are allowed? Would the occurs attribute then apply to the number
of values that can be associated with each key?

Regarding the type attribute on reference elements: The description is
somewhat vague. If I do a GET on a URI identified by a reference, is it like
doing a GET on a resourceType with the same name as the type attribute? What
happens when the type is missing? What would the proxy generator generate
then? Would it return something generic like a byte stream?

Hope this helps,
Jason








-----------------------------------------------------------------------------------
Post ID:825
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-01 01:36:28
Subject:Re: [rest-discuss] Re: Don Box predicts death of HTTP, film at 11
Message:

----- Original Message -----
From: "Jeff Bone" <jbone@...>

>
> (4)  Fundamentally, Don's got a very deep vested interest in seeing
RPC-style
> SOAP interfaces deployed universally;  this interest is rooted in
Microsoft's
> own deeply vested interest in maintaining balkanization of data and
systems
> and integration friction.  To the extent that the Web architecture
succeeds,
> it strategically devalues Microsoft.

This is a very important point - and you don't have to be a conspiracy freak
to see it or believe it.








-----------------------------------------------------------------------------------
Post ID:826
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-01 03:52:17
Subject:Re: [rest-discuss] Re: Don Box predicts death of HTTP, film at 11
Message:


"S. Mike Dierken" wrote:

> This is a very important point - and you don't have to be a conspiracy freak
> to see it or believe it.

This is hopefully true notwithstanding the fact that the person that originally
made the assertion mentioned -- i.e. me -- is probably on some level a
certifiable conspiracy freak. ;-)  (Long-winded way of saying "thanks Mike!" ;-)

jb








-----------------------------------------------------------------------------------
Post ID:827
Sender:"Peter Drayton" <peter@...>
Post Date/Time:2002-03-01 04:34:27
Subject:RE: [rest-discuss] Re: Don Box predicts death of HTTP, film at 11
Message:

However, the interesting thing is that the keynote gave me the distinct
impression that Don favored messaging over RPC. He spent quite a bit of
time talking about how it wasn't at all clear that "stretching RPC out
to internet scale" would work, and how a potentially much better
approach would be to shrink messaging down to work "in the small".
According to him, the issue there is the programming model, which is
what he said he's working on at Microsoft.

When I wrote up [1] the various themes that Don touched on, I
deliberatedly avoided saying which side of the issues Don came down on,
since the writeup would have been waaay longer. My point was that the
keynote covered more ground thatn merely "HTTP is dead", and the other
themes were also interesting questions in their own right. 

--Peter

[1] http://www.razorsoft.net/weblog

> -----Original Message-----
> From: S. Mike Dierken [mailto:mdierken@...] 
> Sent: Friday, March 01, 2002 1:36 AM
> To: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Re: Don Box predicts death of 
> HTTP, film at 11
> 
> ----- Original Message -----
> From: "Jeff Bone" <jbone@...>
> 
> >
> > (4)  Fundamentally, Don's got a very deep vested interest in seeing
> RPC-style
> > SOAP interfaces deployed universally;  this interest is rooted in
> Microsoft's
> > own deeply vested interest in maintaining balkanization of data and
> systems
> > and integration friction.  To the extent that the Web architecture
> succeeds,
> > it strategically devalues Microsoft.
> 
> This is a very important point - and you don't have to be a 
> conspiracy freak
> to see it or believe it.







-----------------------------------------------------------------------------------
Post ID:828
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-01 19:34:19
Subject:Re: [rest-discuss] WRDL Notes
Message:

Jason Diamond wrote:
> 
> Hi, Paul.
> 
> I see you have a new draft up! Would it be possible to put the date of each
> draft at the top so that we can tell when you've made changes?

Will do.

> The DTD has a bad mixed content model for the documentation element (you
> need a * at the end). 

True.

> ... Wouldn't making it ANY be easier? What if I want to
> use DocBook for my documentation? 

I think that there has to be standardization. If I write a tool to
extract documentation from a WRDL it will only work if I know what the
element types are. Therefore I want to strongly encourage people towards
one standard (whether it be XHTML or Docbook) and if you really must do
your own thing then you can do it in an AppInfo tag.

(This is why I prefer a single annotation
> element with a content model of ANY--I could then put multiple elements in
> there with different names or attributes to indicate mediaType or language
> or anything else I wanted.)

How do you figure out how to process the elements? From the namespace? I
thought you didn't trust that?

> The links to the Babelfish example and Python implementation are broken.

I'm having trouble uploading through a firewall but I'll fix that when I
can.

> Regarding the new namespace attribute on representationType elements: My
> faith in being able to use namespaces to reliably identify a document is
> very slim. I see them (as Patrick Stickler recently pointed out) as merely
> punctuation. The mediaType attribute seems much more capable of identifying
> a representation. What would we use the namespace attribute for?

Because many XML vocabularies will not have media types. I am very
sympathetic to Patrick's view but in my own language I'm more concerned
about popularity than purity. If the W3C decides that namespaces are The
Way to identify document types then I want WRDL to be compatible. If
they don't, I'll deprecate it. Plus, there is no good replacement.
DOCTYPES only work with DTDs. There is no standardized PI or anything
else.

> Regarding the new schema elements: Do we really want to embed schemas in
> WRDL documents? Wouldn't it be more maintainable if we could reference them?

That's why it has an href attribute!

> Regarding the occurs attribute on reference elements: Should there be a way
> for the generated proxies to require that a reference appears? I might
> suggest regular expression-like values "?" for zero or one, "*" for zero or
> more, and "+" for one or more. The absence of an occurs attribute could
> imply that only one reference is required (what happens if there's more than
> one? Does it only match the first?). This makes it possible for proxies to
> throw exceptions if a required reference is missng.

What about stealing minOccurs and maxOccurs from XML Schema?

> Regarding the key attribute: You don't mention it but I assume that it's
> implied, does the presence of a key attribute always indicate that multiple
> references are allowed? 

Probably better to still require the minOccurs attribute but...

> ... Would the occurs attribute then apply to the number
> of values that can be associated with each key?

No, I can't follow that logic. I think it should still just count the
number of hits to the reference.

> Regarding the type attribute on reference elements: The description is
> somewhat vague. If I do a GET on a URI identified by a reference, is it like
> doing a GET on a resourceType with the same name as the type attribute? 

Right.

> ... What
> happens when the type is missing? What would the proxy generator generate
> then? Would it return something generic like a byte stream?

Yes, the Python implementation (which I thought was on the site) has a
GenericResource type. It has no references so it is basically a
navigational dead-end. But you can GET and POST and PUT and DELETE it.
And yes you can get the byte stream if you ask for it (but that's true
even of XML resources).

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:829
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-01 19:39:46
Subject:Re: [rest-discuss] Re: Don Box predicts death of HTTP, film at 11
Message:

Peter Drayton wrote:
> 
> However, the interesting thing is that the keynote gave me the distinct
> impression that Don favored messaging over RPC. He spent quite a bit of
> time talking about how it wasn't at all clear that "stretching RPC out
> to internet scale" would work, and how a potentially much better
> approach would be to shrink messaging down to work "in the small".

That sounds to me like: "We tried to force one non-Internet model onto
the Internet and it didn't work. Now we're about to try to force another
non-Internet model onto the Internet. Maybe that will work. Oh, and by
the way, that protocol that is the basis for most of the Internet's most
sophisticated applications? Let's kill that."

> According to him, the issue there is the programming model, which is
> what he said he's working on at Microsoft.

People have spent the last five years adopting to the Web's programming
model, inconvenient as it is.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:830
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-02 08:01:38
Subject:RESTify a business document exchange app
Message:

Here is a message that describes a reasonable message exchange with first
class resources for the business document exchange

http://groups.yahoo.com/group/rest-discuss/message/88



----- Original Message -----
From: "bhaugen32" <bhaugen32@...>
To: <rest-discuss@yahoogroups.com>
Sent: Tuesday, February 19, 2002 5:13 AM
Subject: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language


> "S. Mike Dierken" <mdierken@h...> wrote:
> > > B. How do you handle order fulfillment?
> > It's out of band for our app - we just delivery the docs. If a
> business
> > document is defined for 'shipping notice' or 'delivery status' or
> whatnot,
> > we'll deliver those.
>
> Got any ideas on how you might RESTify this app?
> Possibly relevant excerpt from REST Wiki FAQ:







-----------------------------------------------------------------------------------
Post ID:831
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-02 14:15:38
Subject:Re: RESTify a business document exchange app
Message:

"S. Mike Dierken" <mdierken@h...> wrote:
> Here is a message that describes a reasonable message exchange with 
first
> class resources for the business document exchange
> 
> http://groups.yahoo.com/group/rest-discuss/message/88

Thank you, very nice and suggestive.
I like it much better than one of the previous proposals that had the 
order changing its identity with every change of state.

If I understand correctly, in your proposal, subsequent conversations 
about the order would be addressed to sub-resources of the same 
order.  And you laid out the business process as a series of return 
addresses for subsequent conversational acts.

Did the example referenced above depict a "real" business exchange?
(I don't mean the contents, just the conversational acts.)

Also, I wonder if the idempotency of PUT might be a problem in a 
slightly more elaborate conversation:
for example, if the Acknowledgment of Submission were supposed to be 
followed by an explicit Acceptance or Rejection, e.g.

== Submitting a purchase order ==
POST http://www.widgets.com/industrial/widgets/purchase-orders/ 
HTTP/1.1
Ack-To: http://www.smallbiz.com/accounting/po/12345/ack/
Response-To: http://www.smallbiz.com/accounting/po/12345/response/

So there would be a couple of ways to do it.  As above, where the 
response could say "Accept" or "Reject" or maybe "Counter Offer To 
Come" (we're negotiating, and the deal is still alive).  

Or you could do:
Acceptance-To: http://www.smallbiz.com/accounting/po/12345/accept/
Rejection-To: http://www.smallbiz.com/accounting/po/12345/reject/

In either case, couldn't you have an ambiguous state of the order 
with more than one PUT, one indicating acceptance, the other 
rejection?  

Would a POST to the order (handle this submission as a sub-resource) 
be more semantically accurate?  How would that change the 
conversation process addresses?

Just thinking about it...not sure I am thinking clearly yet.

Thanks,
Bob Haugen









-----------------------------------------------------------------------------------
Post ID:832
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-03 00:11:40
Subject:Re: [rest-discuss] Re: RESTify a business document exchange app
Message:

> ----- Original Message -----
> From: "bhaugen32" <bhaugen32@...>

> >
> > http://groups.yahoo.com/group/rest-discuss/message/88
>

> Did the example referenced above depict a "real" business exchange?
> (I don't mean the contents, just the conversational acts.)
No - it was not an actual exchange that took place - only a mental
experiment.
As I learn more about how real businesses exchange real documents (paper,
fax, etc.) I will be able to make the sample message exchange more
realistic. However, from what I can tell of the real world of (small/medium)
business, there is not a lot of consistency between the millions of
different businesses.

mike






-----------------------------------------------------------------------------------
Post ID:833
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-03 12:41:39
Subject:Re: RESTify a business document exchange app
Message:

"S. Mike Dierken" wrote:
> from what I can tell of the real world of (small/medium)
> business, there is not a lot of consistency between the millions of
> different businesses.

1. There is more consistency than you may think.
There is both commercial law and a body of common
practices that differ somewhat by region and
industry, but have some common elements everywhere.

2. For electronic commerce, there have been years
of work on standardization.  I know, standards are
so nice because there are so many of them.

But all of the initiatives below are related, as a family of 
standards where each used and built upon the predecessor:


* UNIFORM RULES OF CONDUCT FOR INTERCHANGE OF TRADE DATA BY 
TELETRANSMISSION (UNCID),
http://www.unece.org/trade/untdid/texts/d220_d.htm 
* UN/ECE RECOMMENDATION No.26, THE COMMERCIAL USE OF INTERCHANGE 
AGREEMENTS FOR ELECTRONIC DATA INTERCHANGE, 
http://www.unece.org/trade/untdid/texts/d240_d.htm
* The Commercial use of Electronic Data Interchange, Section of 
Business Law American Bar Association, A report and model trading 
partner agreement,
http://www.abanet.org/buslaw/catalog/5070258.html 
* ISO Open-EDI
http://www.jtc1sc32.org/
http://www.rosettanet.org/
http://www.ebxml.org/
http:/www.ebtwg.org/

I'm not suggested you read all of the above.
But here is a concrete example-in-progress:
http://lists.ebtwg.org/archives/ebtwg-bcp/200202/msg00020.html

That example is supposed to be technology-neutral, but there are a 
lot of P2P EDI assumptions in the group.  My purpose for hanging out 
on this list is to figure out what it would mean to RESTify some of 
this body of work.

Have fun,
Bob Haugen









-----------------------------------------------------------------------------------
Post ID:834
Sender:<bouncypvc1@...>
Post Date/Time:2002-03-05 11:16:41
Subject:Free Spring Water, Coffee and Tea for your office
Message:

 




 

	




	


100 Cups

18 Litres Buxton Water

Hot Drinks Pack:

CONTAINING:
Nescafe
Tetley Tea
Options Hot Chocolate
Batchelors Cup a Soups

WOULD YOU LIKE TO TRY A BUXTON WATERCOOLER?
Our Unique hot & cold beverage solution incorporating Buxton Water & hot
beverages - it's much more than just a watercooler!!
 

 	A fully maintained hot & cold drinks solution for your workplace

 	A full range of beverages including Nescafe & Gold Blend Coffee,
Options Hot Chocolate, Tetley Tea and Batchelors Cup a Soups	 
 	Free, no obligation 7 day trial with water, cups and beverage
sample pack	 
 
Please send me a free trial	 
 
Please send me more information	 



 

	
	
	
SPECIAL OFFER PRICES
RENTAL ONLY 2.50 PER WEEK & WATER IS ONLY 6.35 per 18.9ltr BOTTLE
IF YOU DECIDE TO KEEP THE COOLER YOU WILL RECEIVE
A 20 HIGH STREET GIFT VOUCHER OF YOUR CHOICE
OR
3 FREE BOTTLES OF BUXTON WATER
	
	
	

 

	




	


Water Cups

 

Our compact, stylish watercooler that delivers fresh, chilled Buxton
Water
 
 	It is a well known fact that every day your body needs 1.8
litres of water	 
 	We provide a customer service programme second to none	 
 	Free, no obligation 7 day trial with water cups	 
 
Please send me a free trial	 
 
Please send me more information	 

	

FAXBACK ON 0871 8550802 OR CALL 0800 2796969


SIMPLY FILL IN THE FORM BELOW & WE WILL DELIVER TO YOUR DOOR WITHIN 48
HOURS:

PLEASE COMPLETE BELOW:	  	 
Name:  	 	Phone:  	 	
Company:  	 	Fax:  	 	
Title:  	 	Postcode:  	 	
 
	
 	 
 
We try to ensure that those people who do not wish to receive emails do
not receive them by ensuring our agencies cleanse use the FPS database.
If you do not wish to receive emails please return an email with
UNSUBSCRIBE in the title and we shall remove your email address from the
database. 





-----------------------------------------------------------------------------------
Post ID:835
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-05 14:29:19
Subject:Re: [rest-discuss] PUT vs. POST
Message:

"S. Mike Dierken" wrote:
> 
> ----- Original Message -----
> From: "Paul Prescod" <paul@...>
> > But allowing alternate content-type representations is not really
> > considered a transformation.
> >
> Really? Why not? I would think just the opposite - alternate representations
> are nothing but a transformation of a resource.

I meant that the PUT is not semantically a transformation. It is a
transformation only in the sense that you transform from the
representation to the underlying bits that comprise the resource. It
isn't semantically an HTML to GIF transformation. It's an HTML to
"graphical object" converter, which happens to generate GIF
representations if you ask for them.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:836
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-03 00:31:34
Subject:Re: [rest-discuss] Re: RESTify a business document exchange app
Message:

----- Original Message -----
From: "bhaugen32" <bhaugen32@...>
To: <rest-discuss@yahoogroups.com>
Sent: Saturday, March 02, 2002 6:15 AM
Subject: [rest-discuss] Re: RESTify a business document exchange app



>
> Also, I wonder if the idempotency of PUT might be a problem in a
> slightly more elaborate conversation:
> for example, if the Acknowledgment of Submission were supposed to be
> followed by an explicit Acceptance or Rejection, e.g.
>
> == Submitting a purchase order ==
> POST http://www.widgets.com/industrial/widgets/purchase-orders/
> HTTP/1.1
> Ack-To: http://www.smallbiz.com/accounting/po/12345/ack/
> Response-To: http://www.smallbiz.com/accounting/po/12345/response/
>
> So there would be a couple of ways to do it.  As above, where the
> response could say "Accept" or "Reject" or maybe "Counter Offer To
> Come" (we're negotiating, and the deal is still alive).
>
> Or you could do:
> Acceptance-To: http://www.smallbiz.com/accounting/po/12345/accept/
> Rejection-To: http://www.smallbiz.com/accounting/po/12345/reject/
>
> In either case, couldn't you have an ambiguous state of the order
> with more than one PUT, one indicating acceptance, the other
> rejection?
>
The two headers 'reply-to' and 'status-to' were meant to separate out
advisory messages describing processing of a message from
application/semantic response messages. The 'reply-to' is the authoritative
status of the 'business response' to the business request. More than one
differing values PUT there would be an error (for most business document
exchanges, some agreements may allow updates to invoices, etc., but I'm not
a business guy so it may be those things are new resources somehow related
to the original message). More than one differing value sent to the status
would be okay.

I wouldn't put application specific concepts in headers - generic asynch
messaging and resource manipulation concepts would be okay though. So
'rejection' and 'acceptance' are busines concepts & should stay out of a
header name. They should be a value within a message body that is sent as
the 'application response'. Knowing where to put the response is a generic
concept to request/response message exchanges. In a typical synchronous
request/response, you just send it in the response (in http the correlation
between req/resp happens because of the single connection, a wicked cool
simplification). In a two-phase request response, you put it to the response
location - the location being the correlation information - but it is the
same concept as synch request/response.

In the sample the status is updated with PUT - but if the server wants to
keep a history, perhaps it should be POST. But I don't want the clients
needing to know what the server intends to do. I'd like to expose the
resource as the 'current status' - no assumptions about 'extending' an audit
trail - and so I used PUT.  If the server chooses to keep history, then I
suppose a new resource is needed for the audit trail - which would be a
collection of previously PUT entities.








-----------------------------------------------------------------------------------
Post ID:837
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-04 17:59:56
Subject:REST in RDF
Message:

I responded to Paul on xml-dev recently explaining my general
dissatisfaction with method-granularity interface specs like WIDL,
WSDL, WRDL, etc...

Here's my suggestion for a next-gen interface mechanism;

http://www.markbaker.ca/2002/03/RestRDF/

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:838
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-05 17:32:31
Subject:Re: [rest-discuss] PUT vs. POST
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>
To: "rest-discuss" <rest-discuss@yahoogroups.com>

> I meant that the PUT is not semantically a transformation. It is a
> transformation only in the sense that you transform from the
> representation to the underlying bits that comprise the resource. It
> isn't semantically an HTML to GIF transformation. It's an HTML to
> "graphical object" converter, which happens to generate GIF
> representations if you ask for them.

Oh, okay, I see. The 'platonic resource' can't be touched, but you can
interact with the shadows on the wall.

mike






-----------------------------------------------------------------------------------
Post ID:839
Sender:Michael Brennan <michael_brennan@...>
Post Date/Time:2002-03-05 23:30:48
Subject:RE: [rest-discuss] REST in RDF
Message:

> From: Mark Baker [mailto:distobj@...]

<snip/>

> I responded to Paul on xml-dev recently explaining my general
> dissatisfaction with method-granularity interface specs like WIDL,
> WSDL, WRDL, etc...
> 
> Here's my suggestion for a next-gen interface mechanism;
> 
> http://www.markbaker.ca/2002/03/RestRDF/

This looks good to me. I feel there is a need for higher-level archetypes
that can be more easily aligned with the sorts of models business developers
use. This looks to me like a promising direction.

I'm curious how one would model workflow with something like this.
Traditional OO often uses state machines as part of modelling such a
solution, whereas (based on comments I've heard here, on the REST wiki, and
on xml-dev) REST encourages the use of resources to model steps in a
workflow. Presumably, where necessary, one would use transient resources
that expire when the workflow is complete, or a step in the workflow that
invalidates this resource is taken. Would it make sense to have an archetype
in the taxonomy for such resources?






-----------------------------------------------------------------------------------
Post ID:840
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-05 22:45:16
Subject:Re: RESTify a business document exchange app
Message:

"S. Mike Dierken" <mdierken@h...> wrote:
> The two headers 'reply-to' and 'status-to' were meant to separate 
out
> advisory messages describing processing of a message from
> application/semantic response messages. The 'reply-to' is the 
authoritative
> status of the 'business response' to the business request. 

I can go along with that, depending on what you mean by status.
The chain of standards I alluded to in a previous message (UNECE-ISO-
RosettaNet-ebXML) makes a similar distinction.  ebXML calls the 
business content "Business Documents" and the status 
messages "Signals".  

The status signals tend to be simple ACKs but depending on agreement, 
acceptance could also be a signal.  (Simple cases.)

In more complex cases, acceptance would be a substantive business 
document.  If I understand your proposal correctly, you would always 
make acceptance a substantive response, which works fine for me.

> Knowing where to put the response is a generic
> concept to request/response message exchanges. In a typical 
synchronous
> request/response, you just send it in the response (in http the 
correlation
> between req/resp happens because of the single connection, a wicked 
cool
> simplification). 

Seems like a good slot for a simple receipt ACK.
 
> In the sample the status is updated with PUT - but if the server 
wants to
> keep a history, perhaps it should be POST. But I don't want the 
clients
> needing to know what the server intends to do. I'd like to expose 
the
> resource as the 'current status' - no assumptions about 'extending' 
an audit
> trail - and so I used PUT.  If the server chooses to keep history, 
then I
> suppose a new resource is needed for the audit trail - which would 
be a
> collection of previously PUT entities.

The above paragraph seems to imply that you are thinking of something 
different for status than simple ACKs.  

Are you thinking of Delivery and Payment as statuses?  If so, I got 
an argument for you...

But so far, moving forward.

Thanks,
Bob Haugen







-----------------------------------------------------------------------------------
Post ID:841
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-06 05:35:49
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

----- Original Message -----
From: "bhaugen32" <bhaugen32@...>

>
> My goal in joining your discussion is to take some of the business
> concepts from ebXML and RESTify them.  I hope to influence ebXML and
> related efforts to move in the REST direction.
>
> I find it fairly natural to model business objects as suites of Web
> resources.  (Paul Prescod:  refering to one of your recent opponents
> on the xml-dev list, I think it is perfectly feasible to model almost
> everything in any business application system (ERP, CRM, etc.) in Web
> resources.)

Any luck with getting someone to do a pure http binding for the Registry and
Repository services? They seem to /beg/ for a simple URI and http access
mechanism.

Maybe we can convince MarkB to do that like he did with some xml-rpc
interfaces.

I'll go start a page in the Wiki...







-----------------------------------------------------------------------------------
Post ID:842
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-06 05:16:57
Subject:Re: [rest-discuss] Re: RESTify a business document exchange app
Message:

> ----- Original Message -----
> From: "bhaugen32" <bhaugen32@...>

>
> In more complex cases, acceptance would be a substantive business
> document.  If I understand your proposal correctly, you would always
> make acceptance a substantive response, which works fine for me.
When there is a substantive business document, I would always want a
first-class resource (uri, etc.).
There is probably always going to be a business document for full acceptance
of a business request - correct me if I'm wrong.
The initial submission ack might not have a substantive business document
defined.

If we POST a biz doc and return an 'Accepted' status to indicate that the
document was transferred but not yet processed,
I'm not sure about returning a Location header (the http rfc doesn't mention
it - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3 ).
The existence of a document might imply business acceptance - which is not
correct. If the business process defines acknowledgement or status documents
that have 'accepted', 'rejected' and 'undecided' values, then this would be
fine I think (retrieving the status document tells you if it was actually
approved). If the business document set doesn't define 'undecided' values
then the Location header might need to reference a resource that does not
yet exist - and when it does exist the values within would specify
'accepted' or 'rejected'.

If a Location header isn't returned immediately, there is no defined way to
get the status - which is why I added the Reply-To header in the original
POST. A later PUT from the server would have the equivalent of a response
with a 'created' status and a Location header. In the example I used "200
success" and it probably should be "201 Created" with a Location header,
even if the URI was returned as a header in the initial Accepted response.








-----------------------------------------------------------------------------------
Post ID:843
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-05 19:50:49
Subject:Re: [rest-discuss] PUT vs. POST
Message:

This is exactly right --- and this is part of what I was talking about a while
back -wrt- the addressibility of resources vs. representations.  You can't ever
address representations directly.  At the same time while resources are
addressible they still remain abstract in some important sense:  sans DAV
semantics, even a PUT on the resource has an indirect and semantically vague
interaction with the underlying object, semantics subject to interpretation and
intermediation by some unspecified and non-addressible layer(s) of software.

I waffle between believing this is a hugely powerful and important (if
underspecified) concept and thinking it's another HTTP "wart."

$0.02,

jb


Paul Prescod wrote:

> "S. Mike Dierken" wrote:
> >
> > ----- Original Message -----
> > From: "Paul Prescod" <paul@...>
> > > But allowing alternate content-type representations is not really
> > > considered a transformation.
> > >
> > Really? Why not? I would think just the opposite - alternate representations
> > are nothing but a transformation of a resource.
>
> I meant that the PUT is not semantically a transformation. It is a
> transformation only in the sense that you transform from the
> representation to the underlying bits that comprise the resource. It
> isn't semantically an HTML to GIF transformation. It's an HTML to
> "graphical object" converter, which happens to generate GIF
> representations if you ask for them.
>
>  Paul Prescod
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:844
Sender:Michael Brennan <michael_brennan@...>
Post Date/Time:2002-03-06 01:17:48
Subject:RE: [rest-discuss] REST in RDF
Message:

> From: Mark Baker [mailto:distobj@...]

<snip/>

> I responded to Paul on xml-dev recently explaining my general
> dissatisfaction with method-granularity interface specs like WIDL,
> WSDL, WRDL, etc...
> 
> Here's my suggestion for a next-gen interface mechanism;
> 
> http://www.markbaker.ca/2002/03/RestRDF/

One other thing I should have mentioned in my previous post: I'm a bit fuzzy
on what is meant by "identity preserving" container resource. Could someone
elaborate, or point me to some discussion that would help me understand what
is meant by this? The other resource types in the taxonomy make sense to me,
but I am fuzzy on this one.






-----------------------------------------------------------------------------------
Post ID:845
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-06 12:36:15
Subject:Re: Idea: Simple Web Service Behaviour Language
Message:

"S. Mike Dierken" <mdierken@h...> wrote:

> Any luck with getting someone to do a pure http binding for the 
Registry and
> Repository services? They seem to /beg/ for a simple URI and http 
access
> mechanism.

ebXML is divided into a bunch of work groups.

I work with the business process groups, not reg-rep, but know the 
leaders of that group. I have raised the argument with them, and have
received some positive responses.  I believe they have decided that 
all repository elements should have URIs.  But I think they still have
UDDI and database systems in mind.  
 
> Maybe we can convince MarkB to do that like he did with some xml-rpc
> interfaces.
> 
> I'll go start a page in the Wiki...

If you and MarkB start a discussion in the Wiki, I will try to corral 
some reg-rep people to engage in discussion.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:846
Sender:Jim Ancona <jim@...>
Post Date/Time:2002-03-06 14:03:47
Subject:Re: [rest-discuss] Re: RESTify a business document exchange app
Message:

--- "S. Mike Dierken" <mdierken@...> wrote:
> If we POST a biz doc and return an 'Accepted' status to indicate that the
> document was transferred but not yet processed,
> I'm not sure about returning a Location header (the http rfc doesn't mention
> it - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3 ).

It seems to imply that the pointer should be in the response entity: "The
entity returned with this response SHOULD include an indication of the
request's current status and either a pointer to a status monitor or some
estimate of when the user can expect the request to be fulfilled."

> The existence of a document might imply business acceptance - which is not
> correct. If the business process defines acknowledgement or status documents
> that have 'accepted', 'rejected' and 'undecided' values, then this would be
> fine I think (retrieving the status document tells you if it was actually
> approved). If the business document set doesn't define 'undecided' values
> then the Location header might need to reference a resource that does not
> yet exist - and when it does exist the values within would specify
> 'accepted' or 'rejected'.

Wouldn't it be legitimate to return "Created" with a Location header in this
case. After all, you did create a resource--the status document you describe
above.

Jim

=====
Jim Ancona
jim@...                     jancona@...

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/






-----------------------------------------------------------------------------------
Post ID:847
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-06 15:11:24
Subject:Re: [rest-discuss] REST in RDF
Message:

See my "abstract model for http resource state" [1] for an explanation.
It's not intended to be a required class for the base taxonomy;
:Resource, :Container, :Replaceable, :Deleteable are the only required
ones.  But :Annotateable, :Processor, and :IdentityPreservingContainer
basically define a sub-taxonomy of Containers.

> One other thing I should have mentioned in my previous post: I'm a bit fuzzy
> on what is meant by "identity preserving" container resource. Could someone
> elaborate, or point me to some discussion that would help me understand what
> is meant by this? The other resource types in the taxonomy make sense to me,
> but I am fuzzy on this one.

 [1] http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:848
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-06 15:50:54
Subject:Re: [rest-discuss] PUT vs. POST
Message:

> > Well, you SHOULD be able to, viz a viz the requirement that the
> > Content-Location header SHOULD be returned when multiple representations
> > exist for the same resource.
> 
> Granted, but they aren't first-class in that they aren't identified by name i.e.
> URI.

Erm, I'm confused.  Because what I said is that representations *are*
normally identified by a URI, because that's exactly what
Content-Location does.

MB 
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:849
Sender:Jim Ancona <jim@...>
Post Date/Time:2002-03-06 16:04:13
Subject:Re: [rest-discuss] Re: RESTify a business document exchange app
Message:

--- Mark Baker <distobj@...> wrote:
> > > The existence of a document might imply business acceptance - which is
> not
> > > correct. If the business process defines acknowledgement or status
> documents
> > > that have 'accepted', 'rejected' and 'undecided' values, then this would
> be
> > > fine I think (retrieving the status document tells you if it was actually
> > > approved). If the business document set doesn't define 'undecided' values
> > > then the Location header might need to reference a resource that does not
> > > yet exist - and when it does exist the values within would specify
> > > 'accepted' or 'rejected'.
> > 
> > Wouldn't it be legitimate to return "Created" with a Location header in
> this
> > case. After all, you did create a resource--the status document you
> describe
> > above.
> 
> Except that then you lose the "Accepted" bit, which is really the most
> important one.

I think I get it now. You're referring to the case where the resource has not
yet been created, but the server knows its URI in advance, correct? Using
Location with Accept in that case makes sense to me, although in the particular
case Mike describes, I can't see why I wouldn't just create an 'undecided'
status resource at the time the business document was received. In that case I
would return Created (with a Location).

Jim

=====
Jim Ancona
jim@...                     jancona@...

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/






-----------------------------------------------------------------------------------
Post ID:850
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-06 16:25:29
Subject:Re: [rest-discuss] Re: RESTify a business document exchange app
Message:

> > Except that then you lose the "Accepted" bit, which is really the most
> > important one.
> 
> I think I get it now. You're referring to the case where the resource has not
> yet been created, but the server knows its URI in advance, correct?

Nope.

On a 202 response, it is suggested that the body could contain a URI
that represented the "future response".  So you could invoke GET on
it and it would say "not yet", "not yet", "I expect a response soon",
and then finally "the recipient got the message".

I'm suggesting bringing this URI out of the body and putting in the
Location header, and defining that the Location header on a 202
response identifies the "future response".

If anybody here ever used CORBA, there was an orb that supported
a feature called a "future", that was basically a place holder for
a response that you could either use a deferred invocation on (DII),
poll yourself, or do a blocking invocation on.  This is basically
the same thing (once you add a router behind the scenes 8-).

> Using
> Location with Accept

s/Accept/Accepted

> in that case makes sense to me, although in the particular
> case Mike describes, I can't see why I wouldn't just create an 'undecided'
> status resource at the time the business document was received. In that case I
> would return Created (with a Location).

Well, as I said before, I think it's more important the "accepted"
nature of the response be reflected in the response status than the
fact that any old resource was created as a side effect.  It's more
specific, and quite meaningful to intermediaries.

In a sense, if 202 did return the "future" in the Location header, then
you could consider that there's an inheritance hierarchy here;

200 <-- 201 <-- 202
    <-- 203
    <-- 204
    <-- 205
    <-- 206

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:851
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-06 16:20:57
Subject:Re: [rest-discuss] PUT vs. POST
Message:


Mark Baker wrote:

> > > Well, you SHOULD be able to, viz a viz the requirement that the
> > > Content-Location header SHOULD be returned when multiple representations
> > > exist for the same resource.
> >
> > Granted, but they aren't first-class in that they aren't identified by name i.e.
> > URI.
>
> Erm, I'm confused.  Because what I said is that representations *are*
> normally identified by a URI, because that's exactly what
> Content-Location does.

Sorry, right, misparse.  Let me see if I can try this again.  Let's say you've got a
resource named

    http://foo.com/some/data/producer

This is a processing container resource, let's say.  It emits representations as a
result of GET operations, and this rep describes the "current" state of the container
--- which changes rapidly.  These representations vary rapidly, so that potentially
each representation emitted in response to a request is in fact different.  Those
representations are not individually addressible --- I seriously doubt that many
architects would advocate giving each unique representation its own URI for use in
Content-Location.  Content-Location is great for coarse-grained / relatively static
use and where it's appropriate, but it doesn't help out in the general case where a
resource has an arbitrary and time-varying number of representations.

But as I said, this isn't really problematic, except in areas like caching and
archiving.  The former is easily dealt with --- resources which emit varying reps
simply manage cache behavior closely or disable it, while in the latter case various
re-write mechanisms (yuck!) generally suffice.  (And generally speaking, you don't
want to be archiving all the reps emitted by a highly variant resource anyway.)

jb








-----------------------------------------------------------------------------------
Post ID:852
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-06 17:01:26
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

----- Original Message ----- 
From: "bhaugen32" <bhaugen32@...>

> 
> > Maybe we can convince MarkB to do that like he did with some xml-rpc
> > interfaces.
> >
> > I'll go start a page in the Wiki...
> 
> If you and MarkB start a discussion in the Wiki, I will try to corral
> some reg-rep people to engage in discussion.
> 

http://conveyor.com/RESTwiki/moin.cgi/RestifyingEBXMLRegistry






-----------------------------------------------------------------------------------
Post ID:853
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-06 17:07:10
Subject:Re: Idea: Simple Web Service Behaviour Language
Message:

"S. Mike Dierken" <mdierken@h...> wrote:

> > If you and MarkB start a discussion in the Wiki, I will try to 
corral
> > some reg-rep people to engage in discussion.
> > 
> 
> http://conveyor.com/RESTwiki/moin.cgi/RestifyingEBXMLRegistry

I read that.  Seems a little tentative.  Are you sure you are ready 
for engagement with people who may be skeptical?  I suggest adding 
some reasons why they would want to do this.  Could be brief, as in 
one-liners with references to other pages that make the argument.  
Then I can have one page to send them to.  Needless to say, I will 
also reference this group, but it's more difficult to follow than the 
Wiki.







-----------------------------------------------------------------------------------
Post ID:854
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-06 17:12:04
Subject:Re: [rest-discuss] Re: RESTify a business document exchange app
Message:

----- Original Message ----- 
From: "Mark Baker" <distobj@...>

> 
> In a sense, if 202 did return the "future" in the Location header, then
> you could consider that there's an inheritance hierarchy here;
> 
> 200 <-- 201 <-- 202
>     <-- 203
>     <-- 204
>     <-- 205
>     <-- 206
> 

For the RFC challenged:

 "OK" <-- "Created" <-- "Accepted"
     <-- "Non-authoritative information"
     <-- "No content"
     <-- "Reset content"
     <-- "Partial content"


 







-----------------------------------------------------------------------------------
Post ID:855
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-06 17:32:16
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

> Any luck with getting someone to do a pure http binding for the Registry and
> Repository services? They seem to /beg/ for a simple URI and http access
> mechanism.
> 
> Maybe we can convince MarkB to do that like he did with some xml-rpc
> interfaces.

I have this thing against registries, unless they're anything more than
a list of URI like dmoz.org.  The Web is so decentralized, that keeping
metadata separate from data is just a maintenance and security nightmare
waiting to happen.

So I can't really see any value in trying to RESTify ebxml.

I also can't see trying to convince a set of companies that plan to make
money off a centralized model, that a decentralized model is the best
way to go.  So I'm not really into evangelizing REST to them either.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:856
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-06 17:28:48
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

Mark Baker wrote:
> 
>...
> 
> I also can't see trying to convince a set of companies that plan to make
> money off a centralized model, that a decentralized model is the best
> way to go.  So I'm not really into evangelizing REST to them either.

I don't really have the time to become an ebxml reg/rep expert but I do
feel that the ebXML world is a natural ally for the REST world because
they seem to be document-centric rather than API and software-centric.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:857
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-06 05:36:35
Subject:Re: [rest-discuss] Re: RESTify a business document exchange app
Message:

----- Original Message -----
From: "bhaugen32" <bhaugen32@...>

>
> > In the sample the status is updated with PUT - but if the server wants
to
> > keep a history, perhaps it should be POST. But I don't want the clients
> > needing to know what the server intends to do. I'd like to expose the
> > resource as the 'current status' - no assumptions about 'extending' an
audit
> > trail - and so I used PUT.  If the server chooses to keep history, then
I
> > suppose a new resource is needed for the audit trail - which would be a
> > collection of previously PUT entities.
>
> The above paragraph seems to imply that you are thinking of something
> different for status than simple ACKs.
The status messages are just advisory and notify the sender of the biz docs
process through the receivers business process.
If the receiver's business process spawns multiple biz docs, then the status
notifications shouldn't be used - since they are only 'advisory'. The new
business docs should be sent to the sender - probably as a POST to the
Reply-To location. I'm using POST here to 'extend' the originating document
with related material. The Reply-To in the example says '.../ack' so maybe
something isn't quite right.

>
> Are you thinking of Delivery and Payment as statuses?  If so, I got
> an argument for you...
>
Um, not sure what a 'status' is - but my notification would be advisory and
real biz docs would deserve real URI based exchange.









-----------------------------------------------------------------------------------
Post ID:858
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-06 17:48:29
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

Mark Baker wrote:
> 
>...
> 
> Well, there's definitely conflicting goals there.  It would not have
> been hard for them to decentralize without using REST, but they chose
> not to.  So I think that there's forces at work there.

Centralization can improve information longevity. For instance when you
try to find a Java or Python library you often get a 404 but with Perl,
once they are in CPAN, they are in CPAN and they never go away.
Similarly consider the centralization of internet RFCs compared to
random web pages on people's sites.

The best of all possible worlds is for the centralized service to be a
unified mirror of information that is otherwise available in a
decentralized manner.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:859
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-06 18:02:05
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:


> >
> > http://conveyor.com/RESTwiki/moin.cgi/RestifyingEBXMLRegistry
>
> I read that.  Seems a little tentative.  Are you sure you are ready
> for engagement with people who may be skeptical?  I suggest adding
> some reasons why they would want to do this.  Could be brief, as in
> one-liners with references to other pages that make the argument.
> Then I can have one page to send them to.  Needless to say, I will
> also reference this group, but it's more difficult to follow than the
> Wiki.

No - this isn't ready. It's only a place to start. I wanted to work out the
actual REST details before showing it to actual ebXML working group members.
Also, there would need to be a focused 'why rest is good' introduction that
relates it to ebXML reg/rep.

Mike






-----------------------------------------------------------------------------------
Post ID:860
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-06 18:18:17
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

> The best of all possible worlds is for the centralized service to be a
> unified mirror of information that is otherwise available in a
> decentralized manner.

Agreed.  My centralized/decentralized comment related only to the
centralization of metadata.

i.e. if I was told that http://www.yahoo.com identified Yahoo,
but that I had to go to a UDDI registry at IBM to get
information about it, I'd be peeved, especially when I can
just do GET to get that info.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:861
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-06 18:58:41
Subject:Re: Idea: Simple Web Service Behaviour Language
Message:

Paul Prescod <paul@p...> wrote:
> Mark Baker wrote:
> > 
> >...
> > 
> > I also can't see trying to convince a set of companies that plan 
to make
> > money off a centralized model, that a decentralized model is the 
best
> > way to go.  So I'm not really into evangelizing REST to them 
either.
> 
> I don't really have the time to become an ebxml reg/rep expert but 
I do
> feel that the ebXML world is a natural ally for the REST world 
because
> they seem to be document-centric rather than API and software-
centric.

Mark, I don't understand why you are dismissing ebXML either. 
Especially since I'm here and eager to learn. Yes there are big 
companies trying to make money off fat central services. But ebXML 
has a lot of components and many of them are peer-to-peer.  And there 
are also several people including me who are going through the ebXML 
stage of development in order to come out on the other side with 
something much simpler.  Some of those people went thru the eCo 
framework before, which was very RESTful, and think ebXML went astray 
in RegRep.  

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:862
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-06 20:05:04
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

> Mark, I don't understand why you are dismissing ebXML either. 

It's not an entire dismissal, I'm just not prioritizing it very
highly, especially when there's a lot more non-political battles
to be fought.

> Especially since I'm here and eager to learn. Yes there are big 
> companies trying to make money off fat central services. But ebXML 
> has a lot of components and many of them are peer-to-peer.  And there 
> are also several people including me who are going through the ebXML 
> stage of development in order to come out on the other side with 
> something much simpler.  Some of those people went thru the eCo 
> framework before, which was very RESTful, and think ebXML went astray 
> in RegRep.  

I've heard people say that eCo appears quite RESTful, but I haven't
seen that in the look I've had at it.

Anyhow, I will of course help anybody who asks to know more, including
yourself and any of your peers.  I'm just not going to take it upon
myself to try and give them religion.  Please don't take that as a
snubbing; as I said, there's only so many hours in a day.

(btw, bhaugen32@... appears to be rejecting emails with
"unknown user")

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:863
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-06 22:35:31
Subject:Mapping SQL operations to HTTP methods
Message:

Dan Connolly and I just had a quick exchange via IRC about how you'd
map SQL operations to HTTP methods;

http://ilrt.org/discovery/chatlogs/rdfig/2002-03-06.html#T18-09-55

An interesting issue is, what does SQL "update" map to?

Some updates seem to clearly be POST (using Dan's example);

 "update employee set salary = salary * 1.03 where performanceEval>4"

but what about this;

 "set salary = 40000 where level=4"

Now, the issue is, I think, if we have a URI representing "all salaries
for level 4 employees", then this is a set, i.e. a container.  My
interpretation of REST suggests that in order to PUT to a container,
you have to replace the entire state of the container.  So saying
"PUT <40000>" to that URI is a mismatch.  It should be "PUT <40000,
40000,40000,40000 ...>".

This is a real brain teaser.  Clearly you can do it all over POST,
by just posting the SQL statement (minus the where clause, since
that should be in the URI), but would that be considered tunneling?

I'm stumped, for now.  Anybody else got any ideas?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:864
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-06 22:29:21
Subject:Opacity Reconsidered
Message:

I've been thinking a lot about names, identifiers, and opacity over the
last couple of months, and wondering why we stringently insist on opaque
identifiers on the Web while, completely counter to this, the trend in
filesystem research has been to *increase* the semantic richness of
names.  I've tried to synthesize a cogent treatment of this thought and
investigation;  the result of this is a (rather lengthy) write-up I've
made available on the RestWiki.  Comments appreciated, this is a first
draft:

    http://conveyor.com/RESTwiki/moin.cgi/OpacityReconsidered

jb








-----------------------------------------------------------------------------------
Post ID:865
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-06 22:49:04
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Short answer; because you want as much meaning as possible to be
explicit, not implicit.  Every piece of meaning that is implicit
about a URI (if it were not opaque) is information that can not be
easily used for automation by a machine.

Practically though, as long as there is a fixed amount of non-opaque
information that never ever grows, you're ok because understanding it
can be hardcoded in.  But if you want to add stuff over time, then each
time you do all the existing agents out there trying to automate stuff,
will need upgrading.

Best to keep the URI opaque, and build the meaning up on the Semantic
Web.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:866
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-06 22:58:12
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

I don't think that the opacity axiom was ever intended to be at odds
with guessability and readability. I've never seen Tim B-L, Fielding,
etc. propose that random numbers would be better than human readable
strings.

As far as Construcability, you say:

"A listing of /proc would reveal a set of directories represented
processes, each named by the PID of the process they are associated
with."

That's just the point!!! Given /proc, a computer program should navigate
to processes by looking at the *listing* (the entity body) rather than
guessing PIDs! That's using "hypertext (links) as the engine of
application state".

You say:

"Reading the n/status file yields the current status of the process,
while writing to n/ctl would send a message to the process, etc."

On the web, we would use strongly typed hyperlinks so that the name
"status" or "mem" would be irrelevant:

<status href="status"/>
<mem href="mem"/>

And here's where the power comes in...

<status href="http://www.some.other.site.com/status"/>

In a file system you could do that with a symlink. Symlinks (redirects)
are a pain to maintain and computational expensive on the Web so it
makes more sense to use strongly typed links.

Opacity is freedom. Renounce your heresy!

"Web archiving is one example where computability of URI is useful and
important." Well that's what query parameters are for. There is an
exception to URI opacity in the web architecture already. 

So I'm sorry but I don't see much to reconsider in opacity. URIs should
be human readable and guessable. Yes, but that isn't in conflict with
the opacity principle. URIs should sometimes be constructable from a
base and parameters (though probably not deconstructable). Yes, but that
isn't in conflict with the opacity principle. I still think it is a big
mistake for *programs* to either deconstruct or guess URIs.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:867
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-06 03:35:57
Subject:Re: [rest-discuss] REST in RDF
Message:

> I'm curious how one would model workflow with something like this.
> Traditional OO often uses state machines as part of modelling such a
> solution, whereas (based on comments I've heard here, on the REST wiki, and
> on xml-dev) REST encourages the use of resources to model steps in a
> workflow. Presumably, where necessary, one would use transient resources
> that expire when the workflow is complete, or a step in the workflow that
> invalidates this resource is taken. Would it make sense to have an archetype
> in the taxonomy for such resources?

Excellent question.  Yes, I believe so.  It would be quite simple too,
basically;

:Process rdfs:subClassOf :Container

I just posted an XML based example of a workflow[1].  It could easily
be RDF-ized, and use this class.

I'm going over DAML-S[2] right now, checking to see how it might relate
to what I've done.

 [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0048.html
 [2] http://www.daml.org/services/daml-s/2001/10/

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:868
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-06 23:09:52
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Mark Baker wrote:

> Short answer; because you want as much meaning as possible to be
> explicit, not implicit.  Every piece of meaning that is implicit
> about a URI (if it were not opaque) is information that can not be
> easily used for automation by a machine.

Sorry, that's just not true, though it's a common argument for opacity.  As
I point out in the write-up,UNIX has a long and profitable history of using
synthetic filenames constructed according to particular, explicitly
documented conventions to do just that, i.e. automate certain things.
Consider construction of names for things in /dev;  consider the fact that
ps on many modern UNIXes is a shell script that operates by constructing
names and accessing files according to a particular set of conventions on
/proc.  What's more, opacity by itself doesn't guarantee automation any
more than non-opacity breaks it.

> Practically though, as long as there is a fixed amount of non-opaque
> information that never ever grows, you're ok because understanding it
> can be hardcoded in.  But if you want to add stuff over time, then each
> time you do all the existing agents out there trying to automate stuff,
> will need upgrading.

This isn't true, either --- unless you assume that the grammars and
semantics of these names aren't made explicit.  The whole process can be
fully automated by providing a generative grammar for names and some
semantic description for said names.  Granted that you want to make
everything as explicit as possible.  But our focus on using markup to
encode all of this stuff is somewhat historical and cultural.  Upon further
reflection and investigation, it's not at all clear that this is preferable
to using generative grammars for construction of names in semantically-rich
namespaces.

> Best to keep the URI opaque, and build the meaning up on the Semantic
> Web.

Yes, that's the dogma.  But looking at the relative complexity of, say, the
implementation of the PS shell script on a UNIX box with /proc and the
implementation of  something to grok Semantic Web stuff has me wondering.
Perhaps giant stringy webs of RDF aren't the easiest, most useful, or best
ways to get to some of the same functionality.

jb








-----------------------------------------------------------------------------------
Post ID:869
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-06 23:22:34
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Jeff Bone wrote:
> 
>...
> 
> Sorry, that's just not true, though it's a common argument for opacity.  As
> I point out in the write-up,UNIX has a long and profitable history of using
> synthetic filenames constructed according to particular, explicitly
> documented conventions to do just that, i.e. automate certain things.

You also point out in the article that it doesn't always work. I've
added a comment to expand on that to the Wiki.

> Consider construction of names for things in /dev;  consider the fact that
> ps on many modern UNIXes is a shell script that operates by constructing
> names and accessing files according to a particular set of conventions on
> /proc.  What's more, opacity by itself doesn't guarantee automation any
> more than non-opacity breaks it.

A shell script does something like: print /proc/$pid/status

A web script (e.g. XSLT) would do something like "print
traverse($pid/status)" The difference is that in the former status is a
file name. In the latter it is an element type name. When we have an RDF
equivalent to shell scripts and xpaths it will be similarly clear using
RDF.

>...
> This isn't true, either --- unless you assume that the grammars and
> semantics of these names aren't made explicit.  The whole process can be
> fully automated by providing a generative grammar for names and some
> semantic description for said names.  

Why invent something extra when markup works?!?!

> ... Granted that you want to make
> everything as explicit as possible.  But our focus on using markup to
> encode all of this stuff is somewhat historical and cultural.  Upon further
> reflection and investigation, it's not at all clear that this is preferable
> to using generative grammars for construction of names in semantically-rich
> namespaces.

Yes it is. The virtue of markup is that it embeds hyperlinks that can go
*anywhere on the web*. Hierarchical names are necessarily hosted from
the same machine (or at least there must be a redirect on the same
machine). That's why the web is different than a file system. (I added
this point to the Wiki also)

> > Best to keep the URI opaque, and build the meaning up on the Semantic
> > Web.
> 
> Yes, that's the dogma.  But looking at the relative complexity of, say, the
> implementation of the PS shell script on a UNIX box with /proc and the
> implementation of  something to grok Semantic Web stuff has me wondering.
> Perhaps giant stringy webs of RDF aren't the easiest, most useful, or best
> ways to get to some of the same functionality.

I think you're reverting to something you're comfortable with. If you
use XPath or an RDF query language you can get the same benefits without
the inflexibility of centralization.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:870
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-06 23:29:20
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Let me try another strategy. Let's say you want to move a resource. On
Unix, you use a symlink, but you are restricted to file systems that
have been mounted. In a standard OS address space you need to account
for the indirection in advance and you can only redirect to objects in
the same address space. On the Web, you can account for the indirection
in advance by indirecting *through markup* and you can redirect to any
resource anywhere. You can also account for redirection after the fact
using HTTP status codes but this is quite inefficient and will probably
break some client software.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:871
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-06 23:31:24
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:


Paul Prescod wrote:

> Opacity is freedom. Renounce your heresy!

Now see, this is what I'm talking about re: dogma.  I seriously doubt you and
Mark have bothered to carefully read through that monster before starting in
with the indoctrination.  Don't bother, I'm indoctrinated, but I'm
questioning some of the basic precepts;  I'm down with most of this stuff, I
just don't buy the fish-on-Friday argument --- and I've documented why!
Perhaps you could be bothered to read it first so that I don't have to
re-address questions or comments here that are already dealt with in the
document?  Then we could discuss the specific and useful points rather than
simply writing off the whole endeavor as dogmatically inappropriate?

;-)

> "Web archiving is one example where computability of URI is useful and
> important." Well that's what query parameters are for. There is an
> exception to URI opacity in the web architecture already.

But this is problematic!  I *should* be able to e.g. use my caching proxy to
cache /archive/2001/09/11 or whatever!  Shoving things into the query string
isn't a good answer, each of those objects should be reified as a resource
and addressible via URI.  THAT's what REST is about, IMO:  making everything
interesting referenceable.

> So I'm sorry but I don't see much to reconsider in opacity. URIs should
> be human readable and guessable. Yes, but that isn't in conflict with
> the opacity principle.

It depends on how stringently you apply it.  There's very little guidance.
TBL seems to have some informal notions of what makes "good" vs. "bad" URI,
but that's far from normative.

> URIs should sometimes be constructable from a
> base and parameters (though probably not deconstructable). Yes, but that
> isn't in conflict with the opacity principle.

Again, it depends on how stringently you apply the principle.  It's a
widely-misunderstood principle, I think, even potentially misunderstood by
its author.  It's good to have a "principled" design and architecture for the
Web, but those principles should be meaningful.  In this case, I think the
principle was derived in an ad-hoc fashion by some specific failures (i.e.,
content types from extensions) early on, and is overly general.

> I still think it is a big
> mistake for *programs* to either deconstruct or guess URIs.

Why?  If I provided you with (RDF, whatever) that formally defined the
structure of names on my site and your code could deduce from that /
automatically generate meaningful names, why is this a bad thing?

Enough dogma.  Check your premises! ;-)

Bottom line:  the Web insists on opacity --- there are no names, only
identifiers.  Everywhere else that syntactically similar entities are used,
the trend has been to increase rather than decrease the semantic richness of
the namespace.  Why the discrepancy?  Smart people exist in both
communities;  a reasonable person looks at this discrepancy and attempts to
understand what's going on here.

jb









-----------------------------------------------------------------------------------
Post ID:872
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-06 23:49:27
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> > Opacity is freedom. Renounce your heresy!
> 
> Now see, this is what I'm talking about re: dogma.  I seriously doubt you and
> Mark have bothered to carefully read through that monster before starting in
> with the indoctrination.  

I did read it. I've even gone through and added my comments inline. I'm
happy to have sacred cow barbeque but I think the web architecture
already anticipates all of your concerns.

>...
> > "Web archiving is one example where computability of URI is useful and
> > important." Well that's what query parameters are for. There is an
> > exception to URI opacity in the web architecture already.
> 
> But this is problematic!  I *should* be able to e.g. use my caching proxy to
> cache /archive/2001/09/11 or whatever!  

Er, who said you can't cache things in query strings?

> .. Shoving things into the query string
> isn't a good answer, each of those objects should be reified as a resource
> and addressible via URI.  

The query string *generates* a URI. I'm totally not following you.
Here's a URI that is both cacheable and addressable using query strings:

http://www.google.com/search?hl=en&q=everything+old+is+new+REST

>...
> It depends on how stringently you apply it.  There's very little guidance.
> TBL seems to have some informal notions of what makes "good" vs. "bad" URI,
> but that's far from normative.

Okay, but its a user interface issue, NOT a software architecture issue.
I strongly encourage you to write a web page about good URI naming
conventions. But I also encourage you to separate it from the heresy
about /proc. ;)

> > URIs should sometimes be constructable from a
> > base and parameters (though probably not deconstructable). Yes, but that
> > isn't in conflict with the opacity principle.
> 
> Again, it depends on how stringently you apply the principle.  

The page where the principle is described also describes its appropriate
limits: 

"Query strings are clearly not opaque to the client. However, they
should be opaque to (for example) proxies."

>...
> Why?  If I provided you with (RDF, whatever) that formally defined the
> structure of names on my site and your code could deduce from that /
> automatically generate meaningful names, why is this a bad thing?

#1. Because of the redirection problem.

#2. Because now you have two ways to do the same thing: using hyperlinks
and using semantic URIs. What benefit does the latter provide?

#3. Because now you are restricted in your naming conventions so that it
becomes difficult to make names in French and German that are
functionally equivalent to the english names. Does Red Flag linux handle
the Chinese word for /proc and /proc/pid/status? If so, what happens to
your ps script. If not, then you've sacrificed guessability.

>...
> Bottom line:  the Web insists on opacity --- there are no names, only
> identifiers.  Everywhere else that syntactically similar entities are used,
> the trend has been to increase rather than decrease the semantic richness of
> the namespace.  Why the discrepancy?  Smart people exist in both
> communities;  a reasonable person looks at this discrepancy and attempts to
> understand what's going on here.

#1. The web people have this problem where the "file system" is global
and they want any link to be able to point at any server.

#2. The price of double or triple or quadruple dereferencing a file name
is cheap compared to the price of parsing markup in a file system.
Whereas the price of parsing markup is trivial on the web compared to
the price of following one redirect to another redirect to another
redirect etc. Better to plan for the need to move things in advance by
"indirecting" through markup.

#3. The web people just dig markup more.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:873
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-06 23:53:43
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:


Paul Prescod wrote:

> >...
> > This isn't true, either --- unless you assume that the grammars and
> > semantics of these names aren't made explicit.  The whole process can be
> > fully automated by providing a generative grammar for names and some
> > semantic description for said names.
>
> Why invent something extra when markup works?!?!

You're not.  You're defining grammatical conventions on already-existing names in
the same manner that you specify other sorts of things in markup.  It's not an
either-or, it's a both-and.  There are things that the name-based mechanism
allows which can't be done via markup topology...  consider a Web crawler that
simply wants to crawl across every available page on my site --- *including the
one which isn't linked to by any other page.*  Name-based conventions *may* allow
you to find that object.  With markup topology, you'll never find it.

Hey, that's a subtle but good point, IMHO. ;-)  There's something deep lurking
there.

> Hierarchical names are necessarily hosted from
> the same machine (or at least there must be a redirect on the same
> machine). That's why the web is different than a file system. (I added
> this point to the Wiki also)

This is baloney, too --- but again a commonly offered argument.  There's
absolutely nothing that says that distributed filesystems cannot be multi-rooted
and have global names.  Indeed, in a stunning demonstration of the ToII, the SMB
/ CIFS filesystem's names (UNC names) and URIs look so much alike that *a trivial
encoding of UNC names as URI is possible just by replacing '\' with '/'.

> I think you're reverting to something you're comfortable with.

Possibly.  Or perhaps its the lack of familiarity on the part of others of
current filesystem research and their relatively greater comfort level with
markup technologies that causes them to (a) see nonexistent limitations and
problems with semantically-rich naming schemes and (b) seek to compensate for
this with markup technologies.  Which is it?  I don't know, that's what I'm
trying to find out.  I've floated back and forth between these two communities
for a long time, and I prima facie the Opacity Principle seems just as silly to
me as the filesystem guys' perpetual insistence on block-level IO and caching.

My investigation of these issues is driven by familiarity with the work of
Michael McClennen, Stu Sechrest, Hans Reiser, Bal Krishnamurthy, the Plan 9 guys,
and others who have at various times in the past decade worked on enriching the
semantics of file naming.  If you're arguing that the whole endeavor is
worthless, you're indirectly arguing with some very smart guys.  Indeed, you're
telling Rob Pike, Dave Presotta, Ken Trickey, and some other very smart guys that
they've wasted most of their careers.  If, on the other hand, you criticize the
Opacity Principle, you're just telling Tim that he might have overstated a
particular point and telling the rest of us to lighten up and think about how we
interpret those axioms.


Again my question:  why the polar opinion about semantics in names?


jb








-----------------------------------------------------------------------------------
Post ID:874
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-06 23:59:40
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:


Paul Prescod wrote:

> Let me try another strategy. Let's say you want to move a resource.

This indicates a limited view of filesystems.  In a hypothetical semantic
filesystem, the operation is conceptually similar operation to what you do on
the Web.  With rich names, names are queries.  "Moving" a file isn't
necessarily a valid concept in current filesystem research;  rather, you
annotate or fiddle with the properties of a file such that the pathname
(query) that is used to access it is different.

> On
> Unix, you use a symlink, but you are restricted to file systems that
> have been mounted.

Not necessarily.  Various research systems have proposed symbolic links that
can be remote and are resolved only at access time.

> In a standard OS address space you need to account
> for the indirection in advance and you can only redirect to objects in
> the same address space.

Again, there are distributed filesystems with global, multi-rooted
namespaces.

> On the Web, you can account for the indirection
> in advance by indirecting *through markup*

And again, this is preferable...  why?  As opposed, say, to direct
manipulation of properties and metadata?  And how, really, is that different,
anyway?

> and you can redirect to any
> resource anywhere. You can also account for redirection after the fact
> using HTTP status codes but this is quite inefficient and will probably
> break some client software.

None of this is novel.

jb


>
>
>  Paul Prescod
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:875
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 00:02:29
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:


Paul Prescod wrote:

> #1. The web people have this problem where the "file system" is global
> and they want any link to be able to point at any server.

This is not unique to the Web.

> #2. The price of double or triple or quadruple dereferencing a file name
> is cheap compared to the price of parsing markup in a file system.
> Whereas the price of parsing markup is trivial on the web compared to
> the price of following one redirect to another redirect to another
> redirect etc. Better to plan for the need to move things in advance by
> "indirecting" through markup.

This I buy.

> #3. The web people just dig markup more.

That's not good enough. ;-)

jb








-----------------------------------------------------------------------------------
Post ID:876
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-07 00:11:25
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Jeff Bone wrote:
> 
>...
> 
> You're not.  You're defining grammatical conventions on already-existing names in
> the same manner that you specify other sorts of things in markup.  It's not an
> either-or, it's a both-and.  There are things that the name-based mechanism
> allows which can't be done via markup topology...  consider a Web crawler that
> simply wants to crawl across every available page on my site --- *including the
> one which isn't linked to by any other page.*  

Geez, just link it! Use a <link> tag in HTML if you want something
simple.

> ... Name-based conventions *may* allow
> you to find that object.  With markup topology, you'll never find it.

Setting up the conventions in a machine readable form will be more work
than setting up the link.

>...
> > Hierarchical names are necessarily hosted from
> > the same machine (or at least there must be a redirect on the same
> > machine). That's why the web is different than a file system. (I added
> > this point to the Wiki also)
> 
> This is baloney, too --- but again a commonly offered argument.  There's
> absolutely nothing that says that distributed filesystems cannot be multi-rooted
> and have global names.  Indeed, in a stunning demonstration of the ToII, the SMB
> / CIFS filesystem's names (UNC names) and URIs look so much alike that *a trivial
> encoding of UNC names as URI is possible just by replacing '\' with '/'.


You say its baloney but you haven't shown me how I can serve
http://www.myprocesses.com/proc/5323/status from
http://www.yourprocesses.com. I'd have to set up an HTTP redirect which
is expensive both from a maintenance and a performance point of view.
It's cheap in a standard file system.

>...
> Possibly.  Or perhaps its the lack of familiarity on the part of others of
> current filesystem research and their relatively greater comfort level with
> markup technologies that causes them to (a) see nonexistent limitations and
> problems with semantically-rich naming schemes and (b) seek to compensate for
> this with markup technologies.  Which is it?  I don't know, that's what I'm
> trying to find out.  I've floated back and forth between these two communities
> for a long time, and I prima facie the Opacity Principle seems just as silly to
> me as the filesystem guys' perpetual insistence on block-level IO and caching.

Different scale problems have different performance characteristics. If
file system guys tell me that block-level IO is required to get the
performance they need then I'll believe them until I have reason to
believe otherwise.

> My investigation of these issues is driven by familiarity with the work of
> Michael McClennen, Stu Sechrest, Hans Reiser, Bal Krishnamurthy, the Plan 9 guys,
> and others who have at various times in the past decade worked on enriching the
> semantics of file naming.  If you're arguing that the whole endeavor is
> worthless, you're indirectly arguing with some very smart guys.  Indeed, you're
> telling Rob Pike, Dave Presotta, Ken Trickey, and some other very smart guys that
> they've wasted most of their careers.  

One way of looking at it is that the file system has different
requirements, especially when it comes to performance and user
interface. Note that the file system names are a primary user interface
to information navigation, even on GUI-centric platforms. URIs are at
best a secondary or tertiary user interface compared to markup and
browser controls.

Another way of looking at it is that the semantic web could make a lot
of that work obsolete if people started navigating by something other
than names. Whoa! Surfing the web in rdfsh or xpathsh...there's an
interesting idea.

> ... If, on the other hand, you criticize the
> Opacity Principle, you're just telling Tim that he might have overstated a
> particular point and telling the rest of us to lighten up and think about how we
> interpret those axioms.

The opacity principle is important precisely because URIs are so human
readable and people feel that when they model URIs they are modeling the
application. But when they do that they generally aren't taking into
account the indirection and discoverability issues.

Yes, we could build a parallel system that makes names more discoverable
and we could use HTTP redirects for indirection. But *to what end*? I
think you'll reduce the human readability of URIs if you start turning
them into code objects deconstructed by programs. IMO, the opacity
principle works well both in practice and in theory.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:877
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-07 00:22:53
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> > #1. The web people have this problem where the "file system" is global
> > and they want any link to be able to point at any server.
> 
> This is not unique to the Web.

It isn't unique to the Web but it is the fundamental organizational
principle of the Web. File systems tend to think first about local data
and then about making remote data look like local data. 

> > #2. The price of double or triple or quadruple dereferencing a file name
> > is cheap compared to the price of parsing markup in a file system.
> > Whereas the price of parsing markup is trivial on the web compared to
> > the price of following one redirect to another redirect to another
> > redirect etc. Better to plan for the need to move things in advance by
> > "indirecting" through markup.
> 
> This I buy.

Great. Then we agree. ;)


> This indicates a limited view of filesystems.  In a hypothetical semantic
> filesystem, the operation is conceptually similar operation to what you do on
> the Web.  With rich names, names are queries.  "Moving" a file isn't
> necessarily a valid concept in current filesystem research;  rather, you
> annotate or fiddle with the properties of a file such that the pathname
> (query) that is used to access it is different.

Fiddling the markup is like fiddling the metadata for the file. Given
the pseudo-resource

http://www.foo.com/processes#xptr(/status/@href)

I "move" the pseudo-resource by changing the value of the href
attribute. I use the term pseudo-resource, not resource, because the
actual resource identified by the link changes when I update the href.

Anyhow, at the URI (not markup) level, the web is not a query-centric
system it is an address-centric system. We find things first and
foremost through a domain name and an associated IP address. A decent
distributed file system would rather not expose the machine name or IP
address for files. So URIs should be viewed as more like the
book-keeping identifier that the file system uses (inode) and less like
the file name.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:878
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-06 15:10:13
Subject:Re: [rest-discuss] PUT vs. POST
Message:


Mark Baker wrote:

> > This is exactly right --- and this is part of what I was talking about a while
> > back -wrt- the addressibility of resources vs. representations.  You can't ever
> > address representations directly.
>
> Well, you SHOULD be able to, viz a viz the requirement that the
> Content-Location header SHOULD be returned when multiple representations
> exist for the same resource.

Granted, but they aren't first-class in that they aren't identified by name i.e.
URI.  (Generally speaking this isn't a problem, but it makes certain things more
difficult in caching and archiving.  Like many things in the Web, it's one of those
things with some small disadvantage but from which a lot of benefit comes.)

jb








-----------------------------------------------------------------------------------
Post ID:879
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-07 01:35:11
Subject:Re: [rest-discuss] Mapping SQL operations to HTTP methods
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>

>
> but what about this;
>
>  "set salary = 40000 where level=4"
>
> Now, the issue is, I think, if we have a URI representing "all salaries
> for level 4 employees", then this is a set, i.e. a container.  My
> interpretation of REST suggests that in order to PUT to a container,
> you have to replace the entire state of the container.  So saying
> "PUT <40000>" to that URI is a mismatch.  It should be "PUT <40000,
> 40000,40000,40000 ...>".
>

I don't see a requirement that the 'new' state of a collection have the same
number of application specific records. The collection can be malleable in
that it can take a single value and apply it to many managed items - which
is exactly what that SQL statement does. It doesn't nuke the records, it
updates the values from a single input value. The input value to the SQL
statement is not a temp table to be copied - it is a 'representation' not a
'resource'. Of course if PUT requires a 'resource' as input, then you're
hosed.

If the collection is defined to be a 'view' (as I think DanC said in the IRC
log) the reading and writing don't have to be one-to-one. Of course,
write-back is a bitch for any one-to-many or many-to-one mapping. (as RoyF
will find out at his new day job)










-----------------------------------------------------------------------------------
Post ID:880
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 01:45:17
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:


Jeff Bone wrote:

> Paul Prescod wrote:
>
> > #2. The price of double or triple or quadruple dereferencing a file name
> > is cheap compared to the price of parsing markup in a file system.
> > Whereas the price of parsing markup is trivial on the web compared to
> > the price of following one redirect to another redirect to another
> > redirect etc. Better to plan for the need to move things in advance by
> > "indirecting" through markup.
>
> This I buy.

Actually, on second thought, I don't buy this argument --- at least not as an
argument about opacity.  Both the Web and certain modern distributed
filesystems can handle movement of resources to nonlocal environments through
redirection;  the 3xx HTTP codes have analogs in SMB, in NFS+autofs
environments, and elsewhere.  The ability to redirect through markup is unique
to the Web, but it is a decidedly *unRESTful* and HTTP-unfriendly concept.
Consider:

One of the original goals of the Web was to be generally agnostic about the
content that it transported.  We've moved away from that, and that's perhaps a
bad thing.  Where the abstractions-of-interest in REST / HTTP are resources
and their associated coordination language, the abstractions-of-interest in
the Semantic Web are hypertext topologies and metadata.  Whereas the REST
purist way to handle relocation of resources is (correctly, IMO) through the
3xx codes, a markup-based mechanism requires that any client understand the
markup language and redirect conventions.

Anyway, this is another red herring --- neither an argument for opacity nor an
advantage of the Web over other distributed filesystems.  The point of this
endeavor isn't to claim that distributed filesystems are in some sense
superior to the Web or what have you;  it's rather to debug some incorrect
assumptions and assertions that are generally made in support of opacity.

$0.02,

jb








-----------------------------------------------------------------------------------
Post ID:881
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-07 02:03:48
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Maybe the easiest way to drill down on this is for my to challenge your
assertion that it's a good idea for sites to agree on what /search,
/help, and /contact mean.

Clearly it would be a good idea for lots of different types of web
sites to have a common notion of "search", "help", and "contact".  That
way, an agent could locate do things like summarize all the contacts for
me, and correlate that with their postings to alt.sex.  But the issue
is, what's the best way to do this?

One obvious way, which you seem to suggest, is for everybody to share
the same relative name for it.  The major problem with this though, is
that a software agent wouldn't know whether a web site was following
these rules, or if they just happened to have a page named /contact.
It is absolutely key that names not be standardized, because it means
that there has to be some central authority that ensures that names
don't conflict.  After 20 years of people doing this, you literally
would have to check with somebody to ensure that it's ok for you to
publish /foo/bar/baz, lest somebody else has already defined what that
means.

The opacity-friendly way of doing this would be to assert a relationship
between the main site and the URI it uses for the concepts of "contact",
"help", and "search".  For example, a GET on http://foo.com could
return some N3 asserting;

@prefix chs: <http://jbone.net/contact-help-search>
</admin/help/> a chs:Help .
</search/> a chs:Search .
</contact-us/> a chs:Contact .

Ah yes, the sweet smell of decentralization ...

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:882
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-06 16:30:57
Subject:Re: RESTify a business document exchange app
Message:

Mark Baker <distobj@a...> wrote:
> s/Accept/Accepted

Is that a counter-proposal to Mike Dierken's proposal of a Response 
location where the "Accepted" bits would be part of the response?

If so, how would you handle the very common case where there are 
three possible responses:  Accepted, Rejected, or CounterPending. The 
third meaning that we're still negotiating the deal.

(I'm not arguing for or against any proposal here, just trying to 
understand.)

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:883
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 02:09:08
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:


Paul Prescod wrote:

> You say its baloney but you haven't shown me how I can serve
> http://www.myprocesses.com/proc/5323/status from
> http://www.yourprocesses.com. I'd have to set up an HTTP redirect which
> is expensive both from a maintenance and a performance point of view.
> It's cheap in a standard file system.

Sorry, let me clarify.  The point isn't that your claimed limitation does not exist ---
it does --- but rather that the same problem and essentially the same solution exists
on the Web and in several common distributed environments.  The claim that the problem
(or solution) is unique to the Web is the fallacious part.

> > Possibly.  Or perhaps its the lack of familiarity on the part of others of
> > current filesystem research and their relatively greater comfort level with
> > markup technologies that causes them to (a) see nonexistent limitations and
> > problems with semantically-rich naming schemes and (b) seek to compensate for
> > this with markup technologies.  Which is it?  I don't know, that's what I'm
> > trying to find out.  I've floated back and forth between these two communities
> > for a long time, and I prima facie the Opacity Principle seems just as silly to
> > me as the filesystem guys' perpetual insistence on block-level IO and caching.
>
> Different scale problems have different performance characteristics. If
> file system guys tell me that block-level IO is required to get the
> performance they need then I'll believe them until I have reason to
> believe otherwise.

I've been living in that world for the last year or so, and one of the things that's
frustrated me has been this very thing.  One of the best-performing filesystems around
in the last decade or so was derived from Andy Tannenbaum's Bullet File System --- and
it was very RESTlike in some ways.  Whole objects were operated on and semantic naming
was separated from and dynamically mapped to identifiers for immutable stored objects.
Unf., this is "too weird" for most filesystem guys, despite all sorts of compelling,
quantitative data to the contrary.

> One way of looking at it is that the file system has different
> requirements, especially when it comes to performance and user
> interface.

With respect to the former, a *wide area* filesystem (such as the Web and various
others) has different performance characteristics than a local filesystem, a clustered
filesystem, etc.  If you really think there are significant differences, come up with
some of these different requirements and I'll come up with pointers to distributed
filesystem research which specifically address them.  Otherwise, the "oh, it's just a
different problem domain" argument is just FUD.

> Note that the file system names are a primary user interface
> to information navigation, even on GUI-centric platforms. URIs are at
> best a secondary or tertiary user interface compared to markup and
> browser controls.

I don't buy this one, either.  I hear this "GUI" orientation alot, especially from the
hypertext enthusiasts.  The Web is a hypertext medium, but it shouldn't be a hypertext
medium *at the expense of being a universal information space and coordination
language.*

> Another way of looking at it is that the semantic web could make a lot
> of that work obsolete if people started navigating by something other
> than names. Whoa! Surfing the web in rdfsh or xpathsh...there's an
> interesting idea.

I've been hoping for something along those lines for a while.  For the life of me,
though, I have a hard time finding simple syntaxes for interactive use of Web resources
themselves, much less navigating around complex graph topologies.  (And yeah, XPath
*is* nice.  It's necessary, but not sufficient.)

> The opacity principle is important precisely because URIs are so human
> readable and people feel that when they model URIs they are modeling the
> application.

Well, I don't think I believe that.  Look at all the yucky, unfriendly URI out there.
That happens precisely because people *don't* model their URI well enough, and many
I've talked to use "opacity" as an excuse.

> Yes, we could build a parallel system that makes names more discoverable
> and we could use HTTP redirects for indirection.

(a) We already use HTTP for redirects, and when we don't we introduce unpleasant
dependencies between clients and particular markups.  (b) I'm not suggesting a parallel
system, any more than WRDL is a parallel system to RDF.  Like the latter, what I am
suggesting is a specific tool for a specific purpose.

> But *to what end*? I
> think you'll reduce the human readability of URIs if you start turning
> them into code objects deconstructed by programs.

I seriously doubt it;  probably what would happen would be that a commonality of tools
and conventions would appear, which would create more uniformity and better URIs
everywhere.

jb








-----------------------------------------------------------------------------------
Post ID:884
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 02:09:11
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:


Paul Prescod wrote:

> Jeff Bone wrote:
> >
> > Paul Prescod wrote:
> >
> > > #1. The web people have this problem where the "file system" is global
> > > and they want any link to be able to point at any server.
> >
> > This is not unique to the Web.
>
> It isn't unique to the Web but it is the fundamental organizational
> principle of the Web. File systems tend to think first about local data
> and then about making remote data look like local data.

This is a generalization about "file systems" that isn't very useful, Paul.
Distributed filesystems as well as many local filesytems have as their fundamental
organizational principle exactly analogous global namespaces.  Failure to recognize
this (and don't feel singled out, Roy F. didn't recognize this until I encouraged
him to take another look at Plan 9) is one of those areas where Web folks are just
underinformed about the goals and current state of the art in filesystems.

> Anyhow, at the URI (not markup) level, the web is not a query-centric
> system it is an address-centric system.

This is another way of restating the premise, which is that URI are opaque, that
they are identifiers rather than semantic names.  I'm not contesting that this is
the dogma, I'm questioning its value as dogma.  I've thought a lot about this, and
I can't think of any good reasons why this should be so.

If you can tell me one, I'll be quite interested.

> We find things first and
> foremost through a domain name and an associated IP address. A decent
> distributed file system would rather not expose the machine name or IP
> address for files.

That depends on the goals of the distributed filesystem.  The two most widely used
"distributed" filesystems (SMB / CIFS and NFS+autofs) use an exactly analogous
machine + path style of naming.

> So URIs should be viewed as more like the
> book-keeping identifier that the file system uses (inode) and less like
> the file name.

Yes, and that's damned unfortunate.  It's also a bit of an inconsistency in the
goals and requirements for URI --- we need to figure out whether we want URI to be
friendly to humans and their software tools or to be convenient for Web plumbing
builders.  I don't know about you, but I can't remember the last time I interacted
with a file via inode number.

jb








-----------------------------------------------------------------------------------
Post ID:885
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-07 02:22:10
Subject:Re: [rest-discuss] Re: RESTify a business document exchange app
Message:

> Mark Baker <distobj@a...> wrote:
> > s/Accept/Accepted
> 
> Is that a counter-proposal to Mike Dierken's proposal of a Response 
> location where the "Accepted" bits would be part of the response?

No no, just that in HTTP, "Accepted" is the 202 response, and "Accept"
is the request header used to request content negotiation by media type.

> If so, how would you handle the very common case where there are 
> three possible responses:  Accepted, Rejected, or CounterPending. The 
> third meaning that we're still negotiating the deal.

If I've followed the discussion so far, all of those are states of a
resource, and so should be carried over 2xx responses.  Just as HTTP's
methods apply to all resources, so does its response codes - they
have to remain generic.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:886
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 02:22:27
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:


Mark Baker wrote:

> One obvious way, which you seem to suggest, is for everybody to share
> the same relative name for it.  The major problem with this though, is
> that a software agent wouldn't know whether a web site was following
> these rules, or if they just happened to have a page named /contact.

The problem and solution are both the same in the Web case and in the local
operating system file structure case.  How, when I run a script on a machine,
can I be sure that /proc is the process psuedofile system and not a directory
that just happened to be named /proc?  In the OS case, it's because I can
somehow obtain, hopefully programatically, some assurance that the
environment conforms to some standard --- in this case, I can tell I'm
running on (say) Plan 9 and therefore can expect /proc to be organized in and
behave a certain way, the "standard" defined by Plan 9.  In the Web case, one
assumes there would be some resource supported by the site which would
indicate that it conformed to

    http://directory.nameschemes.com/SemNameCore/2002

or whatever.

> It is absolutely key that names not be standardized, because it means
> that there has to be some central authority that ensures that names
> don't conflict.

This doesn't make any sense.  There's no difference in "standardizing"
certain generative grammars for generating resource names and "standardizing"
certain XML schemas for various purposes.  Neither requires a centralized
authority;  both merely require that naming schemes and their associated
semantics are themselves distinguishable via URI.

> The opacity-friendly way of doing this would be to assert a relationship
> between the main site and the URI it uses for the concepts of "contact",
> "help", and "search".  For example, a GET on http://foo.com could
> return some N3 asserting;
>
> @prefix chs: <http://jbone.net/contact-help-search>
> </admin/help/> a chs:Help .
> </search/> a chs:Search .
> </contact-us/> a chs:Contact .

More or less.  I'm not arguing that such information shouldn't be provided;
indeed, I'm piddling around with trying to figure out if RDF or other
XML-based mechanisms can reasonably be used to construct generative grammars
of the type I'm talking about.

jb








-----------------------------------------------------------------------------------
Post ID:887
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 02:31:48
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Paul Prescod wrote:

> Jeff Bone wrote:
> >
> > consider a Web crawler that
> > simply wants to crawl across every available page on my site --- *including the
> > one which isn't linked to by any other page.*
>
> Geez, just link it! Use a <link> tag in HTML if you want something
> simple.

BTW, I'll point out that this unduly biases the Web towards hypermedia which support
such linking, and unduly burdens *all* clients with understanding particular markup
languages.  It's an example of creeping hypermedia-ness of the Semantic Web that, on
some level, is absent from the REST / generic universal information space / HTTP
purist's point-of-view.  The Web is HTTP, not HTML or XML.

jb








-----------------------------------------------------------------------------------
Post ID:888
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-07 02:45:23
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Jeff Bone wrote:
> 
>...
> 
> BTW, I'll point out that this unduly biases the Web towards hypermedia which support
> such linking, and unduly burdens *all* clients with understanding particular markup
> languages.  It's an example of creeping hypermedia-ness of the Semantic Web that, on
> some level, is absent from the REST / generic universal information space / HTTP
> purist's point-of-view.  The Web is HTTP, not HTML or XML.

"REST is defined by four interface constraints: identification of
resources; manipulation of resources through representations;
self-descriptive messages; and, hypermedia as the engine of application
state."

 *
http://www1.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:889
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-07 02:32:42
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Jeff Bone wrote:
> 
>...

> That depends on the goals of the distributed filesystem.  The two most widely used
> "distributed" filesystems (SMB / CIFS and NFS+autofs) use an exactly analogous
> machine + path style of naming.

You are constantly moving the goal posts. You talk about the design
decisions in Plan9 or ReiserFS and then when I point out that the Web
isn't quite like them you point out that the Web has some features in
common with SMB/CIFS. We'll go in circles forever that way.

Yes, if you take the union of all features of all file systems and pick
and choose then you may get something that looks like the Web. But if
you want to claim that the Web should learn from the design decisions
made in file systems then you have to choose one or two logically
similar file systems and demonstrate that the problem domain is similar.

I've not noticed that SMB/CIFS use semantically meaningful names much
other than lpt1: so I don't see how they are relevant to your argument.
In fact, the Windows operating system encourages application designers
to dereference names through the registry and ignore the actual file
names. So we dereference through markup. They dereference through a
binary database that constantly gets corrupted. Both use opaque
identifiers.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:890
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 02:48:17
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Paul Prescod wrote:

> Er, who said you can't cache things in query strings?

I assume you mean things with query strings.  My info is a bit dated, but IIRC
(from proxy work circa '94-'95) it used to be considered bad form for various
reasons for proxy caches to cache "objects" (representations of resources)
identified with URI that had query strings.  Maybe this isn't the case anymore;
indeed, if the entire piece is considered as an opaque whole, on further
consideration I'm not sure why this would be problematic.  OTOH, its a bit
semantically muddled;  does the query string identify the resource or not?  I.e.,
do the following refer to the same _resource_ or not?

    http://foo.com/some/resource
    http://foo.com/some/resource?p1=foo&p2=bar

jb








-----------------------------------------------------------------------------------
Post ID:891
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-07 02:59:36
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

> The problem and solution are both the same in the Web case and in the local
> operating system file structure case.  How, when I run a script on a machine,
> can I be sure that /proc is the process psuedofile system and not a directory
> that just happened to be named /proc?  In the OS case, it's because I can
> somehow obtain, hopefully programatically, some assurance that the
> environment conforms to some standard --- in this case, I can tell I'm
> running on (say) Plan 9 and therefore can expect /proc to be organized in and
> behave a certain way, the "standard" defined by Plan 9.  In the Web case, one
> assumes there would be some resource supported by the site which would
> indicate that it conformed to
> 
>     http://directory.nameschemes.com/SemNameCore/2002
> 
> or whatever.

Ok, so in asserting that, why not reuse that same mechanism to assert
what the URIs are?

> > The opacity-friendly way of doing this would be to assert a relationship
> > between the main site and the URI it uses for the concepts of "contact",
> > "help", and "search".  For example, a GET on http://foo.com could
> > return some N3 asserting;
> >
> > @prefix chs: <http://jbone.net/contact-help-search>
> > </admin/help/> a chs:Help .
> > </search/> a chs:Search .
> > </contact-us/> a chs:Contact .
> 
> More or less.  I'm not arguing that such information shouldn't be provided;
> indeed, I'm piddling around with trying to figure out if RDF or other
> XML-based mechanisms can reasonably be used to construct generative grammars
> of the type I'm talking about.

You need to use query parameters.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:892
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-07 03:04:28
Subject:Query parameters
Message:

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> > Er, who said you can't cache things in query strings?
> 
> I assume you mean things with query strings.  My info is a bit dated, but IIRC
> (from proxy work circa '94-'95) it used to be considered bad form for various
> reasons for proxy caches to cache "objects" (representations of resources)
> identified with URI that had query strings.  

Yes, it was bad form for HTTP 1.0, but not HTTP 1.1:

"We note one exception to this rule: since some applications have
traditionally used GETs and HEADs with query URLs (those containing a
"?" in the rel_path part) to perform operations with significant side
effects, caches MUST NOT treat responses to such URIs as fresh unless
the server provides an explicit expiration time. This specifically means
that responses from HTTP/1.0 servers for such URIs SHOULD NOT be taken
from a cache"

> ... Maybe this isn't the case anymore;
> indeed, if the entire piece is considered as an opaque whole, on further
> consideration I'm not sure why this would be problematic.  OTOH, its a bit
> semantically muddled;  does the query string identify the resource or not?  I.e.,
> do the following refer to the same _resource_ or not?
> 
>     http://foo.com/some/resource
>     http://foo.com/some/resource?p1=foo&p2=bar

No. I have seen nothing to indicate that they refer to the same
resource. URIs address unique identifiers unless some spec says
otherwise. HTTP doesn't say anything that would indicate to me that
those are the same resource:

 * http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:893
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 03:04:05
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:


Paul Prescod wrote:

> "REST is defined by four interface constraints: identification of
> resources; manipulation of resources through representations;
> self-descriptive messages; and, hypermedia as the engine of application
> state."

Fine, yes, this is scripture --- but I'm not sure that the latter follows necessarily,
i.e., it's possible that this POV may be overemphasized in some cases.  If indeed
hypermedia were the *sole* engine of application state, we wouldn't need response codes at
all --- all responses would be self-descriptive hypermedia.

Now you can claim that this is a difference between the pure REST POV and the Web itself,
and you're probably right;  but my interest in both REST and the Web is in determining
what qualities have contributed to the enormous success of the Web.  To the extent that
REST diverges from the Web in practice, I begin to lose interest.

As a counter to this:

"When you design a system, or a language, then if the features can be broken into
relatively loosely bound groups of relatively closely bound features, then that division
is a good thing to be made a part of the design."  --- Principle of Modular Design,
Principles of Design, TBL [1]

It seems clear that embedding the semantics of state transfer in the transferred
hypermedia --- as would be true if hypermedia were truly the engine of all application
state --- breaks with the Principle of Modular Design.

[1] http://www.w3.org/DesignIssues/Principles.html









-----------------------------------------------------------------------------------
Post ID:894
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 03:27:56
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:


Mark Baker wrote:

> Ok, so in asserting that, why not reuse that same mechanism to assert
> what the URIs are?

Because (a) it may be interesting and useful to concisely describe how URI for some
given scheme can be constructed and, if constructed, what they mean (b) it may
*not* be practical or even possible to e.g. exhaustively list all possible opaque
URI constructions from a given scheme.

> You need to use query parameters.

Explain?

jb








-----------------------------------------------------------------------------------
Post ID:895
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 03:25:02
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Paul Prescod wrote:

> You are constantly moving the goal posts. You talk about the design
> decisions in Plan9 or ReiserFS

ReiserFS isn't a distributed filesystem at all.  The lessons from ReiserFS involve
embedding semantics in names, not issues of distribution.  Plan 9 has (some might say
is) a distributed "file" system, but it's so idiosyncratic that it's not a good
comparison, here.

My point in bringing up different filesystems is to help "you" (or the otherwise
dogmatically-afflicted ;-) remedy your misunderstanding that the Web is somehow
different from all filesystem-oriented efforts.  There's not a single high-level
architectural characteristic of the Web that isn't present in some other filesystem
effort, distributed or local.  (There are admittedly none that have *all* those
characteristics.)  There's *no good reason* to believe that there's any single thing
unique about the Web beyond its default and de facto hypermedia interface and the
synthesis it achieves of all its features.  Given the similarities, IMO it's fair to
draw lessons from any / all filesystems which share some characteristic, goal, or what
have you with the Web.  Categorically stating that lessons learned elsewhere aren't
applicable to the Web because it's special (when it isn't) smacks of a kind of
technological provincialism that's frustrating.  We should be proud of the Web.  We
shouldn't be too proud of ourselves. ;-)

Let me be clear about my claims:  after a fair bit of thought, I've concluded that the
strictest statements and interpretations of the Opacity Axiom may be a mistake caused by
overgeneralization from early historical problems in the Web's development.  To the
extent that it has nothing to say contrary to my following assertions, then I'm
generally fine with it:

  * URI should be constructable by human or machine
  * URI should be meaningfully deconstructable by human or machine
  * URI designers should be encouraged to build meaningful namespaces

> Yes, if you take the union of all features of all file systems and pick
> and choose then you may get something that looks like the Web. But if
> you want to claim that the Web should learn from the design decisions
> made in file systems then you have to choose one or two logically
> similar file systems and demonstrate that the problem domain is similar.

Well, that's rather silly, isn't it?  That's like saying "tell me everything you know
about numbers.  You may only use the number 2."

> I've not noticed that SMB/CIFS use semantically meaningful names much
> other than lpt1: so I don't see how they are relevant to your argument.

If my CIFS home directory contains, say, \\someserver\jbone\mail\archive\FoRK\1999 then
that name is indeed semantically meaningful, and its possible that both humans and
software might be able to make some deductions about what other names exist in that
hierarchy.  Particularly if I give them some guidance on the semantics and generative
grammar of that naming scheme as it relates to my information organizational structure.

> In fact, the Windows operating system encourages application designers
> to dereference names through the registry and ignore the actual file
> names.

Yes, and what a good idea that turned out to be. ;-)  Contrast this with systems where
installing an entire piece of software is simply a matter of unpacking a tarball in a
directory.

jb








-----------------------------------------------------------------------------------
Post ID:896
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-07 03:56:30
Subject:Re: [rest-discuss] Query parameters
Message:

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> > >     http://foo.com/some/resource
> > >     http://foo.com/some/resource?p1=foo&p2=bar
> >
> > No.
> 
> Right, that's my recalibrated understanding.  But let me point something out:  if this
> is true, then query parameters are pretty much useless and a kind of syntactic noise.
> If the two URI above don't refer to the same resource "paramterized" differently, then
> there's no need at all for '?', '&', or a special treatment of '='.  The latter URI
> could more simply, uniformly be represented as
> 
>     http://foo.com/some/resource/p1=foo/p2=bar

The query syntax clearly separates the bits that are opaque from the
bits that are client-generated. This allows us to discuss the opacity
axiom and still have an escape hatch for when it is not appropriate.
Your proposed syntax also suggests a hierarchy that isn't there. What
would "p1=foo/../p1=bar" mean?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:897
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 03:32:11
Subject:Re: [rest-discuss] Query parameters
Message:


Paul Prescod wrote:

> >     http://foo.com/some/resource
> >     http://foo.com/some/resource?p1=foo&p2=bar
>
> No.

Right, that's my recalibrated understanding.  But let me point something out:  if this
is true, then query parameters are pretty much useless and a kind of syntactic noise.
If the two URI above don't refer to the same resource "paramterized" differently, then
there's no need at all for '?', '&', or a special treatment of '='.  The latter URI
could more simply, uniformly be represented as

    http://foo.com/some/resource/p1=foo/p2=bar

jb










-----------------------------------------------------------------------------------
Post ID:898
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-07 04:12:26
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Jeff Bone wrote:
> 
> Mark Baker wrote:
> 
> > Ok, so in asserting that, why not reuse that same mechanism to assert
> > what the URIs are?
> 
> Because (a) it may be interesting and useful to concisely describe how URI for some
> given scheme can be constructed and, if constructed, what they mean 

Interesting, yes. Useful? You'll have to make the case that it is every
more useful except for the following:

> ... (b) it may
> *not* be practical or even possible to e.g. exhaustively list all possible opaque
> URI constructions from a given scheme.
> 
> > You need to use query parameters.
> 
> Explain?

Query parameters are for when it is not possible to "e.g. exhaustively
list all possible opaque URI constructions from a given scheme."

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:899
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-07 04:10:10
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

Jeff Bone wrote:
> 
> ... There's *no good reason* to believe that there's any single thing
> unique about the Web beyond its default and de facto hypermedia interface and the
> synthesis it achieves of all its features. 

It isn't an issue of whether there is any single thing. If you want to
apply the design criteria of another system then the basic architecture
and requirements have to be similar. That's clearly not true of SMB/CIFS
so maybe we could stop talking about it.

> ...  Given the similarities, IMO it's fair to
> draw lessons from any / all filesystems which share some characteristic, goal, or what
> have you with the Web.  Categorically stating that lessons learned elsewhere aren't
> applicable to the Web because it's special (when it isn't) smacks of a kind of
> technological provincialism that's frustrating.  

You haven't actually presented any lessons learned. You've said: "smart
people made other choices so maybe they were right." And maybe they were
wrong. The benefits you've argued for non-opacity are quite small and
you're talking about erecting new schema languages, conventions and
interface definition systems to support it.

>...
> Let me be clear about my claims:  after a fair bit of thought, I've concluded that the
> strictest statements and interpretations of the Opacity Axiom may be a mistake caused by
> overgeneralization from early historical problems in the Web's development.  

And I think you're wrong. At the very least, the opacity axiom frees the
application to physically put its resources where-ever it wants without
incurring the cost of an HTTP redirect. It also addresses Mark's issue
about standardization.

> ... To the
> extent that it has nothing to say contrary to my following assertions, then I'm
> generally fine with it:
> 
>   * URI should be constructable by human or machine
>   * URI should be meaningfully deconstructable by human or machine
>   * URI designers should be encouraged to build meaningful namespaces

I disagree. Wherever possible, machines should be discouraged from
either constructing or deconstructing them. Barring a few weird cases
(like censorship proxies) they should be "end-to-end" so that only the
producing and consuming applications ever deconstruct them and
applications that didn't produce them should not try to deconstruct
them.

> > Yes, if you take the union of all features of all file systems and pick
> > and choose then you may get something that looks like the Web. But if
> > you want to claim that the Web should learn from the design decisions
> > made in file systems then you have to choose one or two logically
> > similar file systems and demonstrate that the problem domain is similar.
> 
> Well, that's rather silly, isn't it?  That's like saying "tell me everything you know
> about numbers.  You may only use the number 2."

No, it's saying lets restrict our conversation to systems that are
relevant.

> > I've not noticed that SMB/CIFS use semantically meaningful names much
> > other than lpt1: so I don't see how they are relevant to your argument.
> 
> If my CIFS home directory contains, say, \\someserver\jbone\mail\archive\FoRK\1999 then
> that name is indeed semantically meaningful, and its possible that both humans and
> software might be able to make some deductions about what other names exist in that
> hierarchy.  

Nobody could prevent you from writing software that does that but it
would be poor software design. Of course using human meaningful names is
great. But writing software that presumes, for example, that the mailing
archive is going to be broken down by years and that the years will
reside on the same disk would be poor software design. I already have
this problem when I want to move my massive trash folder to a different
disk than the other mail messages.

> ... Particularly if I give them some guidance on the semantics and generative
> grammar of that naming scheme as it relates to my information organizational structure.

And how will I get around the fact that my 1999 and 2000 folders just
won't fit on the same disk and the \\someserver\ operating system
doesn't have a concept of symlinks?

> > In fact, the Windows operating system encourages application designers
> > to dereference names through the registry and ignore the actual file
> > names.
> 
> Yes, and what a good idea that turned out to be. ;-)  

It's an excellent idea. Thanks to it, I can take my home directory from
machine to machine with all of the magical windows setting in it. On one
machine its e:\data\profile on another its c:\profile and in theory I
could even have one machine get its profile information over the net.

Guess what: Unix does the same thing. It is typical to dereference your
home directory through one of ~, $HOME or /etc/passwd. Hypertext is the
engine of application state. Unix just isn't consistent about it because
nobody ever formulated it as an axiom. And because Unix is not
consistent about it, you get software that presumes that a particular
file is going to be in a particular place. There is no global root way
to ask where the file should be so you just have to "know".

The reason it can't be an axiom on Unix (or even Windows) is because
indirection is annoying and people hate indirection in user interfaces.
The file system is a really important user interface in every operating
system so people get annoyed if they can only navigate it through
indirection. I don't dispute that the opacity principle has a price in
simplicity and to a certain extent usability. It compensates in
*flexibility*.

> ... Contrast this with systems where
> installing an entire piece of software is simply a matter of unpacking a tarball in a
> directory.

You're talking about something totally different.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:900
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-07 04:09:30
Subject:Re: [rest-discuss] Opacity Reconsidered
Message:

> Mark Baker wrote:
> 
> > Ok, so in asserting that, why not reuse that same mechanism to assert
> > what the URIs are?
> 
> Because (a) it may be interesting and useful to concisely describe how URI for some
> given scheme can be constructed and, if constructed, what they mean (b) it may
> *not* be practical or even possible to e.g. exhaustively list all possible opaque
> URI constructions from a given scheme.
> 
> > You need to use query parameters.
> 
> Explain?

A URI is an odd creature with opaque, semi-opaque, and non-opaque parts.
The authority/port part is non-opaque, the path part is opaque, and
query parameters are semi-opaque.  That is, they are opaque to
intermediaries, but are not opaque to clients because they are a way
for the publisher to say "put what you want here, I can take it".
That's where somebody other than the publisher gets to do guessing.
For example, from your Wiki page, you have;

http://foo.com/~joeuser/archive/www.att.com/1999/04/19 

This would best be;

http://foo.com/~joeuser/archive?host="www.att.com"&date="1999/04/19"
etc..

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:901
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-06 15:02:46
Subject:Re: [rest-discuss] PUT vs. POST
Message:

> This is exactly right --- and this is part of what I was talking about a while
> back -wrt- the addressibility of resources vs. representations.  You can't ever
> address representations directly.

Well, you SHOULD be able to, viz a viz the requirement that the
Content-Location header SHOULD be returned when multiple representations
exist for the same resource.

I really love that header, as it reifies a Composite pattern that's
really necessary if "everything on the Web has a URI".  That's why I
gave it special attention in RestRDF.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:902
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-06 15:15:49
Subject:Re: [rest-discuss] Re: RESTify a business document exchange app
Message:

> > The existence of a document might imply business acceptance - which is not
> > correct. If the business process defines acknowledgement or status documents
> > that have 'accepted', 'rejected' and 'undecided' values, then this would be
> > fine I think (retrieving the status document tells you if it was actually
> > approved). If the business document set doesn't define 'undecided' values
> > then the Location header might need to reference a resource that does not
> > yet exist - and when it does exist the values within would specify
> > 'accepted' or 'rejected'.
> 
> Wouldn't it be legitimate to return "Created" with a Location header in this
> case. After all, you did create a resource--the status document you describe
> above.

Except that then you lose the "Accepted" bit, which is really the most
important one.

I noticed that 201 didn't include the Location header some time ago, but
forgot to bring it up.  I think it would be a great idea to include it,
as it would permit simpler automation of asynchronous processing with
HTTP.  Anybody want to raise this with on the HTTP WG mailing list?
It might be added to the errata - I consider it an oversight, and I
doubt there's any deployment issue with doing it.

Another option would be the use the DAV "multistatus" feature where
a response includes a XML body that includes multiple response codes.
This way it could return both 201 and 202.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:903
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 06:41:43
Subject:Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:


Paul Prescod wrote:

> It isn't an issue of whether there is any single thing. If you want to
> apply the design criteria of another system then the basic architecture
> and requirements have to be similar. That's clearly not true of SMB/CIFS
> so maybe we could stop talking about it.

The amazing thing about SMB/CIFS vis-a-vis the Web isn't that its "basic architecture"
(whatever that means, we're talking about names, here) is similar, and I have no visibility to
its requirements a priori.  The amazing thing about SMB/CIFS is the *almost identical to HTTP
URI* naming scheme it employs.  It doesn't take much head-scratching to realize that the same
problems yield the same solutions, and indeed, the similarity of the two is a rather striking
example of the ToII.

> You haven't actually presented any lessons learned.

Then you haven't read what I've written. ;-)  But if you'd prefer to hear it them from other
potentially more authoritative sources, go spend a fraction of the amount of time prowling the
references I've posted that you (and I, and all of us on this list) have spent studying The
Official Cannon. :-)

> The benefits you've argued for non-opacity are quite small and
> you're talking about erecting new schema languages, conventions and
> interface definition systems to support it.

Well, there's no reason to believe that the benefits or small, large, or otherwise in the
absence of a more detailed investigation of relaxing the opacity axiom.  But without such an
investigation --- substituting dogma for research --- one can't really speak authoritatively
about such things.  It seems to me that the Opacity Axiom is overstated and overapplied, and
I've documented some few of the many reasons why embedding information in names is in fact
useful, not anathema as the dogma states.

As for the horrors of new schema languages, conventions, and interface definition systems...
WRDL?  I rest my case.  If you're going to argue, you should at least try not to argue with
yourself. ;-)  (Sometimes, that's hard --- trust me, I know. ;-)

> And I think you're wrong. At the very least, the opacity axiom frees the
> application to physically put its resources where-ever it wants without
> incurring the cost of an HTTP redirect. It also addresses Mark's issue
> about standardization.

(a) The redirect issue is a complete red herring, as I've already illustrated.  Name opacity
has *nothing at all* to do with redirection and relocation.

(b)  The "standardization" issue is also a red herring, as I've already illustrated.  It
hardly matters whether what's being "standardized" (let's be more clear, specified by any and
all who want to specify such things, independent of any central authority) is N3 notation for
ontologies of resources or some other mechanism for specifying generative grammars for names
and information organizational conventions.

> >   * URI should be constructable by human or machine
> >   * URI should be meaningfully deconstructable by human or machine
> >   * URI designers should be encouraged to build meaningful namespaces
>
> I disagree. Wherever possible, machines should be discouraged from
> either constructing or deconstructing them.

Why?  I've heard all the reasons you and others have brought up.  They aren't compelling.
There are clear existance proofs of the power and utility of semantically meaningful names.
The counter-arguments are mostly apocryphal horror stories of certain bad choices made early
in the Web's lifecycle.

> Barring a few weird cases
> (like censorship proxies) they should be "end-to-end" so that only the
> producing and consuming applications ever deconstruct them

I agree.  Proper operation of intermediaries requires that it be possible to treat URI
opaquely.  This doesn't mean that URI need be absolutely opaque, and says nothing about the
producers, consumers, etc.

> No, it's saying lets restrict our conversation to systems that are
> relevant.

I'm not going to argue with you about how to argue, Paul.  If you're offended by the plethora
of potential learning opportunities I'm providing you, I'm truly sorry.

> Nobody could prevent you from writing software that does that but it
> would be poor software design.

Well, you are in essence asserting that all attempts to embed semantics and use meaningful
names to structure systems of resources --- including such incredibly powerful and yet
incredibly misunderstood efforts like Plan 9 --- is poor software design.  You make this
assertion with very little backup, and contrary to the prevailing opinion of some of the
world's most influential computer scientists.

> Of course using human meaningful names is
> great. But writing software that presumes, for example, that the mailing
> archive is going to be broken down by years and that the years will
> reside on the same disk would be poor software design.

It does nothing of the sort.  It poses an abstract organization of resources in a
quasi-hierarchical namespace.  It doesn't at all necessarily assume that the breakdown by
years is the only possible naming structure (others might simultaneously exist) or that the
objects are going to "reside on the same disk."  (Check out NTDFS, AT&T 3DFS, Sun's
Translucent File System, the FiST stackable filesystem toolkit, and other filesystems to see
why you're wrong in your presumption.)  It might be a bad software design if those
presumptions were true, but the fact that you make those presumptions simply illustrates a
lack of understanding of the flexibility and utility of the filesystem namespace in many
modern filesystems.

> I already have
> this problem when I want to move my massive trash folder to a different
> disk than the other mail messages.

Yes, no doubt, this is a huge problem.  Most workday local filesystems couple the namespace to
the underlying storage space in unpleasantly tight ways.  This is one of the problems we're
addressing at Deepfile.

> And how will I get around the fact that my 1999 and 2000 folders just
> won't fit on the same disk and the \\someserver\ operating system
> doesn't have a concept of symlinks?

Simple --- you layer on a stackable filesystem.  You then mount up the 1999 filesystem from
one place and the 2000 folder from another place into a single virtual parent directory.
Voila!  It looks like they're in the same place, but they aren't.

> > Yes, and what a good idea that turned out to be. ;-)
>
> It's an excellent idea.

Now I know you're broken.  ;-)  The Windows registry is the worst idea ever, hands down, end
of story.  It's such a bad idea that getting away from the registry and from "DLL Hell" ---
i.e., enabling plug-and-go installation of software just by writing directories and files ---
was supposedly one of the original motivations of the research effort that became .NET.

> I don't dispute that the opacity principle has a price in
> simplicity and to a certain extent usability.

Now we're getting somewhere.

> It compensates in
> *flexibility*.

Yes, by *losing* it.

> > ... Contrast this with systems where
> > installing an entire piece of software is simply a matter of unpacking a tarball in a
> > directory.
>
> You're talking about something totally different.

It's part-and-parcel of the same thing.  Squint, you can see it.

jb








-----------------------------------------------------------------------------------
Post ID:904
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 06:59:03
Subject:Even RFC2396 doesn't really treat URI as opaque
Message:


Paul Prescod wrote:

> Interesting, yes. Useful? You'll have to make the case that it is every
> more useful except for the following:

I don't actually have to make the case --- one of the wonderful things about the Web is
that, as always, I'm free to ignore whatever parts of the dogma you can't make sense of
for me. ;-)

Look, I bought the REST ticket, saw the show, got the T-shirt, drank the Kool-Aid, got a
bit part in the production, and have even helped sell more tickets to my friends and
family.  I only have one itty-bitty small problem with the whole thing:  after a lot of
consideration and a lot of comparitive analysis with other systems that exhibit similar
properties in similar contexts, I've concluded the opacity axiom is largely based on
unsubstantiated paranoia that stems from overgeneralization from early problems with the
(then lack of) Web architecture, and is in general taken far too seriously and literally
by many people.  That's my opinion, open to change, compelling counterarguments welcome.

Even Mark's own "opacity" investigation [1] makes my point for me.  We start with the
presumption that URI are opaque and "semantics free" in all contexts then proceed to
describe how in fact they have parts that have hierarchical and other relationships with
each other!  The URI spec itself itself, in all its contortions to specify how
HTTP-scheme relative URI are to be handled, proves my point!  They aren't semantics-free
and they aren't opaque, they describe a hierarchical information space supplemented with
properties and a flat parameter space.  This is a kind of *semantics.*  It desribes an
*ontology*, albeit rather vaguely.

Paul, you aren't going to sway my considered opinion simply by reciting the dogma to me,
and none of the arguments you've posed are unfamiliar.  Indeed, most of them are dealt
with in the writeup.  If you want to convince me that URI *are* and *should be* opaque,
you need to illustrate that this is true and that dangers abound when you treat them
otherwise.  For every "dangerous" example you give, I'll be happy to offer a positive,
beneficial scenario for using semantically-meaningful names.  We'll see who runs out of
scenarios first.

jb

[1] http://www.markbaker.ca/2002/01/UriOpacityInvestigation/
[2] http://www.ietf.org/rfc/rfc2396.txt







-----------------------------------------------------------------------------------
Post ID:905
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 07:24:21
Subject:The Principle of Explicit Transparency
Message:


Mark Baker wrote:

> A URI is an odd creature with opaque, semi-opaque, and non-opaque parts.
> The authority/port part is non-opaque, the path part is opaque, and
> query parameters are semi-opaque.

Another way to put this is that URI are prima facie not opaque entities --- otherwise
what is all that grammar doing in RFC2396?  They have parts and those parts have syntax,
and those parts also have semantic relationships with each other.  However, due perhaps
to some early failures in putting *inappropriate* information into URI, we've apparently
decided as a Web community to chuck the endeavor entirely.  And some (at least) among us
have done this in relative ignorance of current research regarding semantic naming in
other more-or-less analogous contexts.

> http://foo.com/~joeuser/archive/www.att.com/1999/04/19
>
> This would best be;
>
> http://foo.com/~joeuser/archive?host="www.att.com"&date="1999/04/19"
> etc..

I fail entirely to see why this is objectively preferable to the former.  It's got more
syntax, that's for sure. ;-)  OTOH, a "smart" namespace manager might provide all of the
following as potential well-formed synonyms for the object of interest:

http://foo.com/~joeuser/archive/www.att.com/1999/04/19
http://foo.com/~joeuser/www.att.com/archive/1999/04/19
http://foo.com/~joeuser/1999/04/19/archive/www.att.com
http://foo.com/~joeuser/1999/04/19/www.att.com/archive

The Principle of Explicit Transparency
----------------------------------------------

Mark, in your opacity investigation you state that you believe the Opacity Axiom to be
fundamental because it forces "publishers to be explicit about the relationships between
their resources through any mechanism that allows them to state those relationships."  I
totally buy that this is desirable...  however that doesn't mean that URI cannot be
*other* than opaque.  How about this for a relaxed statement:

"URI are required (modulo existing exceptions to this rule in RFC2396) to be treated by
all parties other than publishers as if they were opaque, except when the publisher is
explicit about the relationships between those resources and the names they may have
through any mechanism that allows them to state those relationships and rules for forming
names.  In all cases, URI are required to be treated as opaque by any party to an
interaction other than the ultimate endpoints involved."

I.e., publishers could easily provide to others generative grammars or other mechanisms
that would allow them to construct well-formed and meaningful references without a-priori
requiring a link to some root in the site's namespace.

Indeed, relaxing opacity would allow for easier introduction and proliferation of naming
schemes which deviate from the traditional hierarchical containers-and-objects metaphor.
The explicit information about the organization of the (name)space could be used to
describe the specific relationships of the various syntactic parts, just like RFC2396
does but in a machine-processible fashion.  The kinds of problems you were discussing
earlier re: mapping to the relational model might be more easily addressed by allowing
applications to define what the relationship between parts separated by '/' is intended
to be.  A particular application might treat these parts as order-independent sets and
'/' as set-theoretic intersection, and explicit information about this would allow
applications to construct their own "queries" against this namespace.

That's my story for tonite, I'm sticking to it. ;-)

jb








-----------------------------------------------------------------------------------
Post ID:906
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 07:34:38
Subject:Dot-Dot is Tricky was Re: [rest-discuss] Query parameters
Message:

Paul Prescod wrote:

> Your proposed syntax also suggests a hierarchy that isn't there. What
> would "p1=foo/../p1=bar" mean?

Assuming something like McClennen-Sechrest, I would assume that this means the object p1=bar
if it exists in the same directory as the object p1=foo.  (Remember, we've already decided
that each possible permutation in fact identifies a different resource, so the idea that
specific values for parameters identify different resources shouldn't trouble you too much.)

I'm really kicking the dog, here, but here you go proving to me again that URI aren't
actually opaque *even now.*  If you truly believed that URI were opaque --- or that the path
parts were opaque --- then why would you assume that my URI suggests hierarchy?  If URI were
actually opaque, I would entirely be free to interpret any syntactically well-formed URI in
whichever way I like.  Perhaps '/' means set intersection in my ontology, '..' is
meaningless, and order of parts is irrelevant.

URI aren't opaque, they have specific syntax and associated semantics *even today.*  One way
to look at what I'm proposing is this:  find ways to free the semantics of URI from the
implied semantics of RFC2396 and make them explicit and usable by humans and software.

jb

PS - Getting the semantics of .. right is troublesome in any context.  Cf. Rob Pike (one of
the inventors of the idea of .., IIRC) musings on the topic in the context of Plan 9
development in his paper "Lexical File Names in Plan 9 or Getting Dot-Dot Right." [1]

[1] http://www.cs.bell-labs.com/sys/doc/lexnames.pdf











-----------------------------------------------------------------------------------
Post ID:907
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-06 17:48:04
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

> > I also can't see trying to convince a set of companies that plan to make
> > money off a centralized model, that a decentralized model is the best
> > way to go.  So I'm not really into evangelizing REST to them either.
> 
> I don't really have the time to become an ebxml reg/rep expert but I do
> feel that the ebXML world is a natural ally for the REST world because
> they seem to be document-centric rather than API and software-centric.

Well, there's definitely conflicting goals there.  It would not have
been hard for them to decentralize without using REST, but they chose
not to.  So I think that there's forces at work there.

And I'm not saying there's no value to evangelizing it to them.  It's
just that there's only so many hours in a day.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:908
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-06 19:15:05
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

bhaugen32 wrote:
> 
>...
> 
> Mark, I don't understand why you are dismissing ebXML either.

I think he was just saying that trying to get the regrep people (not
ebXML in general) to move to a decentralized model would take more
effort than he is willing to undertake.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:909
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-07 14:17:11
Subject:Re: Idea: Simple Web Service Behaviour Language
Message:

Paul Prescod:
> Bob Haugen:
> > 
> >...
> > 
> > Mark, I don't understand why you are dismissing ebXML either.
> 
> I think he was just saying that trying to get the regrep people (not
> ebXML in general) to move to a decentralized model would take more
> effort than he is willing to undertake.

I'm not personally interested in regrep, as I said, I think they went 
the wrong way.

There are lots of groups within ebXML. I come from the Business 
Process group. You're looking into DAML-S business process models. I 
think in some ways we are a generation ahead.  We do technology-
neutral models, but are developing an RDF representation.  DAML-S is 
ahead of us on RDF, we're ahead in resource modeling and use of 
resource state for pre and post condition expressions.  I think in 
the near future we will try to get together with them (the models are 
similar enough to converge), but it's another case of too few hours 
in a day.  

[...]

Paul Prescod:
>> I don't really have the time to become an ebxml reg/rep expert but 
I do
>> feel that the ebXML world is a natural ally for the REST world 
because
>> they seem to be document-centric rather than API and software-
centric.

Mark Baker:
>Well, there's definitely conflicting goals there. 
>It would not have been hard for them to decentralize 
>without using REST, but they chose not to. 
>So I think that there's forces at work there.

There are definitely forces at work in the regrep group, and they 
come from your previous employer.  Much of ebXML is P2P.  The 
business process stuff is all P2P at this point.  I think they would 
be open to REST.  Or at least I am, and so are some others in my gang.

> And I'm not saying there's no value to evangelizing 
> it to them. It's just that there's only so many hours 
> in a day.

I'm not sure why you keep repeating this to me. I'm not regrep.  You 
don't need to evangelize me, I came to you.  All I want is to find 
somebody to discuss this stuff with me respectfully.  In particular, 
answer questions.

Or actually I don't even need that, I can go back to lurking, and 
I'll get it just fine.

One problem I am having now is that there are at least five different 
approaches for how to do the resource modeling on the table: mine 
(not a proposal yet), Paul Prescod's, Mike Dierken's, Jeff Bone's and 
Mark Baker's.  And there are some terminology issues confusing them.

One terminology issue is "accept":  the standard business protocol 
for contracts (orders are a kind of contract) is offer-acceptance. 
Accepted is also used as an HTTP response.  But the semantics of the 
two uses are very different.  

-Bob Haugen











-----------------------------------------------------------------------------------
Post ID:910
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-07 15:29:37
Subject:Re: [rest-discuss] Re: Idea: Simple Web Service Behaviour Language
Message:

> There are lots of groups within ebXML. I come from the Business 
> Process group. You're looking into DAML-S business process models. I 
> think in some ways we are a generation ahead.  We do technology-
> neutral models, but are developing an RDF representation.  DAML-S is 
> ahead of us on RDF, we're ahead in resource modeling and use of 
> resource state for pre and post condition expressions.  I think in 
> the near future we will try to get together with them (the models are 
> similar enough to converge), but it's another case of too few hours 
> in a day.  

That sounds cool.  But I still haven't made my mind up about DAML-S
yet.  I think I've read their docs 3 times by now, and it's still not
sinking in for me.  Not sure why.

> 
> [...]
> 
> Paul Prescod:
> >> I don't really have the time to become an ebxml reg/rep expert but 
> I do
> >> feel that the ebXML world is a natural ally for the REST world 
> because
> >> they seem to be document-centric rather than API and software-
> centric.
> 
> Mark Baker:
> >Well, there's definitely conflicting goals there. 
> >It would not have been hard for them to decentralize 
> >without using REST, but they chose not to. 
> >So I think that there's forces at work there.
> 
> There are definitely forces at work in the regrep group, and they 
> come from your previous employer.

I can neither confirm nor deny that. 8-)

>  Much of ebXML is P2P.  The 
> business process stuff is all P2P at this point.  I think they would 
> be open to REST.  Or at least I am, and so are some others in my gang.

Good.  Invite them over!

> > And I'm not saying there's no value to evangelizing 
> > it to them. It's just that there's only so many hours 
> > in a day.
> 
> I'm not sure why you keep repeating this to me. I'm not regrep.  You 
> don't need to evangelize me, I came to you.  All I want is to find 
> somebody to discuss this stuff with me respectfully.  In particular, 
> answer questions.

I'm obviously here for that reason.  Sorry Bob, I got the impression
from the previous discussion that I was being asked to run out and
evangelize REST on the ebXML mailing lists.

> Or actually I don't even need that, I can go back to lurking, and 
> I'll get it just fine.
> 
> One problem I am having now is that there are at least five different 
> approaches for how to do the resource modeling on the table: mine 
> (not a proposal yet), Paul Prescod's, Mike Dierken's, Jeff Bone's and 
> Mark Baker's.  And there are some terminology issues confusing them.
> 
> One terminology issue is "accept":  the standard business protocol 
> for contracts (orders are a kind of contract) is offer-acceptance. 
> Accepted is also used as an HTTP response.  But the semantics of the 
> two uses are very different.  

I don't think this is an issue at all.  "Accept" is for content
negotiation, not for any kind of offer/acceptance mechanism.  You use
it to say "give me HTML", or "give me JPEG".  I don't see them as
related at all.

Neither do I see the Accepted (202) response code being related to
offer/acceptance.  It's a data transfer feature ("response will not be
returned on this connection"), not anything that has any "business
level" semantics.

I think if you asked Paul/Mike/Jeff/myself to model offer/acceptance,
that we would pretty much build the same model.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:911
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-07 15:57:33
Subject:Re: Idea: Simple Web Service Behaviour Language
Message:

Mark Baker wrote:
> I still haven't made my mind up about DAML-S
> yet.  I think I've read their docs 3 times by now, and it's still 
not
> sinking in for me.  Not sure why.

I haven't made my mind up either.  When I said "technology neutral 
design", I meant as an ideal.  The technology-neutral refrain in 
ebXML comes from UN/CEFACT, the United Nations trade facilitation 
committee.  The UN/CEFACT business process people do not think XML is 
the end of the road.  Some prefer RDF. They are also mandated to use 
UML, which embeds some other technology assumptions, although I think 
they may go more deeply into RDF in the near future.  

DAML-S appears to assume procedure-step style workflow engines.  
RosettaNet crashed and burned trying to use those in B2B ecommerce 
before giving up and going to a state-alignment conversational model. 
Etc.

> >  Much of ebXML is P2P.  The 
> > business process stuff is all P2P at this point.  I think they 
would 
> > be open to REST.  Or at least I am, and so are some others in my 
gang.
> 
> Good.  Invite them over!

I will, as soon as I have figured out enough to make a good "sales 
pitch".
>  Sorry Bob, I got the impression
> from the previous discussion that I was being asked to run out and
> evangelize REST on the ebXML mailing lists.

Not by me.  I agree it would be a total waste of time and just annoy 
the inhabitants.  I intend to bring people from my gang in ebXML over 
to here and the REST wiki, when I think I can make a good case (or 
somebody else has made a good case first, which would be even better 
from my point of view).

> I don't think ["accept"] is an issue at all.  "Accept" is for 
content
> negotiation, not for any kind of offer/acceptance mechanism.  You 
use
> it to say "give me HTML", or "give me JPEG".  I don't see them as
> related at all.
> 
> Neither do I see the Accepted (202) response code being related to
> offer/acceptance.  It's a data transfer feature ("response will not 
be
> returned on this connection"), not anything that has any "business
> level" semantics.

I agree, but I think the overloaded word confused some of the 
discussions. 
 
> I think if you asked Paul/Mike/Jeff/myself to model 
offer/acceptance,
> that we would pretty much build the same model.

Let's do it! It is one of the key business-level protocols. My 
conclusion from previous discussions would be two HTTP exchanges:
1. offer-ack
2. businessResponse-ack
where businessResponse could be "accept", "reject" or some variation 
on "let's negotiate, I will make a counter-offer next".

A good RESTful offer-acceptance model would be the start of a 
compelling argument to the ebXML business process gang.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:912
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-07 16:17:38
Subject:Offer/acceptance
Message:

> > I think if you asked Paul/Mike/Jeff/myself to model 
> offer/acceptance,
> > that we would pretty much build the same model.
> 
> Let's do it! It is one of the key business-level protocols. My 
> conclusion from previous discussions would be two HTTP exchanges:
> 1. offer-ack
> 2. businessResponse-ack
> where businessResponse could be "accept", "reject" or some variation 
> on "let's negotiate, I will make a counter-offer next".

Just to clarify, is "ack" a business level ack ("got your offer,
I'll check it out and get back to you"), or a transfer level ack
("received your message")?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:913
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-07 16:47:03
Subject:SMB/CIFS
Message:

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> > It isn't an issue of whether there is any single thing. If you want to
> > apply the design criteria of another system then the basic architecture
> > and requirements have to be similar. That's clearly not true of SMB/CIFS
> > so maybe we could stop talking about it.
> 
> The amazing thing about SMB/CIFS vis-a-vis the Web isn't that its "basic architecture"
> (whatever that means, we're talking about names, here) is similar, and I have no visibility to
> its requirements a priori.  The amazing thing about SMB/CIFS is the *almost identical to HTTP
> URI* naming scheme it employs.  It doesn't take much head-scratching to realize that the same
> problems yield the same solutions, and indeed, the similarity of the two is a rather striking
> example of the ToII.

I keep telling you that the inventors of SMB/CIFS are as dogmatic about
the opacity principle as we are, and they back it up with licensing
programs and stickers.

> > > Yes, and what a good idea that turned out to be. ;-)
> >
> > It's an excellent idea.
> 
> Now I know you're broken.  ;-)  The Windows registry is the worst idea ever, hands down, end
> of story.  It's such a bad idea that getting away from the registry and from "DLL Hell" ---
> i.e., enabling plug-and-go installation of software just by writing directories and files ---
> was supposedly one of the original motivations of the research effort that became .NET.

You're not listening and you edited out the part of the message that
points out that UNIX is the same in this regard as Windows. Yes the
registry is a bad idea. Microsoft happens to indirect through the
registry. The indirection is a good idea. That's why Unix does it too,
through "~", "TEMPDIR", "HOME" and /etc/passwd.

Because Unix now has an efficient concept of symlinks, it could probably
get away with having a root directory called /plan9/homdirs which
organized everything in the plan9 style and another root directory
called /linux/homedirs which organized everything in the Linux style.
But the Web *does not have* an efficient concept of symlinks. Instead it
has hyperlinks.

> > > ... Contrast this with systems where
> > > installing an entire piece of software is simply a matter of unpacking a tarball in a
> > > directory.
> >
> > You're talking about something totally different.
> 
> It's part-and-parcel of the same thing.  Squint, you can see it.

No, it isn't part and parcel of the same thing. Indirecting well-known
paths through something like an environment variable or registry setting
or hypertext document has *nothing to do* with whether installation goes
into a single directory. You're just trying to tar the idea through
proximity to bad ideas.

> (a) The redirect issue is a complete red herring, as I've already illustrated.  Name opacity
> has *nothing at all* to do with redirection and relocation.

Let's put it this way. Opaque names and non-opaque names can both be
redirected and relocated equally easily. *BUT* if the authoritative,
official way to navigate from one name to another is through name
similarlity relationships rather than through hypertext relationships
then it becomes impossible for two related names to be directly served
off of unrelated servers in a domain-name based system. Therefore you
need the hypertext to be authoritative in which case the names are
effectively opaque again because you are no longer relying on their
similarity.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:914
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 18:36:52
Subject:Onions in the Varnish
Message:

I haven't read the book myself yet, but ordered it just based on
this anecdote:

"In The Periodic Table, Primo Levi tells a story that happened
when he was working in a varnish factory. He was a chemist, and
he was fascinated by the fact that the varnish recipe included a
raw onion. What could it be for? No one knew; it was just part of
the recipe. So he investigated, and eventually discovered that
they had started throwing the onion in years ago to test the
temperature of the varnish: if it was hot enough, the onion would
fry."
    -- Paul Graham [1]

The Axiom of Opacity is just such an onion in the varnish of REST
/ the Web.  It's prima facie false;  it should at best be called
The Conceit of Opacity and at worst The Delusion of Opacity.
Consider the following contradiction, brought to you courtesy Tim
Berners-Lee:

"When you are not dereferencing you should not look at the
contents of the URI string to gain other information." (Opacity
Axiom) [2]

"Looking at this
[http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm], the
"pubs/1998" header [sic, he's referring to hierarchical parts of
a URI -jb] is going to give any future archive service a good
clue that the old 1998 document classification scheme is in
progress." [3]

So we're not supposed to look at the contents of a URI string.
But here we are looking at the contents of a URI string.
Hmmm...  where there's a contradiction, there's probably
confusion, and confusion about and selective application of an
axiom makes one question the validity of the axiom.

$0.02,

jb

[1] http://www.paulgraham.com/arcll1.html
[2] http://www.w3.org/DesignIssues/Axioms
[3] http://www.w3.org/Provider/Style/URI.html









-----------------------------------------------------------------------------------
Post ID:915
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 18:09:15
Subject:Re: [rest-discuss] SMB/CIFS
Message:


Paul Prescod wrote:

> I keep telling you that the inventors of SMB/CIFS are as dogmatic about
> the opacity principle as we are,

And you conclude this because...?

> Indirecting well-known
> paths through something like an environment variable or registry setting
> or hypertext document has *nothing to do* with whether installation goes
> into a single directory. You're just trying to tar the idea through
> proximity to bad ideas.

Sigh.  Paul, you're getting the independent threads of this conversation tangled --- not suprising,
given your Webby proclivities.  ;-)  The point I was making re: the registry is that some
installation mechanisms dispense with this indirection entirely, creating self-contained
installations / configurations rather than interacting with settings in the registry / environment /
what-have-you.  This isn't a bad idea, it's a good idea --- and it's one of the motivating ideas
behind .NET, behind the ROX desktop, behind some aspects of how NeXT / OS X package software, etc.

> Let's put it this way. Opaque names and non-opaque names can both be
> redirected and relocated equally easily. *BUT* if the authoritative,
> official way to navigate from one name to another is through name
> similarlity relationships rather than through hypertext relationships
> then it becomes impossible for two related names to be directly served
> off of unrelated servers in a domain-name based system.

Not at all --- this appears to be an overgeneralization.  In order for this to make sense, you need
to describe specifically what the relationship between the two names is and why this relationship
prevents being served from unrelated servers.

jb







-----------------------------------------------------------------------------------
Post ID:916
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-07 18:41:23
Subject:Re: [rest-discuss] SMB/CIFS
Message:

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> > I keep telling you that the inventors of SMB/CIFS are as dogmatic about
> > the opacity principle as we are,
> 
> And you conclude this because...?

Because on Windows you cannot get Microsoft's little stamps of approval
on your product if you refer directly to "/Program Files" or "/Documents
and Settings". You MUST look up the real names of these things. You MUST
NOT presume that the file system namespace is consistent.

> > Indirecting well-known
> > paths through something like an environment variable or registry setting
> > or hypertext document has *nothing to do* with whether installation goes
> > into a single directory. You're just trying to tar the idea through
> > proximity to bad ideas.
> 
> Sigh.  Paul, you're getting the independent threads of this conversation tangled --- not suprising,
> given your Webby proclivities.  ;-)  The point I was making re: the registry is that some
> installation mechanisms dispense with this indirection entirely, creating self-contained
> installations / configurations rather than interacting with settings in the registry / environment /
> what-have-you.  This isn't a bad idea, it's a good idea --- and it's one of the motivating ideas
> behind .NET, behind the ROX desktop, behind some aspects of how NeXT / OS X package software, etc.

You're going to have to provide some evidence for that statement. For
instance how does .NET in any way remove a level of indirection from the
filesystem?

> > Let's put it this way. Opaque names and non-opaque names can both be
> > redirected and relocated equally easily. *BUT* if the authoritative,
> > official way to navigate from one name to another is through name
> > similarlity relationships rather than through hypertext relationships
> > then it becomes impossible for two related names to be directly served
> > off of unrelated servers in a domain-name based system.
> 
> Not at all --- this appears to be an overgeneralization.  In order for this to make sense, you need
> to describe specifically what the relationship between the two names is and why this relationship
> prevents being served from unrelated servers.

I have a resource that represents a user and one that represents a
user's bio. I could use the namespace: /users/paul/bio or I could use
hypertext /users/paul#xptr(document(@bio)). In the latter case, the
thing referenced by @bio can live anywhere on the Web, even at a
gnutella:// URI. In the former case I need to set up a redirect from
/users/paul/bio to the real location.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:917
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-07 19:27:24
Subject:Re: [rest-discuss] Onions in the Varnish
Message:

Jeff Bone wrote:
> 
>...
> 
> The Axiom of Opacity is just such an onion in the varnish of REST
> / the Web.  It's prima facie false;  it should at best be called
> The Conceit of Opacity and at worst The Delusion of Opacity.
> Consider the following contradiction, brought to you courtesy Tim
> Berners-Lee:
> 
> "When you are not dereferencing you should not look at the
> contents of the URI string to gain other information." (Opacity
> Axiom) [2]
> 
> "Looking at this
> [http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm], the
> "pubs/1998" header [sic, he's referring to hierarchical parts of
> a URI -jb] is going to give any future archive service a good
> clue that the old 1998 document classification scheme is in
> progress." [3]
> 
> So we're not supposed to look at the contents of a URI string.
> But here we are looking at the contents of a URI string.
> Hmmm...  where there's a contradiction, there's probably
> confusion, and confusion about and selective application of an
> axiom makes one question the validity of the axiom.

You're right there is confusion. But it is in your mind, not Tim's. The
opacity axiom applies to *software*. One should not write software that
breaks when the form of an HTTP URI changes. It's like not writing a
function that breaks when its first argument is a variable named "foo"
instead of one named "bar". You don't own the caller's namespace and
should make no assumptions about it. Similarly client and intermediary
software does not own the server's namespace and should make no
assumptions about it.

Tim was talking about a *human* reading the URI. That's why he said that
it is a "clue". He's talking about the Web equivalent to variable naming
conventions. As in, you SHOULD use m_ as a member prefix because this
will make reading your code simpler. But I would kill you if you sent me
a piece of software that depended upon member variables starting with
m_. So variable names are opaque, except when they aren't, in exactly
the same way.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:918
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 20:50:28
Subject:Re: [rest-discuss] Onions in the Varnish
Message:


Paul Prescod wrote:

> You're right there is confusion. But it is in your mind, not Tim's. The
> opacity axiom applies to *software*.

Sorry, Paul -- the confusion isn't in my head, it may or may not be in Tim's
head, but it's certainly in yours.  ;-)  Here's why:

Every single browser and probably almost every other sort of Web client on
the planet breaks the opacity axiom each and every day.  URI are not opaque;
they have semantics.  Without those semantics, relative URI would be
impossible.

To say that URI are opaque indicates both sloppiness of language and
terminological (or other worse) confusion.  To assert that it is incorrect to
extract any information from URI, to do anything other than dereference one
--- is contradictory to a very common use of URI which is spelled out in
great detail in RFC2396 -wrt- relative URI.

So once we've dispelled the delusion that URI are *in fact* and by intent /
design opaque, we can get on with our lives and begin to ask what the
structure and semantics of URI names are and how we can enrich those
semantics formally, explicitly, usefully.

> Tim was talking about a *human* reading the URI. That's why he said that
> it is a "clue". He's talking about the Web equivalent to variable naming
> conventions. As in, you SHOULD use m_ as a member prefix because this
> will make reading your code simpler. But I would kill you if you sent me
> a piece of software that depended upon member variables starting with
> m_. So variable names are opaque, except when they aren't, in exactly
> the same way.

Invalid analogy.  URI aren't variable names in a flat namespace, they are
semi-hierarchical names in a structured namespace.  Consider:  every piece of
*Web server software* on the planet builds log files.  These log files are
often named and managed in a hierarchical log space, with log file names
constructed generatively according to some rules or grammar.

jb








-----------------------------------------------------------------------------------
Post ID:919
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 20:39:56
Subject:Re: [rest-discuss] SMB/CIFS
Message:


Paul Prescod wrote:

> I have a resource that represents a user and one that represents a
> user's bio. I could use the namespace: /users/paul/bio or I could use
> hypertext /users/paul#xptr(document(@bio)). In the latter case, the
> thing referenced by @bio can live anywhere on the Web, even at a
> gnutella:// URI. In the former case I need to set up a redirect from
> /users/paul/bio to the real location.

Just to be entirely clear:

You've just pointed out that, in fact, URI can have *more* rather than less semantics than the traditional
/ naive understanding of filesystem pathnames.  (Assuming embedding XPointer/XLink/XPath and related kinds
of things into URI.)

jb








-----------------------------------------------------------------------------------
Post ID:920
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 21:27:51
Subject:Re: [rest-discuss] Onions in the Varnish
Message:


Mark Baker wrote:

> Paul and I are arguing that, without authoritative information to the
> contrary, one should not make assumptions about somebody else's
> namespace.

We're in agreement on that.  The disagreement potentially comes in terms
of what that authoritative information needs to be, how it may be used,
and whether it can be used generatively to construct URI.

> Moreover, we argue that in addition to this, even when
> this authoritative information is available, it should not map to
> a specific relative URI structure, but instead each resource should
> be classified as the expected type independant of its name, and
> as part of the same aforementioned authoritative information.
>
> Jeff appears to agree with the first part, per his response to me
> about signifying the "implementation" of a relative URI structure
> by exposing that as a "feature" URI.  But he disagrees with the
> second part.
>
> Is that a fair characterization?

More or less.  I'm not suggesting that the abstract "type" of a resource
be solely identified by its URI;  I am however suggesting that abstract
"type" information may be profitably embedded in URI, and that (with
appropriate rules and information for doing so, provided presumably by
the owner of the URI) that "type" and other useful information may be
inferred from nothing more than URI.

Note I'm specifically not talking about content type --- that would be a
very bad idea --- but a somewhat fuzzier notion of ontological "type,"
i.e. how that resources stands in relation to other resources in the same
information subspace and what other resources might be there.

jb








-----------------------------------------------------------------------------------
Post ID:921
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-07 21:34:56
Subject:Re: [rest-discuss] Onions in the Varnish
Message:

Jeff Bone wrote:
> 
>...
> 
> Sorry, Paul -- the confusion isn't in my head, it may or may not be in Tim's
> head, but it's certainly in yours.  ;-)  

Why don't we quit this line of discussion. It's unnecessarily
inflammatory to presume that because someone disagrees with you they
must not have thought through the issues. In fact I had all of the same
questions when I first heard that URIs are opaque. Luckily, there is a
document that discusses opacity, query parameters, relative URIs and so
forth. It was written in 1996, perhaps years after Tim Berners-Lee went
down the same mental paths you are. I went through them around six
months ago. I haven't done a comparison to various file systems but I
have thought through what opacity means in this context and when it
applies and doesn't. That's why I've been telling people, for example,
to use query parameters when opacity is not appropriate and slashes when
it is.

> ... Here's why:
> 
> Every single browser and probably almost every other sort of Web client on
> the planet breaks the opacity axiom each and every day.  URI are not opaque;
> they have semantics.  Without those semantics, relative URI would be
> impossible.

As long as you restrict yourself to the semantics described in the URI
specifications, I have no argument. Those are shared agreements that
software reliably implements. When you start inventing naming
conventions you are going beyond that and starting to embed *application
semantics* in URIs. Software that depends upon this will be fragile in
the face of changes in URIs. Insofar as URIs are tied to servers, they
will be fragile in the face of resource moves to other servers. This can
only be mitigated through expensive redirects.

> To say that URI are opaque indicates both sloppiness of language and
> terminological (or other worse) confusion.  To assert that it is incorrect to
> extract any information from URI, to do anything other than dereference one
> --- is contradictory to a very common use of URI which is spelled out in
> great detail in RFC2396 -wrt- relative URI.

URIs are opaque at the application level. Client software should not
inspect URIs to try and figure out the structure of a server's data
model.

Relative URIs are a syntactic shortcut like a macro. Like a macro, they
are provided by the person who created the data. If the *client* started
inventing relative URIs, by adding ".."s etc., it would be a violation
of application-level URI opacity.

> So once we've dispelled the delusion that URI are *in fact* and by intent /
> design opaque, we can get on with our lives and begin to ask what the
> structure and semantics of URI names are and how we can enrich those
> semantics formally, explicitly, usefully.

You have to make a case that there is value in enriching those
semantics. So far all I've seen is: "this thing that can be done with
hypertext. We could also do it in a different way with namespaces." The
confusion caused by relative URIs demonstrates that the current level of
"rewriting semantics" already causes a problem. It was confusing for me
at first also. I presumed that HTTP's notion of containment and URI's
notion of containment were related. They are not. HTTP's is a *public*
containment that client and server should share. URIs is a *private*
containment that is owned by the server and used by the client only
under strict server control...in other words with "..".

> > Tim was talking about a *human* reading the URI. That's why he said that
> > it is a "clue". He's talking about the Web equivalent to variable naming
> > conventions. As in, you SHOULD use m_ as a member prefix because this
> > will make reading your code simpler. But I would kill you if you sent me
> > a piece of software that depended upon member variables starting with
> > m_. So variable names are opaque, except when they aren't, in exactly
> > the same way.
> 
> Invalid analogy.  URI aren't variable names in a flat namespace, they are
> semi-hierarchical names in a structured namespace.  

From the client's point of view it *is* a flat namespace. That's just
the point.

URIs have hierarchical parts *only* to allow relative URIs:

RFC 2396:
>    It is not necessary for all URI within a given scheme to be
>    restricted to the <hier_part> syntax, since the hierarchical
>    properties of that syntax are only necessary when relative URI are
>    used within a particular document.

And relative URIs *only* exist as a shortcut syntax for the maintenance
of human-authored documents:

>    Relative addressing of URI allows document trees to be partially
>    independent of their location and access scheme.  For instance, it is
>    possible for a single set of hypertext documents to be simultaneously
>    accessible and traversable via each of the "file", "http", and "ftp"
>    schemes if the documents refer to each other using relative URI.

In other words' it is a hack to get around the fact that rewriting URIs
is a pain and not even feasible with primitive software like FTP
servers.

> ... Consider:  every piece of
> *Web server software* on the planet builds log files.  These log files are
> often named and managed in a hierarchical log space, with log file names
> constructed generatively according to some rules or grammar.

So software ignores web architecture. What a surprise! This could easily
be handled with either hypertext links or query parameters.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:922
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 22:30:32
Subject:Re: [rest-discuss] Onions in the Varnish
Message:

Detailed but concise responses to many incorrect or invalid assertions.

Paul Prescod wrote:

> Jeff Bone wrote:
> >
> > Sorry, Paul -- the confusion isn't in my head, it may or may not be in Tim's
> > head, but it's certainly in yours.  ;-)
>
> Why don't we quit this line of discussion. It's unnecessarily
> inflammatory to presume that because someone disagrees with you they
> must not have thought through the issues.

You opened that line of argument.  I just tossed it back with a winky. ;-)  I would
prefer not to engage that way, but you did (and continue to, below) presume the
very thing you're encouraging me not to presume about you.

> In fact I had all of the same
> questions when I first heard that URIs are opaque.

It's incorrect (and, as you've asserted above, unnecessarily inflammatory) to
assume that this is a first reaction to URI opacity on my part.  On the contrary,
as I've mentioned in private correspondance to you previously, my starting point
circa my REST gestalt mid last year was to accept all of it --- including URI
opacity --- on faith.  My current POV is the result of a critical examination of
that acceptance of the whole rather than specific parts.  My current conclusions
are not the result of a process of initial non-acceptance.

> Luckily, there is a
> document that discusses opacity, query parameters, relative URIs and so
> forth. It was written in 1996, perhaps years after Tim Berners-Lee went
> down the same mental paths you are.

I'd be very surprised if, either in the course of the discussion here or in the
pages I've been working on in the Wiki, I haven't cited the document you mention.
I would be even more surprised if I haven't already read that document and, indeed,
based part of my current thinking on it.

> I haven't done a comparison to various file systems

Then you are insufficiently prepared.

> As long as you restrict yourself to the semantics described in the URI
> specifications, I have no argument. Those are shared agreements that
> software reliably implements. When you start inventing naming
> conventions you are going beyond that and starting to embed *application
> semantics* in URIs.

No, you are embedding information modeling semantics in URI.  HTTP is the
application.  And this should be no more or less acceptable than using, say,
arbitrary XML Schemata or RDF.  Again, if it's not clear, I'm *not* suggesting that
URI be given "naked semantics."  I am suggesting that explicit and possibly
extensible semantics can be given by specific namespace owners to specific sets of
URI w/o the Web coming to an end.

> Software that depends upon this will be fragile in
> the face of changes in URIs.

This is a myth, cf. the Wiki.  Short version:  this is no more a problem than is
schema evolution, etc. in RDF ontologies.  To the extent that software might be
fragile in the face of good, disciplined use of structured naming, that's IMO poor
software design causing the fragility.

> Insofar as URIs are tied to servers, they
> will be fragile in the face of resource moves to other servers. This can
> only be mitigated through expensive redirects.

This is a red herring.  URIs are already tied to servers.  Recognizing and
exploiting the semantics of the path component of a URI doesn't make the URI any
more or less susceptible to this problem.

> URIs are opaque at the application level. Client software should not
> inspect URIs to try and figure out the structure of a server's data
> model.

This is trivially incorrect.  Relative URI are an example of how client software
can and does inspect URI to determine certain things about the structure of a
server's data model.

> Relative URIs are a syntactic shortcut like a macro. Like a macro, they
> are provided by the person who created the data. If the *client* started
> inventing relative URIs, by adding ".."s etc., it would be a violation
> of application-level URI opacity.

Big deal.  If the server (or some other agency) provides explicit information about
the structure of its names and their associated semantics then there's no downside.

> You have to make a case that there is value in enriching those
> semantics.

No, you have to make the case that there isn't.  Extraordinary claims require
extraordinary proof.  TBL's assertion of the axiom is the extraordinary claim,
counter to the majority of all namespace and filesystem research out there today.

> So far all I've seen is: "this thing that can be done with
> hypertext. We could also do it in a different way with namespaces."

That's not true, I have already given you a very particular example of how
generative names can be used that is impossible to accomplish with hypertext.  With
generative names, it might be possible to crawl a site to "find the page that isn't
linked to by any other page."  Using strictly the hypergraph topology, this is
impossible.  This is a trivial but I think evocative example.

> > Invalid analogy.  URI aren't variable names in a flat namespace, they are
> > semi-hierarchical names in a structured namespace.
>
> >From the client's point of view it *is* a flat namespace. That's just
> the point.

Only by virtue of the Axiom of Opacity.  You can't use the Axiom of Opacity to
prove the validity of the Axiom of Opacity.  Next thing you know you'll be telling
me that everything in the Bible is true because it's God's Word, and we know that
because the Bible tells us so.

> > ... Consider:  every piece of
> > *Web server software* on the planet builds log files.  These log files are
> > often named and managed in a hierarchical log space, with log file names
> > constructed generatively according to some rules or grammar.
>
> So software ignores web architecture. What a surprise! This could easily
> be handled with either hypertext links or query parameters.

My point is to illustrate that useful and simple examples of generative naming
abound throughout all types of software.  Why do you think Web server
implementations use such a non-Webby concept as structured naming to manage
logfiles, rather than using some other hypermedia concept or what have you?  Could
it be because there are benefits to doing so?

jb







-----------------------------------------------------------------------------------
Post ID:923
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-07 17:39:18
Subject:Re: Offer/acceptance
Message:

Mark Baker wrote:

> > 1. offer-ack
> > 2. businessResponse-ack
> > where businessResponse could be "accept", "reject" or some 
variation 
> > on "let's negotiate, I will make a counter-offer next".
> 
> Just to clarify, is "ack" a business level ack ("got your offer,
> I'll check it out and get back to you"), or a transfer level ack
> ("received your message")?

In RosettaNet and ebXML it's called "receipt acknowledgment" which 
means "message received" and "schema validated". It is business-level 
but should be done quickly and automatically and the contents can be 
stereotyped.  It may require non-repudiation of receipt (e.g. digital 
signature).  The contents would be archived in a transaction log, 
which I think should be part of the resource model.

There could be other complications, too, but I'll spare you for now.







-----------------------------------------------------------------------------------
Post ID:924
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-07 22:31:10
Subject:Re: Offer/acceptance
Message:

I tried to reply to this earlier, but it apparently went off into 
space.  I got the message earlier that there was something amiss with 
my Yahoo groups profile, and tried to fix it, and the next reply was 
published quickly.  Don't know what happened to the last one.  If 
this one disappears, I'll try deleting and re-adding my membership 
with a new user id.  The problems started to appear after the recent 
Yahoo groups outage, although that may have been coincidental.

Mark Baker asked [about offer-ack]:
> Just to clarify, is "ack" a business level ack ("got your offer,
> I'll check it out and get back to you"), or a transfer level ack
> ("received your message")?

The acks are business-level, but simple.  In RosettaNet and ebXML, 
it's called a "receipt acknowledgment" and means "received" 
and "schema validated".  Non-repudiation of receipt may be required. 
The receipts would go into a transaction log, which I think should be 
part of the resource model.

There could be other status messages and complications depending on 
the business process model, but those will do for starters and 
everything else would be a variation.

-Bob Haugen









-----------------------------------------------------------------------------------
Post ID:925
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 20:36:32
Subject:Re: [rest-discuss] SMB/CIFS
Message:


Paul Prescod wrote:

> You're going to have to provide some evidence for that statement. For
> instance how does .NET in any way remove a level of indirection from the
> filesystem?

It doesn't remove a level of indirection from the filesystem, it uses filesystem-based objects
(assemblies) to store all necessary metadata in a self-contained fashion.  Cf. "Avoiding DLL Hell:
Introducing Application Metadata in the Microsoft .NET Framework" [1]

> I have a resource that represents a user and one that represents a
> user's bio. I could use the namespace: /users/paul/bio or I could use
> hypertext /users/paul#xptr(document(@bio)).

So, just to point something out:  you've introduced semantics into that name.

The point is that whatever interprets these names --- whether human or Web server or servlet or enhanced
shell (as with ksh98) or kernel namespace manager (as with Plan 9, Linux, etc.) --- can be made to
understand the latter.  Indeed the kind of thing you're doing with that name is precisely the kind of
thing e.g. Reiser would like to accomodate for "file" name resolution in the operating system:  "semantic
naming."

Furthermore, there's absolutely no reason why I can't (using some sophisticated file namespace mechanism
such as custom extensions to 3DFS) provide a mapping from /users/paul/bio to resolve to
/users/paul#xptr(document(@bio)).  Indeed, in the long run I truly believe that the boundaries between the
Web and filesystems must dissolve and the location dependencies of *both* mechanisms must go away.  But
that's a later argument;  let's stick with debunking the Delusion of Opacity and eliminating the dangers
of tossing out structured semantic naming without good justification.

A namespace is a namespace.  It's all about how you manipulate them and how you interact with them.  I'm
specifically *not* stating that traditional UNIX-like pathnames have the power and flexibility and so
forth of URI, nor am I advocating any move away from URI.  What I am pointing out is that the same level
of name resolution and indirection from symbolic names to lower-level objects (representations, local
device:inode pairs, etc.) happens both in the Web and in filesystems, and that filesystems have obtained
positive benefit by not being delusional about name opacity.

jb

[1] http://msdn.microsoft.com/msdnmag/issues/1000/metadata/metadata.asp









-----------------------------------------------------------------------------------
Post ID:926
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-07 18:12:31
Subject:Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

Jeff Bone wrote:
> 
>...
> 
> Well, there's no reason to believe that the benefits or small, large, or otherwise in the
> absence of a more detailed investigation of relaxing the opacity axiom.  But without such an
> investigation --- substituting dogma for research --- one can't really speak authoritatively
> about such things.  

Well, go do the research! I have not run into any problems that name
transparency would help me to solve. The examples you've presented have
been trivially solvable with hypertext, using existing techniques.  You
admit that making name-based navigation work as well as hypertext
navigation would require a bunch of new standards, so I think you need
to demonstrate that there is some payoff for that effort. Here are the
advantages I've heard you cite:

 1. Guessability for humans -- nobody disputes the value of this. But
the authoritative way to navigate for humans must be hypertext. i.e.
I'll kick your ass if you build a site with a /search but no search
button. On the other hand, having a search button that goes to
www.google.com rather than /search seems acceptable to me. So you may
create URIs that are readable but you should ACT as if they are opaque.

 2. Guessability for computers -- the only way you could make things
guessable for computers is to invent this "generative grammar" thing.
First, we already have most of that in HTML forms and XForms. Second,
guessability is never as good as certainty and certainty can be provided
more easily through hypertext. You say: "A program armed with a grammar
for constructing resource names from hierarchical components and a
further declarative description of the semantics of each part ---
potentially in RDF --- could similarly 'discover' information in a sort
of gestalt rather than deductive fashion." You do not demonstrate why
this is better. By the way, note that in Unix it is common to "discover"
new files by going to a directory and getting a listing. Getting a
listing in HTTP is doing a GET and parsing the XML. Unix programs do not
discover the list of new processes by poking at /proc/random_number.
Rather they do an LS and *parse the result* (semantically...of course
this is not precisely what happens in C programs).

3. As a resource modeling tool -- if you treat this as similar to 1., I
have no problem with it. Make meaningful names for communication among
humans and then write software that treats the names as meaningless.

> ... It seems to me that the Opacity Axiom is overstated and overapplied, and
> I've documented some few of the many reasons why embedding information in names is in fact
> useful, not anathema as the dogma states.

Nobody, anywhere, would say that it is bad to embed information names.
The problem is making names the canonical source for information.

> As for the horrors of new schema languages, conventions, and interface definition systems...
> WRDL?  I rest my case.  If you're going to argue, you should at least try not to argue with
> yourself. ;-)  (Sometimes, that's hard --- trust me, I know. ;-)

WRDL is based on the notion that the hypertext is the definitive means
for navigating between components. If we made names the definitive means
then your new language would probably be a appropriate. But as I
understand it, what you are arguing is that we should have both. Names
should be the definitive in some circumstances and hypertext in others.
That means we need both WRDL (or something like it) and a generative
grammar language. We need both WRDL's notion of a resource type and your
notion of a URI interface type. Until I hear some compelling advantages
for having two different, parallel authoritative navigation mechanisms,
I'd rather apply Occam's razor.

>...
> (b)  The "standardization" issue is also a red herring, as I've already illustrated.  It
> hardly matters whether what's being "standardized" (let's be more clear, specified by any and
> all who want to specify such things, independent of any central authority) is N3 notation for
> ontologies of resources or some other mechanism for specifying generative grammars for names
> and information organizational conventions.

Let's be 100% clear about how we each see things working. 

My model: Somebody gives me a URI, like
"www.foobar.com/blahservice.xml". I expect my software to be able to
look at that XML document and see if it is in a vocabulary it knows
(probably through an XML namespace or doctype). If it is, I expect it to
be able to follow all links and access the complete service through
hyperlinks. It may have a WRDL that describes the service or it may just
run with no validation. If it isn't a vocabulary I've ever heard of then
in theory I may one day be able to use RDF to figure out the semantics
of the service (okay, I doubt it, but the semantic web people seem to
believe it so I'll mention it). 

Now what do YOU propose? I look at the URI document and then I take its
name and tack on a /jeffsnamingconventions or a /paulsnamingconventions
or a /mikesnamingconventions, etc., etc. until I get a "hit"? When I
find a hit I know what generative grammar it is using and I construct
other names based on the base name?

>...
> Well, you are in essence asserting that all attempts to embed semantics and use meaningful
> names to structure systems of resources --- including such incredibly powerful and yet
> incredibly misunderstood efforts like Plan 9 --- is poor software design.  

The value of namespaces as organizational tools depends heavily on the 

a) flexibility of the namespaces, 
b) the ease or difficulty of constructing new namespaces, 
c) the introspection tools availble for navigating namespaces, 
d) the ease of having adjacent names stand for things on physically
distant devices 
e) the extent to which the user will use namespaces as a navigation
mechanism
f) the extent to which it is important to decentralize namespace
standardization

etc.

Plan 9:

a) It has *per process* namespaces, so you can't get much more flexible
then that. 
b) Obviously constructing namespaces in Plan 9 is very cheap since it
can be done in user space
c) plan 9, like every operating system, has an "ls" command. It returns
a document with name-value pairs where the values can be pointers
elsewhere. The web has GET. It returns hypertext which typically embeds
name-value pairs where the values can be pointers elsewhere
d) plan 9 namespaces are "client-side" (i.e. in the process) so two
seemingly adjacent things can be arbitrarily far apart in physical space
with no runtime expense
e) In unix-like systems, namespace navigation is a primary tool for
navigating information. Hyperlinks are not a first-class concept.
f) in plan 9, "Although there is no global name space, for a process to
function sensibly the local name spaces must adhere to global
conventions" This is okay when you are designing an operating system,
because you already expect people to "port" their software to your OS. I
don't want to "port" applications from one web site to another.

In plan 9, "the command 

cat /proc/*/status

is a crude form of the ps command; the actual ps merely reformats the
data so obtained."

Note that the cat command does not use some form of generative grammar.
Rather the command line processor parses the logical output of an "ls"
on /proc and then works with those files. The command is almost legal
XPath syntax although the semantically equivalent XPath would look more
like:

http://www.machine.com/processes#xprt(document(//proc/status))

(if we presume that status's live in a separate document rather than the
same one)

> ... You make this
> assertion with very little backup, and contrary to the prevailing opinion of some of the
> world's most influential computer scientists.

Once again you're shifting around. I'm talking about good application
design in a system with the constaints of the Web or (to some extent)
CIFS/SMB. Plan 9 is a totally different world because Plan 9 is an
*operating system* not just a file system and it manages many things in
the kernel that we cannot do on the Web. Yes, if we could push namespace
merging onto the client side on the Web then of course that would be a
very powerful tool. In fact, hypertext is all we can transmit to the
client side so in essence we do namespace merging using hypertext.


>...
> It does nothing of the sort.  It poses an abstract organization of resources in a
> quasi-hierarchical namespace.  It doesn't at all necessarily assume that the breakdown by
> years is the only possible naming structure (others might simultaneously exist) or that the
> objects are going to "reside on the same disk."  (Check out NTDFS, AT&T 3DFS, Sun's
> Translucent File System, the FiST stackable filesystem toolkit, and other filesystems to see
> why you're wrong in your presumption.)  It might be a bad software design if those
> presumptions were true, but the fact that you make those presumptions simply illustrates a
> lack of understanding of the flexibility and utility of the filesystem namespace in many
> modern filesystems.

That only works because you have *kernel support* for making namespaces
look very different than physical layout. The web *has no such thing*. I
can't have a file "appear to be" on one machine for one user and on
another machine for another user without considerable runtime expense
and complexity.

> > I already have
> > this problem when I want to move my massive trash folder to a different
> > disk than the other mail messages.
> 
> Yes, no doubt, this is a huge problem.  Most workday local filesystems couple the namespace to
> the underlying storage space in unpleasantly tight ways.  This is one of the problems we're
> addressing at Deepfile.

Once you address it on the Web we'll be able to use namespaces as an
organizational tool on the Web.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:927
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-07 21:12:01
Subject:Re: [rest-discuss] Onions in the Varnish
Message:

I'm not sure there's as much disagreement as we might think.

Paul and I are arguing that, without authoritative information to the
contrary, one should not make assumptions about somebody else's
namespace.  Moreover, we argue that in addition to this, even when
this authoritative information is available, it should not map to
a specific relative URI structure, but instead each resource should
be classified as the expected type independant of its name, and
as part of the same aforementioned authoritative information.

Jeff appears to agree with the first part, per his response to me
about signifying the "implementation" of a relative URI structure
by exposing that as a "feature" URI.  But he disagrees with the
second part.

Is that a fair characterization?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:928
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-07 23:22:23
Subject:Opacity Myths Debunked, Kinds of Names
Message:

I've started a page on the Wiki [1] which attempts to capture and
debunk some of the "myths" about name opacity that we've
discussed here and that commonly occur elsewhere.  I'm interested
in collecting more myths to add to this page, so let me have 'em
if you've got 'em. :-)

I've also got the rough outline of a page [2] on the different
kinds and qualities of names.  It's barely an outline at this
point;  what I'd like to do with it is ultimately construct a
taxonomy of different kinds of names and a table of the
operations and characteristics each supports.  In my own
investigation of opacity I've concluded that the refusal to
recognize the differences between names and addresses by e.g. TBL
is probably more of a historical / cultural response to the
contentiousness of discussing various ideas about naming and
identity in the early Web than it is a well-formed technical
viewpoint.  I'd like to clear out the fog of confusion a bit and
give us a vocabulary to use in discussing names and their
applications.

$0.02, and feedback welcome,*

jb

[1] http://conveyor.com/RESTwiki/moin.cgi/OpacityMythsDebunked
[2] http://conveyor.com/RESTwiki/moin.cgi/KindsOfNames

* always welcome, though dogma discouraged. ;-)







-----------------------------------------------------------------------------------
Post ID:929
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-08 01:07:04
Subject:Naming vs. Navigating
Message:

One of the recurring themes in this discussion has been Paul's questioning of why we need naming when
navigating hypertext might suffice.  The answer is that, if both mechanisms were equally expressive, we
wouldn't need both.  But the fact is that navigation and naming aren't equally expressive in all
situations or for all purposes.  There are things you can do --- particularly in dense,
highly-structured information spaces --- which are not possible via traversal of graph structures from
opaque entry points.

Imagine if, whenever I wanted to run "ls" for the first time in a shell process, I had to "crawl" the
directory structure from the root in order to locate the executable.  This would be awful, wouldn't it?

I've provided many examples of how generative naming can be and is used in various contexts to
accomplish things that aren't or are not easily accomplished via navigation from some well-known
starting point.  To recap some of these examples:

  * discovery of "unlinked" but named objects in a namespace
  * creation, maintenance, and access of dense, regular namespaces
    * logging
    * archiving
    * collections of non-hypermedia
  * avoiding user interface navigation
  * programatic use of regular namespaces
    * log managers
    * debuggers -w- /proc
    * system management tools
    * location of executables, libraries, etc. by other programs

Etc. etc. etc.  All of these things benefit from having a priori understanding (via filesystem
organization "standards," conventions, grammars or rules for generating names, etc.)  of namespace
organization and rules for generating names of interest.  All of them operate by de novo synthesis of
semantically-meaningful names in structured namespaces.  None of these operate solely by traversal of
graph structures, even trivial graph structures such as single-rooted filesystem DAGs --- and many (such
as the debugger example) *require* structured name generation.

The value of generative naming and structured namespaces simply can't be questioned, given the ubiquity
of the technique in everything we do with software.  It's preference to navigation *for certain
purposes* should be clear.  Insistence otherwise is, really, pretty silly.

jb








-----------------------------------------------------------------------------------
Post ID:930
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-08 01:19:44
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

Jeff Bone wrote:
> 
>...
> 
> Not true.  For the *fourth* time (counting the Wiki) here's a trivial example that debunks this
> myth, a problem which generative names solve which cannot be solved via hypertext.  You are a Web
> crawler.  Your job is to find all the public objects on a Web server, *including the one or ones
> that are not linked to by other objects.*  

This is ridiculous. Part of your problem statement is to disallow me
from using one of the two tools under discussion. "How would you solve
this problem in Java without using Java."

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:931
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-08 00:45:30
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

Geez, Paul, you're going for an alltime record in how many times one can be demonstrably wrong in a
single e-mail.  Please take the time to read this if we're going to keep this up, as we're now
hitting a point where I'm demonstrating the incorrectness of certain of your assertions *repeatedly*
and yet you keep insisting on them.  I have no problem with *either* being wrong or telling somebody
they are wrong --- mistakes made once are good, but the same mistakes made multiple times are stupid
and annoying.  I'm sorry if that's inflammatory, but if you can't learn, don't argue.

Paul Prescod wrote:

> Well, go do the research! I have not run into any problems that name
> transparency would help me to solve. The examples you've presented have
> been trivially solvable with hypertext, using existing techniques.

Not true.  For the *fourth* time (counting the Wiki) here's a trivial example that debunks this
myth, a problem which generative names solve which cannot be solved via hypertext.  You are a Web
crawler.  Your job is to find all the public objects on a Web server, *including the one or ones
that are not linked to by other objects.*  Generative, structured names can solve this problem.
Hypermedia cannot, as by definition these objects are not part of the hypergraph.

Paul, you can go on asserting till the cows come home that I haven't give you such an example, but
the problem appears to be that you haven't read it, undertood it, and acknowledged it.

> You
> admit that making name-based navigation work as well as hypertext
> navigation would require a bunch of new standards, so I think you need
> to demonstrate that there is some payoff for that effort.

No more, say, than you need to demonstrate the advantages of e.g. WRDL.

> Here are the
> advantages I've heard you cite:
>
>  1. Guessability for humans -- nobody disputes the value of this. But
> the authoritative way to navigate for humans must be hypertext. i.e.
> I'll kick your ass if you build a site with a /search but no search
> button. On the other hand, having a search button that goes to
> www.google.com rather than /search seems acceptable to me. So you may
> create URIs that are readable but you should ACT as if they are opaque.

The last statement is non-sequiter from your example.  But let's be clear:  there is a *difference*
between navigation and directly naming an object.  Both are useful in different contexts.  In
general, however, navigation is more expensive than just simply "going" to the resource in
question.  If in order to get to your search page I must first pull up your front page and click a
link, this is less useful than being able to type in .../search and get to the same place.

>  2. Guessability for computers -- the only way you could make things
> guessable for computers is to invent this "generative grammar" thing.

It's not an invention, we've been using generative grammars for ages.  The question is how and
whether to apply this kind of thing to the Web in order to (a) solve problems hypermedia cannot
solve, such as dealing with objects that do not reside in hypermedia and / or link inconcistencies,
or (b) solve problems that hypermedia can solve but for which name-based solutions are easier, more
useful, or more efficient.

> First, we already have most of that in HTML forms and XForms. Second,
> guessability is never as good as certainty and certainty can be provided
> more easily through hypertext.

I'm not arguing purely for guessability.  Consider:  if I am on a UNIX box, I don't have to "guess"
whether /etc, /dev, etc. will be there --- they will.  I know this because I know the organizational
structure that the OS conforms to and presents through the filesystem.

> You do not demonstrate why
> this is better.

The above example (which you're blissfully refusing to grok ;-) demonstrates one way in which this
is "better" i.e. useful for tasks hypermedia isn't useful for.

> By the way, note that in Unix it is common to "discover"
> new files by going to a directory and getting a listing. Getting a
> listing in HTTP is doing a GET and parsing the XML. Unix programs do not
> discover the list of new processes by poking at /proc/random_number.
> Rather they do an LS and *parse the result* (semantically...of course
> this is not precisely what happens in C programs).

That's true, and this is a good point.  However, programs on various UNIXen *do* indeed "construct"
synthetic filenames synthetically based on conventions, rules, etc.  Debuggers contruct filenames to
reference the /proc/n/mem psuedofile representing the memory of PID n that they are debugging.
Logging systems manipulate filenames of e.g. the form /var/logs/<software>/<year>/<month>/<day> and
so on.  Archives of various things synthesize filenames much like the following to organize the
information they manage.  These things don't "discover" anything by traversing the filesystem from
some well-known entry point;  they have a priori information about how the namespace is organized,
and they use this constructively to manage the information space.

There's several additional examples of the use of structured names that are not and cannot be
accomodated in hypermedia or other navigational metaphors.  In all cases, names are computed rather
than navigated to.

> 3. As a resource modeling tool -- if you treat this as similar to 1., I
> have no problem with it. Make meaningful names for communication among
> humans and then write software that treats the names as meaningless.

That's how this started, in a sense, but the more I thought about it the more I discovered that
structured and semantically-meaningful names were as or even more useful to softare.

> Nobody, anywhere, would say that it is bad to embed information names.

TBL would, and does in his explanation / justification / rationalization of the Opacity Axiom and
elsewhere.

> The problem is making names the canonical source for information.

Did you think I suggested this?  If so, you're wrong.

> > As for the horrors of new schema languages, conventions, and interface definition systems...
> > WRDL?  I rest my case.  If you're going to argue, you should at least try not to argue with
> > yourself. ;-)  (Sometimes, that's hard --- trust me, I know. ;-)
>
> WRDL is based on the notion that the hypertext is the definitive means
> for navigating between components.

So what you're telling me is that invention of new "schema languages, conventions, and interface
definition systems" is a futile activity, to be discouraged and avoided...  unless you're dogma
compliant?  GMAB.  I'm not casting aspersions on your effort at all.  Rather, I believe that such
effort is valid regardless of whether it conforms to doctrine or not, particularly if deviating from
doctrine produces something useful that does not devalue other doctrinologically-appropriate tools.

> If we made names the definitive means
> then your new language would probably be a appropriate. But as I
> understand it, what you are arguing is that we should have both.

What I am arguing is that we *do* have both (relative URI) and that TBL's own Design Principle of
Tolerance as well as the general attention to extensibility and openness in other areas of Web
design argues --- contrary to the axiom --- for opening up the semantics of URI for other purposes,
in effect *truly* allowing namespace owners to use their namespaces as they see fit.  (They already
do the latter;  I'm simply advocating a mechanism to encourage more discipline and consistency.)

> Names
> should be the definitive in some circumstances and hypertext in others.
> That means we need both WRDL (or something like it) and a generative
> grammar language. We need both WRDL's notion of a resource type and your
> notion of a URI interface type. Until I hear some compelling advantages
> for having two different, parallel authoritative navigation mechanisms,
> I'd rather apply Occam's razor.

Occam's razor only applies if the mechanisms (navigation and name generation) are expressively
equivalent.  They aren't, as I've demonstrated repeatedly with my crawler example.  Both models need
to exist.  (Actually, while it's provably true that generative names can do things hypergraph
traversal cannot, the converse has yet to be proven in this discussion.  But I'm generously willing
to grant that it's probably the case that both mechanisms are necessary.)

> My model: Somebody gives me a URI, like
> "www.foobar.com/blahservice.xml".

I completely understand your model.  I took the time to do so.  I rather like it.

> Now what do YOU propose? I look at the URI document and then I take its
> name and tack on a /jeffsnamingconventions or a /paulsnamingconventions
> or a /mikesnamingconventions, etc., etc. until I get a "hit"? When I
> find a hit I know what generative grammar it is using and I construct
> other names based on the base name?

This is a bit of a bad example;  generative names are bad for generating names in sparse
namespaces.  They're good, for example, for calculating the name of a particular archival object
given the name of an earlier one + a syntax for representing time in the name + an understanding of
the "period" of the archive.

> The value of namespaces as organizational tools depends heavily on the

Thanks for the lesson, Paul, I'm quite familiar with Plan 9. ;-)

> > ... You make this
> > assertion with very little backup, and contrary to the prevailing opinion of some of the
> > world's most influential computer scientists.
>
> Once again you're shifting around.

There's a lot of ground to cover in debunking the myth of opacity.

> I'm talking about good application
> design in a system with the constaints of the Web or (to some extent)
> CIFS/SMB. Plan 9 is a totally different world because Plan 9 is an
> *operating system* not just a file system and it manages many things in
> the kernel that we cannot do on the Web.

This argument isn't compelling.  We're talking about the use of namespaces and naming.  There are
similarities.  There are differences.  As long as we don't ignore these, it's possible to use
lessons learned in one in the other context.

> Yes, if we could push namespace
> merging onto the client side on the Web then of course that would be a
> very powerful tool.

Do you think I'm suggesting that?  I'm not.

> In fact, hypertext is all we can transmit to the
> client side so in essence we do namespace merging using hypertext.

The latter assertion is false.  A large majority by volume of the traffic on the Web is not
hypertext but rather opaque media objects.

> That only works because you have *kernel support* for making namespaces
> look very different than physical layout.

This is false.  The very thing I was referring you to which you *clearly* haven't bothered to
investigate --- AT&T's 3DFS --- is a userspace per-process virtual filesystem implementation that
runs on many different platforms with no kernel support at all.

> The web *has no such thing*. I
> can't have a file "appear to be" on one machine for one user and on
> another machine for another user without considerable runtime expense
> and complexity.

This is also trivially false, as demonstrated by (for instance) mirroring, etc.

> Once you address it on the Web we'll be able to use namespaces as an
> organizational tool on the Web.

But I'm not going to be allowed to address it if everybody wants to continue being delusional about
URI opacity. ;-)

jb








-----------------------------------------------------------------------------------
Post ID:932
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-08 02:37:59
Subject:Re: [rest-discuss] Opacity Myths Debunked, Kinds of Names
Message:

The name/location/identifier thing, for whatever reason, was the first
thing I understood about the Web really well.  This was back in 94/95,
before I got the Web.

My view of it, which I got before reading very much of Tim's stuff,
was that you have strings that are used in different contexts for
different purposes.  To a higher layer, an identifier looks like
a location.  To a lower layer, it looks like a name.  That is,
depending upon how you look at it, an identifier is both a name
and a locator.

http://www.markbaker.ca/2001/03/James/ is a string that identifies
my son (who turned 1 today!).  I use it as a name when I ask a cache if
it has a valid representation for me.  I use it as a locator when my
HTTP client stack follows the rules in RFC 2396 to turn it into
something that opens a socket to port 80 on 207.236.3.141.

Rohit had a great presentation at TWIST '99[1], and a spinoff
article[2] in his IEEE column about this.

 [1] http://www.isr.uci.edu/events/twist/twist99/presentations/khare/
 [2] http://www.isr.uci.edu/~rohit/IEEE-L7-namespaces.html

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:933
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-08 05:14:41
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:


Paul Prescod wrote:

> This is ridiculous. Part of your problem statement is to disallow me
> from using one of the two tools under discussion. "How would you solve
> this problem in Java without using Java."

The above Java example *is* ridiculous --- it's a problem that would never occur in real life.  The
example I've offered is something that might easily occur --- consider densely packed regularly named
namespaces full of opaque media objects without links between them.

I'm denying you your tool because, in some cases, your tool doesn't work, or because it's more work to
make your tool work than to make other tools work.  Hammer, nails, etc.

jb








-----------------------------------------------------------------------------------
Post ID:934
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-08 05:28:31
Subject:Hammer / Nail / Screwdriver
Message:


Paul Prescod wrote:

> This is ridiculous. Part of your problem statement is to disallow me
> from using one of the two tools under discussion. "How would you solve
> this problem in Java without using Java."

Actually, on more reflection, your pushback is incredibly ridiculous.  You're saying "I have a phillips
head screwdriver.  I can drive any screw with this.  Prove me wrong by showing me something I can't
screw in with this."  I'm saying "fine, here's a regular screw.  Screw it in with your phillips head
screwdriver.  You can't."  And you're getting petulant and complaining that I'm invalidating your
assertion by giving you something other than a phillips head screw.

jb








-----------------------------------------------------------------------------------
Post ID:935
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-08 06:33:56
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> > This is ridiculous. Part of your problem statement is to disallow me
> > from using one of the two tools under discussion. "How would you solve
> > this problem in Java without using Java."
> 
> The above Java example *is* ridiculous --- it's a problem that would never occur in real life.  The
> example I've offered is something that might easily occur --- consider densely packed regularly named
> namespaces full of opaque media objects without links between them.

Now you've given me a problem statement: "How would you handle densely
packed regularly named namespaces full of opaqaue media objects without
links between them." Fine. By saying "between them" you've opened the
door for me to add hypertext that links the documents externally. In
other words I'm now allowed to use the tool I'm supposed to compare.

I'm presuming I have control over the server because otherwise I can't
solve this using either a regular naming convention or a hypertext
solution. If the graphics use random names and are not linked somehow
then the robot is screwed either way.

So given that I control the server, I can simply write a CGI that
generates an index document that creates links to the opaque objects a
la images.google.com. If there is a reason to want to get indexes just
of subsets of them then my CGI would do that too (c.f.
images.google.com). If the files are reliably named then this CGI should
take about an hour to write. As the service provider I can trivially
include images in the set that are not physically stored on the server
because the URIs can point anywhere on the Web.

Now if I am JUST the spider writer and I have no opportunity to
co-ordinate with the service creator then I may be reduced to hacking.
I'm trying to get information out that the service provider did not give
me explicit access to. Guessing predictable filenames might be an okay
hacking technique in some circumstances. Poking around for a hypertext
index might be another good technique in some circumstances. I could
also try to see if there was an FTP interface or perhaps a known
security hole I could exploit. ;)

> I'm denying you your tool because, in some cases, your tool doesn't work, or because it's more work to
> make your tool work than to make other tools work.  Hammer, nails, etc.

Now that you've stated the problem as a problem, I've applied my hammer
and as far as I can see it works fine.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:936
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-08 16:08:56
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:


Paul Prescod wrote:

> Now you've given me a problem statement: "How would you handle densely
> packed regularly named namespaces full of opaqaue media objects without
> links between them." Fine. By saying "between them" you've opened the
> door for me to add hypertext that links the documents externally. In
> other words I'm now allowed to use the tool I'm supposed to compare.

Sorry, "without links to them."  Bottom line, Paul --- although everything on the Web *can* be linked to,
not everything is.  Yet everything that is nameable by a URI --- regardless of whether it has inbound or
outbound links in some hyperstructure --- is still part of "the Web."

The Web enables hypertext.  It is not defined by it, nor is it intended to be constrained by it.  The
statement "hypermedia is the engine of application state" is another onion in the varnish, a hypermedia
enthusiast's statement of opinion about the Web rather than a true principle of its design, IMO.  It seems
to me that, by itself, HTTP is the application, not XML or HTML.  It seems to me, after months of
consideration, that the problem with Roy's formulation of REST is not that it is too constraining but rather
that it is *not constraining enough* --- it fails to separate the concerns of generic resource modeling and
representational state transfer from the concerns of a particular kind of state that might be transferred,
i.e. hypermedia.  But that's a later argument.

I'm working on a set of examples for the Wiki beyond the one I've repeatedly offered which illustrate how
dispensing with the pretext of opacity enables some things that are not possible simply through graph
traversal from an opaquely-named entry point and how it simplifies and makes many other things more
efficient.  I'll post here when that is ready for perusal.


> Now if I am JUST the spider writer and I have no opportunity to
> co-ordinate with the service creator then I may be reduced to hacking.

Yes, you are reduced to "hacking" in this case --- *because* of opacity.  (The limitation to being the
spider writer should've been clear in the original problem statement.)  Dispensing with opacity and
introducing explicit information about organizational schemes and the specific semantics of structured names
elevates that activity to something more disciplined.

> Now that you've stated the problem as a problem, I've applied my hammer
> and as far as I can see it works fine.

No, you seized on a misstatement of mine (I incorrectly said "between" when "to" was the more limiting
statement I was going for, and indeed used in earlier formulations) and ran with it.  Further, you ignored
one basic premise that was clear, namely that your task was constrained by virtue of not being in local
control of the resources in question.

jb


>
>
>  Paul Prescod
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:937
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-08 16:45:20
Subject:Clarification and the dimensionality of URIspace
Message:

I'm not proposing --- despite examples yesterday which might imply
something to the contrary --- both that URI be considered transparent
*and* that the semantics of e.g. '/', ';', and '?' subject to
redefinition by any namespace owner.  I might've confused the discussion
when I talked about the possibility of using '/' to mean set
intersection;  that's sort of an extreme example, not something you're
really want to do.  Informally, '/' should only be used to indicate
traversal of  "links" in a graph-structured namespace.  That is, given a
partial path

    a/b/

then the following should hold

    a/b/.. ==  a/

I'm not at all trying to redefine the semantics associated with existing
URI syntax, just trying to point out that those semantics do indeed
exist and can be usefully exploited.  As Mark indicates in notes on his
own opacity investigation, the existing URIspace has several
well-defined dimensions or degrees of freedom.  '//' selects between
roots in a (flat or hierarchical, depending on whether hostnames are
opaque) namespace;  '/' traverses named links in a single-rooted
graph-structured namespace rooted in the authority, yielding a
two-dimensional object, a directed graph.  The addition of properties
via ';' introduces a third dimension to the namespace.  The query string
'?' turns each "point" in an arbitrary number of so-far three
dimensional spaces into its own namespace of arbitrary dimensionality or
degree.

There are some conclusions that can be drawn from this.  '/' should
*only* be used to represent graph-oriented (commonly incorrectly called
"hierarchical") relationships.  Conversely, *all* such relationships
*should* be represented by use of '/'.  This is my beef with shoving
stuff into query parameters out of some poorly-conceived concern for
opacity;  when you push information into the query string, you lose the
information about the graph-oriented relationships between the parts.
This is a bad thing;  we've got a syntax for representing that
information in URI, but concern for "opacity" means that generally
speaking we often can't use it, with the result being less meaningful
names.

jb








-----------------------------------------------------------------------------------
Post ID:938
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-08 17:51:41
Subject:Re: [rest-discuss] Onions in the Varnish
Message:

>
> URIs are opaque at the application level. Client software should not
> inspect URIs to try and figure out the structure of a server's data
> model.

Is it okay for a client to be /told/ what the structure of a server's data
model (with respect to URIs) is? and then do URI munging?








-----------------------------------------------------------------------------------
Post ID:939
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-08 18:12:40
Subject:Re: [rest-discuss] Clarification and the dimensionality of URIspace
Message:

----- Original Message -----
From: "Jeff Bone" <jbone@...>

> [...] Informally, '/' should only be used to indicate
> traversal of  "links" in a graph-structured namespace.  That is, given a
> partial path
>
>     a/b/
>
> then the following should hold
>
>     a/b/.. ==  a/
>
This is harder than it looks, if 'b' has more than one incoming pointer
('parent').
Doing lexical operations (fiddling with just the text) will work. Actually
doing the traversals might not work if the traversal algorithm doesn't
remember its sequence of traversed nodes - which implies that ".." will work
only in the context of the full request/transaction/session/whatever. Doing
something like this probably would fail:

 get("a").get("b").get("..")

since get("b") rips the state of the resource out of its context.






-----------------------------------------------------------------------------------
Post ID:940
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-08 19:28:57
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> > Now you've given me a problem statement: "How would you handle densely
> > packed regularly named namespaces full of opaqaue media objects without
> > links between them." Fine. By saying "between them" you've opened the
> > door for me to add hypertext that links the documents externally. In
> > other words I'm now allowed to use the tool I'm supposed to compare.
> 
> Sorry, "without links to them." 

Oh, I see. We're back to "Java can't implement this solution unless you
use Java."

> ... Bottom line, Paul --- although everything on the Web *can* be linked to,
> not everything is.  Yet everything that is nameable by a URI --- regardless of whether it has inbound or
> outbound links in some hyperstructure --- is still part of "the Web."

How do we find things that are part of the Web but not hyperlinked? You
say by working with names. But that only works a tiny, tiny, tiny
fraction of the time. Most of the time you can't find things by guessing
at their names. That only works when you have an agreement with the
website author. Why wouldn't they express that agreement through
hypertext (which is already deployed) rather than a generative grammar
language (which isn't)? I'm still waiting for a use case.

If you invent a generative grammar language for the Web, I will write a
CGI program that allows generative grammars to generate hypertext
documents so that the Web subsumes that functionality *through
hypertext*.

> ...  It seems
> to me that, by itself, HTTP is the application, not XML or HTML.  It seems to me, after months of
> consideration, that the problem with Roy's formulation of REST is not that it is too constraining but rather
> that it is *not constraining enough* --- it fails to separate the concerns of generic resource modeling and
> representational state transfer from the concerns of a particular kind of state that might be transferred,
> i.e. hypermedia.  But that's a later argument.

If we define hypertext as "text with links" then it becomes clear that
anything you can represent with plan 9 namespaces I can represent with
text with links. The only question is whether the system is closed over
hypertext or closed over namespaces or neither. If we obey the opacity
principle then it will become closed over hypertext because things
without links to them would by definition not be on the Web. But thanks
to query parameters and URIs the set of things with links to them is
infinite.

>...
> Yes, you are reduced to "hacking" in this case --- *because* of opacity.  

No, I'm reduced to hacking because I'm trying to get access to
information (the listing of files) that was not provided to me. If it is
provided to me as hypertext or a generative grammar I am equally able to
get access to it.

> ... (The limitation to being the
> spider writer should've been clear in the original problem statement.)  Dispensing with opacity and
> introducing explicit information about organizational schemes and the specific semantics of structured names
> elevates that activity to something more disciplined.

Okay you're the spider writer. I've just put ten .gif files on my
website. Really. To help you along I put your first name in their file
names. Go find them. (Please don't brute force my service provider.) If
you show me how to solve the problem with namespaces I'll show you how
to do it with hypertext.

Either the webiste owner is working with you or not. If they are not
working with you then there is no reason to believe the names will be
consistent because *they own the server side namespace and can name the
graphics whatever they want*. That isn't unique to the Web. Every
operating system I've ever used allows you to name things more or less
whatever you want. Every programming language I've ever used allows you
to name things more or less whatever you want. Are you saying the Web
should enforce predictable names?

If they are working with you then the tried and true and 100% effective
way for them to do so is to provide hypertext (either static or dynamic)
that provides access to the documents.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:941
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-08 18:23:45
Subject:Re: [rest-discuss] Re: Offer/acceptance
Message:

> > Just to clarify, is "ack" a business level ack ("got your offer,
> > I'll check it out and get back to you"), or a transfer level ack
> > ("received your message")?
> 
> In RosettaNet and ebXML it's called "receipt acknowledgment" which 
> means "message received" and "schema validated". It is business-level 
> but should be done quickly and automatically and the contents can be 
> stereotyped.  It may require non-repudiation of receipt (e.g. digital 
> signature).  The contents would be archived in a transaction log, 
> which I think should be part of the resource model.
> 
> There could be other complications, too, but I'll spare you for now.

Ok, so let's say we have this resource which is the thing that is
being negotiated for;

http://company1.com/thing

So company2 becomes aware of this thing, and wants to make an offer for
it.  So it does a GET on that URI and retrieves some RDF asserting that
it is of type http://stds.org/product.  company2 knows this means that
it can submit an offer document to that URI, so it puts one together and
POSTs it there.  company1's software receives the offer, and can do
one of two things;

- respond with an "Acceptance" document immediately
- respond with an "Ack" document, which includes a URI that refers
to the Acceptance or Rejection document in the future.

How's that?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:942
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-08 21:59:56
Subject:Re: [rest-discuss] Clarification and the dimensionality of URIspace
Message:


"S. Mike Dierken" wrote:

> This is harder than it looks,

No doubt --- it's taken 30 years for *any* UNIX or derivative to get this
right.  Cf.  "Lexical File Names in Plan 9, or, Getting Dot-Dot Right" by Rob
Pike.  [1] Interestingly, (a) the algorithm for dealing with dot-dot in Plan 9
is very similar to the way it is handled with relative URI, and (b) in fact they
acknowledge this and cite Roy Fielding's earlier work on dealing with this
problem.

jb

[1] http://www.cs.bell-labs.com/sys/doc/lexnames.pdf









-----------------------------------------------------------------------------------
Post ID:943
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-08 22:23:28
Subject:Generative Naming
Message:

I've been working on a Wiki page to describe Generative Naming [1] in
more detail, along with some examples of how it might be used to solve
problems that hyperstructures cannot or cannot efficiently solve.  It's
not done, but it's a good and useful start.  Check it out if you'd like,
feedback appreciated.

jb

[1] http://conveyor.com/RESTwiki/moin.cgi/GenerativeNaming







-----------------------------------------------------------------------------------
Post ID:944
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-08 22:21:14
Subject:More for Paul
Message:

See the Wiki: [1]

Paul Prescod wrote:

> > Sorry, "without links to them."
>
> Oh, I see. We're back to "Java can't implement this solution unless you
> use Java."

No.  The above is an artificially bogus problem statement, I wouldn't do that to you.  The problem I have offered
is a much more realistic problem statement grounded in the *fact* that, while there are addressible objects on the
Web, not all of them are necessarily part of any hypertext structure.

> How do we find things that are part of the Web but not hyperlinked?

You get URLs to them in e-mail, or on napkins, or whatever.  You ever noticed that field in your browser that you
can type things into, or do you always get to every piece of content you access by following links from your home
page? ;-)

> You
> say by working with names. But that only works a tiny, tiny, tiny
> fraction of the time.

No, it's guaranteed to work *all* the time.  Hyperlinks depend on names.  Names do not depend on hyperlinks.  How
you acquire those names is a different matter, but TBL etc. have made it very explicit that the URI space is
intentionally constructed to not depend on any given mechanism of name acquisition.

> If you invent a generative grammar language for the Web, I will write a
> CGI program that allows generative grammars to generate hypertext
> documents so that the Web subsumes that functionality *through
> hypertext*.

Ok.  ;-)  But first, just to warm up, maybe you should start as follows:  write a program that lists all the
natural numbers.  Report back. ;-)  (The fact that you can write a grammar for something doesn't imply that you
can practically generate the possibly infinite set of things that the grammar *can* generate.)


> If we define hypertext as "text with links" then it becomes clear that
> anything you can represent with plan 9 namespaces I can represent with
> text with links.

It's not a question of representation, it's a question of whether generative, dynamic representations are
equivalent to static, declarative representations for all purposes.  They aren't.  Cf. the Wiki for more detailes,
but the following should suggest the problem:  while I may be able to write a grammar that generates all possible
strings that the grammar can generate, that set may be infinite and might not be enumerable.

> The only question is whether the system is closed over
> hypertext or closed over namespaces or neither. If we obey the opacity
> principle then it will become closed over hypertext because things
> without links to them would by definition not be on the Web.

This is exactly correct!  And the conclusion I've drawn is that (a) the original intent of at least the URI and
HTTP architectural components of the Web was that the Web was a superset of the hypertext structure, and (b) the
deviation away from those precepts is a cultural artifact of the increasing focus and interest on the part of a
few people (TBL) on markup-based KR.  But it's not at all clear that markup-based KR can or can best capture all
the kinds of information that inhabits a universal information space.

> But thanks
> to query parameters and URIs the set of things with links to them is
> infinite.

Yes, but pushing hierarchical / graph-structure inormation into the flat space of query parameters *loses*
information.  This is badness.  See the Wiki.

>
> > Yes, you are reduced to "hacking" in this case --- *because* of opacity.
>
> No, I'm reduced to hacking because I'm trying to get access to
> information (the listing of files) that was not provided to me.

This is incorrect.  I am trying to find objects in a space that is not and perhaps cannot be (or cannot
efficiently be) enumerated.  And I'm not "hacking," I'm using information about the organization of that space
that was explicitly provided to me by the owner of that space to do so.

> Okay you're the spider writer. I've just put ten .gif files on my
> website. Really. To help you along I put your first name in their file
> names. Go find them. (Please don't brute force my service provider.) If
> you show me how to solve the problem with namespaces I'll show you how
> to do it with hypertext.

This wouldn't be an appropriate problem for generative names, it would be like the problem I gave you earlier of
enumerating an infinite set.  Generative names aren't appropriate for this --- but neither is hypertext, if the
set is truly infinite or even very large.  I'm not suggesting that generative naming can or should tackle this
kind of problem.  I am, however, suggesting that there are information spaces which are well-organized, dense, and
regular for which this is an efficient and useful technique.  Infospaces organized along time and space are good
examples.  See the Wiki.

> Either the webiste owner is working with you or not. If they are not
> working with you then there is no reason to believe the names will be
> consistent because *they own the server side namespace and can name the
> graphics whatever they want*. That isn't unique to the Web. Every
> operating system I've ever used allows you to name things more or less
> whatever you want. Every programming language I've ever used allows you
> to name things more or less whatever you want. Are you saying the Web
> should enforce predictable names?

Not at all.

> If they are working with you then the tried and true and 100% effective
> way for them to do so is to provide hypertext (either static or dynamic)
> that provides access to the documents.

I'm not suggesting that hypertext isn't a good thing, and indeed the right tool in many, many cases.  I am
suggesting that it is not the right tool for every job, and in many cases where it's not the right tool generative
names in structured namespaces are.  We have both a hammer (hypertext) and a saw (the URI namespace).  We
shouldn't use the hammer to try to cut boards.

jb

[1] http://conveyor.com/RESTwiki/moin.cgi/GenerativeNaming







-----------------------------------------------------------------------------------
Post ID:945
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-08 23:16:45
Subject:Re: Offer/acceptance
Message:

Mark Baker wrote:
> Ok, so let's say we have this resource which is the thing that is
> being negotiated for;
> 
> http://company1.com/thing
> 
> So company2 becomes aware of this thing, and wants to make an offer 
for
> it.  So it does a GET on that URI and retrieves some RDF asserting 
that
> it is of type http://stds.org/product.  company2 knows this means 
that
> it can submit an offer document to that URI, so it puts one 
together and
> POSTs it there.  company1's software receives the offer, and can do
> one of two things;
> 
> - respond with an "Acceptance" document immediately

Easy.

> - respond with an "Ack" document, which includes a URI that refers
> to the Acceptance or Rejection document in the future.

The more interesting case...

> How's that?

Very simple.  Want to keep going?  I'm interested to find out if this 
simple plan will run into trouble in the next user stories.

If so, may I change the names from Company1 and Company2 to Seller 
and Buyer?  (Did I assign them correctly? I'll get confused 
otherwise.)  


Ok, so we got:
http://seller.com/thing

-To which URI the Buyer POSTs an offer to buy (i.e. Purchase Order).

And I'll focus on the case where the Seller responds to the Buyer 
with an "Ack" document including a URI referring to an Acceptance or 
Rejection document in the future.  Which the Buyer will check in the 
future.  All the documents except the "Ack" are in the control of the 
Seller.

Sorry if this is tedious, but if I rephrase, it may tell you if I 
understand or not.  Did I?

Ok, then, next complication:  the offer to buy should not be good 
forever, it should have a time constraint.  At the appointed time, 
the Buyer could check the URI for the Acceptance or Rejection 
document and if it's not there, the deal is off.  How would you 
handle that?  We want it to be clear to both parties that the deal is 
off, so they don't end up in court because the Seller tried to keep 
going.

-Bob Haugen











-----------------------------------------------------------------------------------
Post ID:946
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-09 02:25:26
Subject:Re: More for Paul
Message:

I've read your Wiki and all I can find that makes sense to me is:

"No, Really, WTF Is It Good For?"

Jeff Bone wrote:
> 
>...
> 
> No.  The above is an artificially bogus problem statement, I wouldn't do that to you.  The problem I have offered
> is a much more realistic problem statement grounded in the *fact* that, while there are addressible objects on the
> Web, not all of them are necessarily part of any hypertext structure.

And, in general, they are only reachable if somebody wants you to reach
them. The "web way" for them to express that is to give you either a
hard-coded address or a hypertext document. Inventing a new way for
describing sets of documents buys no new power, only complexity.

> > How do we find things that are part of the Web but not hyperlinked?
> 
> You get URLs to them in e-mail, or on napkins, or whatever.  You ever noticed that field in your browser that you
> can type things into, or do you always get to every piece of content you access by following links from your home
> page? ;-)

Once I type them in I defacto have a hyperlink. 

>...
> > If you invent a generative grammar language for the Web, I will write a
> > CGI program that allows generative grammars to generate hypertext
> > documents so that the Web subsumes that functionality *through
> > hypertext*.
> 
> Ok.  ;-)  But first, just to warm up, maybe you should start as follows:  write a program that lists all the
> natural numbers.  Report back. ;-)  (The fact that you can write a grammar for something doesn't imply that you
> can practically generate the possibly infinite set of things that the grammar *can* generate.)

def natural_numbers(startpos, endpos):
   for i in xrange(startpos, endpos):
      print "<num>%d</num>" % i

Now you can "address" all of the natural numbers through this function.

> > If we define hypertext as "text with links" then it becomes clear that
> > anything you can represent with plan 9 namespaces I can represent with
> > text with links.
> 
> It's not a question of representation, it's a question of whether generative, dynamic representations are
> equivalent to static, declarative representations for all purposes.  They aren't.  Cf. the Wiki for more detailes,
> but the following should suggest the problem:  while I may be able to write a grammar that generates all possible
> strings that the grammar can generate, that set may be infinite and might not be enumerable.

You don't have to enumerate them because you are only ever interested in
a subset.

> > The only question is whether the system is closed over
> > hypertext or closed over namespaces or neither. If we obey the opacity
> > principle then it will become closed over hypertext because things
> > without links to them would by definition not be on the Web.
> 
> This is exactly correct!  And the conclusion I've drawn is that (a) the original intent of at least the URI and
> HTTP architectural components of the Web was that the Web was a superset of the hypertext structure, and (b) the
> deviation away from those precepts is a cultural artifact of the increasing focus and interest on the part of a
> few people (TBL) on markup-based KR.  But it's not at all clear that markup-based KR can or can best capture all
> the kinds of information that inhabits a universal information space.

I feel like I'm arguing with you about libertarianism. You aren't trying
to solve a real problem that you've experienced in practice, just trying
to achieve a sort of hypertext-less purity. Well I'm trying to achieve a
hypertext-centric purity. Having the Web be closed over hypertext makes
it a much simpler information space. As you say, generative grammars
don't handle anything either. Next we'll be shipping Javascript
documents with the only goal of generating hyperlinks on the client
side. That's powerful enough that we could do away with hyperlinks and
generative grammars altogether.

> > But thanks
> > to query parameters and URIs the set of things with links to them is
> > infinite.
> 
> Yes, but pushing hierarchical / graph-structure inormation into the flat space of query parameters *loses*
> information.  This is badness.  See the Wiki.

No, it doesn't lose information. Queries generate *indexes* over
hierarchical information space. The existence of the Google index does
not destroy the hierarchy of MSDN, one of the things it may index.

> >
> > > Yes, you are reduced to "hacking" in this case --- *because* of opacity.
> >
> > No, I'm reduced to hacking because I'm trying to get access to
> > information (the listing of files) that was not provided to me.
> 
> This is incorrect.  I am trying to find objects in a space that is not and perhaps cannot be (or cannot
> efficiently be) enumerated.  

The relevant subsets of the information can be enumerated. The idea "ls
/1999/*/02" you can be expressed as a query with the appropriate
wildcard. The indexed documents may have whatever URI hierarchy you
want, and separately may have whatever HTTP hierarchy you want.

> ... And I'm not "hacking," I'm using information about the organization of that space
> that was explicitly provided to me by the owner of that space to do so.

The Web has a way for them to provide that information to you. It is a
hypertext index. Go to images.google.com. The Web way deals with both
highly structured AND highly unstructured namespaces.

>...
> This wouldn't be an appropriate problem for generative names, it would be like the problem I gave you earlier of
> enumerating an infinite set.  Generative names aren't appropriate for this --- but neither is hypertext, if the
> set is truly infinite or even very large.  I'm not suggesting that generative naming can or should tackle this
> kind of problem.  I am, however, suggesting that there are information spaces which are well-organized, dense, and
> regular for which this is an efficient and useful technique.  Infospaces organized along time and space are good
> examples.  See the Wiki.

You're an infospace designer. You have two options, one is to provide
access to the infospace through indexes and hypertext. The other is to
provide it through a generative grammer. In the former, all computation
can be done entirely on the server side, requires no more a priori
agreement beyond that necessary to use today's web and allows all
standard web tools to work with the index. The latter requires a new
language: "generative grammars for the web". It requires an agreement to
use this new namespace schema language. It requires new client side
code. The logical index generated on the client side with this
generative technique is not "on the web" (has no URI) and cannot be used
as an input to web processes.

Generating the index on the server reifies it with a URI and generally
builds on existing web infrastructure better.
http://www.somefiles.com/images?subset=/1999/*/02

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:947
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-09 03:44:50
Subject:Re: [rest-discuss] Re: More for Paul
Message:

> I've read your Wiki and all I can find that makes sense to me is:
> 
> "No, Really, WTF Is It Good For?"

Ditto.  There are a lot of people learning REST via the Wiki.  We should
take care to tag those more, <ahem/>, "controversial" pages as "Not
generally accepted as RESTful".

But back to Jeff's ideas.  Ignoring the so-called dogma for the moment,
here's a couple of very practical concerns.

First, internationalization.  If we agree that /help means "help",
shouldn't we also permit /aide to mean the same?  And if we do that, do
we require bots to understand all languages, and that no new languages
be defined?  If not, how do you deploy new languages?  You need a layer
of indirection here, something to assert "this URI is of this type".

Second, if my namespace already includes a "/help" - perhaps I use it
as the name for my "happy elves love partying" resource - does that mean
that I can't use the help/contact/search system?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:948
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-09 04:08:33
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

>
> How do we find things that are part of the Web but not hyperlinked? You
> say by working with names. But that only works a tiny, tiny, tiny
> fraction of the time. Most of the time you can't find things by guessing
> at their names. That only works when you have an agreement with the
> website author. Why wouldn't they express that agreement through
> hypertext (which is already deployed) rather than a generative grammar
> language (which isn't)? I'm still waiting for a use case.

Aren't HTML FORM elements a set of inputs to some agreed-upon-instructions
for generating URIs?








-----------------------------------------------------------------------------------
Post ID:949
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-09 04:48:53
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

>
> If you invent a generative grammar language for the Web, I will write a
> CGI program that allows generative grammars to generate hypertext
> documents so that the Web subsumes that functionality *through
> hypertext*.
>

I have a flat list of 100K users. Each are URI addressable. This is
goodness.
I have a username from another source (an email address for example).
I know they are (or might be) somewhere in that list... how do I get the URI
for it?
Sure.... I could do a query... but that would need a URI & I'd have to..
generate one.
Sure... I could GET the index (100K times the size of a record in markup...)
then search locally. But I (a lazy programmer) don't want to.
I can't go upstream to the original source & tell it to give me identifiers
used by a different system.
What now?


(if this is a different problem, feel free to correct me...)


Mike






-----------------------------------------------------------------------------------
Post ID:950
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-09 04:57:33
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

>
> Sorry, "without links to them."  Bottom line, Paul --- although everything
on the Web *can* be linked to,
> not everything is.  Yet everything that is nameable by a URI ---
regardless of whether it has inbound or
> outbound links in some hyperstructure --- is still part of "the Web."

This is an important point. When at a company that shall remain nameless, I
boiled down information systems into several aspects  - not all being
provided or efficient, but you could talk about the system in those terms:
 - read/write
 - address/reference
 - discovery
 - query
 - transform

(above that there is security, events and transactions, but they are in a
different category).

Not all system have a way to do all these seven things - some are easy to
read and hard to write back to. Some have no discovery - or at least no
standard interoperable discovery mechanism. For example, in SQL you can
reference a table, but I don't know of a (standard) way to list them.

Anyway.. I think Jeff has a good point that sometimes you don't have a good
way to discover instances of the remote server's public identifiers for
information, but you do have a good way to create those identifiers via
patterns of some kind.
The view that everything can and should be discoverable through receiving
the value from the server might be an analogous argument to the 'every
operation can be get/put/post/delete combined with many objects',. but this
time I'm not on the same side.

Examples help. How do I take an email address and get a users profile from a
URI addressable directory service?









-----------------------------------------------------------------------------------
Post ID:951
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-09 05:12:06
Subject:Re: [rest-discuss] Re: Offer/acceptance
Message:

>
> And I'll focus on the case where the Seller responds to the Buyer
> with an "Ack" document including a URI referring to an Acceptance or
> Rejection document in the future.  Which the Buyer will check in the
> future.  All the documents except the "Ack" are in the control of the
> Seller.

[...]

>
> Ok, then, next complication:  the offer to buy should not be good
> forever, it should have a time constraint.  At the appointed time,
> the Buyer could check the URI for the Acceptance or Rejection
> document and if it's not there, the deal is off.  How would you
> handle that?
I think that this probably is an application level concept, so should go in
the response body - some xml format.
I don't know if web resource have a concept of lifetime.
There is an 'Expires' header - but this is meant for caching.

 "The presence of an Expires field does not imply that the original resource
will change or cease to exist at, before, or after that time. "
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21

I'd still consider using it though...







-----------------------------------------------------------------------------------
Post ID:952
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-09 06:00:35
Subject:Re: [rest-discuss] Generative Naming
Message:

----- Original Message -----
From: "Jeff Bone" <jbone@...>

> Check it out if you'd like, feedback appreciated.
>
> [1] http://conveyor.com/RESTwiki/moin.cgi/GenerativeNaming
>

---
"Myth #6: Link Topologies Can Do Everything Structured Names Can
Consider the following task. I am a Web crawler, and I want to find every
publically available object that is served up by a Web server. This Web
server contains and makes available one or more objects that are not linked
to by any other object. If the server provides information which I can use
to dynamically understand and generate structured names in its namespace, I
may be able to find those objects. If names are opaque and I am restricted
to traversing the hypergraph topology, finding the objects that are not
linked to is impossible. See GenerativeNaming for more examples of how
constructable semantic names can sometimes be more expressive or efficient
or enable things that can't be done with graph traversal. "
---

I'd like to examine this part "This Web server contains and makes available
one or more objects that are not linked to by any other object."

In the scenerios I can think about (a large database of one table), the
objects /are/ linked by another object - the db table - but that other one
isn't 'public'.
I would re-phrase this (to describe my scenario) to "This Web server
contains and makes available one or more resources that are not linked to by
any other publicly available resource."
What I'm getting at is that the linking is there, but it is not made visible
publicly. Sometimes it's not visible due to lazy programmers like me, but
many times it isn't feasible to just list all known resources (transfer the
state of the index of the table).

Making the private resource into a public resource would help. You could
define 'views' over this resource and list all those - which brings you back
to hyperlinking - but you'd need to know the name of the view. Which is
still an issue, but not one that requires generating a structured name. This
would bring some scenarios into the hypermedia fold (the HyperFold(tm)) -
but that isn't practical for everything.
For example a DB resource could have a representation like:
<table>
 <allVCRs>/data/query?dev=vcr</allVCRs>
 <allUsers>/data/users/list</allUsers>
</table>

You still need to know names (e.g. 'allUsers') but you don't have to
construct them.

I do think generative naming is very useful but I'm thinking of the case
where you have to translate addresses. Two disparate systems have 'local'
names for something and don't know about each other. You receive a name from
serviceA and need to do something via serviceB. Defining a pattern based
mapping is handy. I don't know how to do it otherwise. Anyone? Anyone?










-----------------------------------------------------------------------------------
Post ID:953
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-09 06:10:21
Subject:Re: [rest-discuss] Re: More for Paul
Message:


Paul Prescod wrote:

> I've read your Wiki and all I can find that makes sense to me is:
>
> "No, Really, WTF Is It Good For?"

I know.  Try harder.  (Do you have any *substantive* criticism, or are we reduced to taking pot shots? ;-)

> And, in general, they are only reachable if somebody wants you to reach
> them.

But linking to them via hypertext is *explicitly* not the only means of making them available and communicating that
availability.  Napkins, billboards, voice convo, e-mail, etc.

> The "web way" for them to express that is to give you either a
> hard-coded address or a hypertext document. Inventing a new way for
> describing sets of documents buys no new power, only complexity.

I've already given you many specific examples and general explanations.

> Once I type them in I defacto have a hyperlink.

No, you de facto have a URI.  A URI is not a hyperlink --- a URI embedded in hypertext is a hyperlink.  Whether you have
a hyperlink or not depends on whether it occurs in a recognizable hypertext.

> def natural_numbers(startpos, endpos):
>    for i in xrange(startpos, endpos):
>       print "<num>%d</num>" % i
>
> Now you can "address" all of the natural numbers through this function.

No, I didn't say in some range, I said *all of them.*  (Hint:  it was a joke, Paul.  The point should be clear:  you
can't list an infinite set.)

> You don't have to enumerate them because you are only ever interested in
> a subset.

But the server cannot a priori know what subset I'm interested in.  Therein lies the problem.  Consider a resource
representing the digits of pi.  I'd like to be able to address specifically the digits of pi.  The ordinal position of a
digit of pi bears a subordinate, hierarchical relationship to the sequence of digits that make up pi.  I'd like to be
able to say

    http://www.constants.com/pi/2036

rather than

    http://www.constants.com/pi?digit=2036

Why?  Because the meaning of the first is clearer by virtue of the use of the hierarchical path syntax, while the
meaning of the second is not as clear.  This is a bit of a weak example, because the first is not a *lot* clearer than
the second, but you get my drift.  At least, in the first example, the index *is* the namespace rather than being an
adjunct to it.  Pi and pi's 2036th digit are both equally first-class entities, though the latter is "subordinate" to
the former.

> I feel like I'm arguing with you about libertarianism.

This is a scientific and engineering discussion, not a political discussion.  At least it should be --- that's what I'm
trying to keep it at.

> You aren't trying
> to solve a real problem that you've experienced in practice, just trying
> to achieve a sort of hypertext-less purity.

No, I'm trying to avoid cutting boards with hammers.  We have *two* powerful abstractions with the Web:  the URI
namespace and hypertext.  We should use them both.

> Well I'm trying to achieve a
> hypertext-centric purity.

So here we have it --- you're the one with the political agenda, here.  The Web is undergoing a revisionist movement
called "The Semantic Web."  People have problems grokking namespaces, while everybody understands (some) graph theory.
Let's get rid of the troublesome namespaces!  Problem is, there are things namespaces are good for that graphs are not.

> Having the Web be closed over hypertext makes
> it a much simpler information space. As you say, generative grammars
> don't handle anything either. Next we'll be shipping Javascript
> documents with the only goal of generating hyperlinks on the client
> side. That's powerful enough that we could do away with hyperlinks and
> generative grammars altogether.

Javascript documents that generate hyperlinks would be a form of generative "grammar" or an equivalent generative
system.

>
> > Yes, but pushing hierarchical / graph-structure inormation into the flat space of query parameters *loses*
> > information.  This is badness.  See the Wiki.
>
> No, it doesn't lose information. Queries generate *indexes* over
> hierarchical information space. The existence of the Google index does
> not destroy the hierarchy of MSDN, one of the things it may index.

It loses information *in the URI.*  This is clear.  Think about it.

> The relevant subsets of the information can be enumerated.

Again the problem is that the server cannot know a priori which subset is interesting, so it cannot be enumerated in
hypertext, only indirectly represented via a partial name.  This name *can* be represented as a query string, at the
expense of losing information about the relationships between the query parameters and between those parameters and the
overall information space being modeled.

> The Web has a way for them to provide that information to you. It is a
> hypertext index. Go to images.google.com. The Web way deals with both
> highly structured AND highly unstructured namespaces.

It also has a mechanism called "URI" that can be used to represent highly organized information spaces directly.

> You're an infospace designer. You have two options,

Not an either-or choice, but one to be informed by the problem you're modeling.

> Generating the index on the server reifies it with a URI and generally
> builds on existing web infrastructure better.
> http://www.somefiles.com/images?subset=/1999/*/02

This is a good and noble goal, and should be pursued wherever possible.  Sometimes, though, these indices cannot be
reified;  rather, the relevant information must be computed.  Generative naming works in this case;  hypertext per se
does not.  In the case of generative naming, the namespace *is* the index.

jb








-----------------------------------------------------------------------------------
Post ID:954
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-09 06:22:27
Subject:Re: [rest-discuss] Re: More for Paul
Message:


Mark Baker wrote:

> Ditto.  There are a lot of people learning REST via the Wiki.  We should
> take care to tag those more, <ahem/>, "controversial" pages as "Not
> generally accepted as RESTful".

This is a reasonable request.  I have now marked the documents in question in
the following manner, at the top of the page:

    Note:  THIS DOCUMENT CONTAINS REST HERESY.

> But back to Jeff's ideas.  Ignoring the so-called dogma for the moment,
> here's a couple of very practical concerns.
>
> First, internationalization.

It's no more or less a problem here than it is in agreeing on XML tag name
choices in "standardized" schemas, etc., and then dealing with
transformations between language representations of tag name choices.

> You need a layer
> of indirection here, something to assert "this URI is of this type".

As mentioned, the semantic information about what particular name elements
needs to be represented elsewhere.  I'll go further:  not only do complete
URI need to be typed, but their parts need to be typed.

> Second, if my namespace already includes a "/help" - perhaps I use it
> as the name for my "happy elves love partying" resource - does that mean
> that I can't use the help/contact/search system?

Good question.  The answer at first seems to be yes, and this seems to be a
weakness.  The mechanism for avoiding this problem is the same as it is in
XML:  introduce namespaces inside URI components to avoid collision.  But we
don't even have to do anything to introduce those;  the ';' property space
does our job for us.  Instead of namestd:help you have help;namestd or what
have you.

jb








-----------------------------------------------------------------------------------
Post ID:955
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-09 06:37:02
Subject:Re: [rest-discuss] Generative Naming
Message:

"S. Mike Dierken" wrote:

> I would re-phrase this (to describe my scenario) to "This Web server
> contains and makes available one or more resources that are not linked to by
> any other publicly available resource."

This is a good point, thanks!  A further point is that the scenario only makes
sense for sets of objects for which some predictable naming scheme conceptually
exists.  (Thanks also to Paul for his rather ridiculous but pertinent example
about sparse, irregular spaces in some earlier message;  I never imagined using
names for those, but it's good to be clear.)  I have changed to wording to:

"This Web server contains and makes available one or more resources that are not
linked to by any other publicly available resource, but for which one or more
predictable naming schemes conceptually exists."


> I do think generative naming is very useful but I'm thinking of the case
> where you have to translate addresses. Two disparate systems have 'local'
> names for something and don't know about each other. You receive a name from
> serviceA and need to do something via serviceB. Defining a pattern based
> mapping is handy. I don't know how to do it otherwise. Anyone? Anyone?

Hmmm...  this is an interesting point.  Want to elaborate?

jb









-----------------------------------------------------------------------------------
Post ID:956
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-09 06:47:57
Subject:Algorithms and Data Structures
Message:

It's seeming to me like generative naming vs. hypermedia discussion all boils
down to algorithms and data structures.  An XML document is a data structure;
the hyperstructure of the Web is a data structure.  Some data structures can
encode algorithms --- for example, an XSLT transform is an XML data structure
that is also a Turing-complete algorithmic language.  The hyperstructure of the
Web is not an algorithmic language.

It is well-known that algorithms can represent things that cannot be explicitly
represented without computation.  If URIspace is intended to contain all possible
information --- and I assume that it is --- then non-generative naming and
hypermedia are not sufficient by themselves to refer to all the things URIspace
is intended to contain.  Generative names are not Turing-complete algorithmic
languages either, of course, but they do provide a mechanism by which references
to objects may be computed.  Without generative names, the Web can contain things
that cannot be referred to without a priori knowledge of the thing.

Give a person a fish, and you've fed him dinner.  Teach a person to fish, and
you've fed them for life.  Give a person a URI, and you've given him a reference
to a resource.  Teach a person to make URIs to your resources, and you've given
him references to all of them.

Just a thought before bed.

jb








-----------------------------------------------------------------------------------
Post ID:957
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-09 07:43:37
Subject:Motivation, Theoretical Arguments
Message:

One point.  Paul actually brings up an interesting possibility
re: my motivation in pressing the issue of URI opacity:

> You aren't trying to solve a real problem that you've
experienced in practice,
> just trying to achieve a sort of hypertext-less purity.

In fact this isn't at all the case.  Most of the thorniest
technical problems I've dealt with in my entire career have all
touched on the stuff we're talking about: from mapping and
transforming between arbitrary data models at Evolutionary
Technologies* a over a decade ago to exposing an information
model for presence in URIspace at Activerse to exposing a rich
and flexible ontological model for online news in HTTPspace at
Clickfeed to filesystem namespace wrangling and breaking the
barriers between filesystem and Web at Deepfile.  In particular,
opaque URIs make my job harder at Deepfile in ways that I can't
really discuss in detail until we open the kimono on what we're
doing.

Throughout all of these, it's become clear that namespaces ---
abstract machines which resolve semantically-meaningful names
into things --- are incredibly powerful tools for solving a
variety of problems.  We've got one of those tools in URIs, I
just hate to see us lose the use of it for obscure, political /
cultural, or mistaken reasons.

The fact that I'm invoking some theoretical arguments to support
what I'm asserting doesn't mean that the point is academic;  it
means that the theoretical arguments demonstrate (or at least
should be evocative of familiar) definitive generalizations.
I've admittedly not done as good a job as I would like with those
arguments, but the points we're dicussing touch some very
fundamental and philosophical parts of computer science such as
computability, identity, representability, information theory,
and so on.

I've tried to supplement these with some toy but concrete
examples that illustrate the points I'm making.  I'm happy to add
more (and more detailed) examples, if that's useful, and if
anyone else can think of any good examples (or counterexamples)
I'm happy to add them.  I'd like to communicate the problem well
enough for people to understand --- but this may indeed be as
subtle and thorny a topic to the RESTful as REST itself is to the
RPC enthusiast or Web layman.

Cheers,

jb











-----------------------------------------------------------------------------------
Post ID:958
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-09 09:30:36
Subject:Re: [rest-discuss] Generative Naming
Message:

>
>
> > I do think generative naming is very useful but I'm thinking of the case
> > where you have to translate addresses. Two disparate systems have
'local'
> > names for something and don't know about each other. You receive a name
from
> > serviceA and need to do something via serviceB. Defining a pattern based
> > mapping is handy. I don't know how to do it otherwise. Anyone? Anyone?
>
> Hmmm...  this is an interesting point.  Want to elaborate?
>
At the risk of my train of thought being derailed...

A lot of information systems have 'fragments' that can be passed to other
systems to control other information. These are like partial hyperlinks -
they aren't ready to be used without adjusting for the target information
system. In a RDB the values in one table don't say much about whether you
can use them against another table, or in another database or a the file
system, etc. The 'base' part of database means its all been normalized. You
need a third thing to link the two systems together - thats what the set of
queries are after all (sure sure foreign key constraints, blah blah
blah...).
These 'fragments' of an address are just relative locations. If I wanted to
take data that contained 'hidden' or 'truncated' hyperlinks and make visible
the links lurking within, the values need to 'bubble up' through name
translation. From the value in a table, to the name of the table, to the
name of the database to the name of the db server, etc. Expressing this name
translation symbolically is what most web software (the procedural code
aspects) does today. This is probably just a convoluted description of 'link
re-writing'.
Doing this 'link re-writing' assumes you know what is being referenced by
the link - and that's where the problem comes in. You can generate many
different views, but someone will always want something different. They will
know about a third information system that uses the same value as a lookup
name, but you don't know anything about it and so cannot generate the link
to it. You have to provide a 'relative name' and let the client/intermediary
do the rest.

I see the power of information in the 'joins' between data systems. Taking
values from one place (email addresses from an ldap server) and generating
references into another (home folders on disk, searches on google, entries
at hotornot, inboxes at hotmail, etc.) is easy and leads to cool systems
like the web itself. Doing this by keeping an explicit instance-based
mapping is tedious and unnecessary. Generating the links via symbolic
descriptions of the naming transform sounds looks better to me.

mike 'sleepyhead' d







-----------------------------------------------------------------------------------
Post ID:959
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-09 17:54:23
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

"S. Mike Dierken" wrote:
> 
>...
> 
> I have a flat list of 100K users. Each are URI addressable. This is
> goodness.

Great.

> I have a username from another source (an email address for example).

I feel a query coming on....

> I know they are (or might be) somewhere in that list... how do I get the URI
> for it?

You can't. Either the information owner has given you a way to map from
email addresses to URIs or they haven't. Jeff's way to do the mapping is
to have the information owner specify (how?) that email addresses may be
plugged in to URIs. The Web way is for the informatoin owner to create a
query that maps from email addresses to URIs. The Web way allows 50K of
the users to live at one domain and 40K at another and 10K at another. 

> Sure.... I could do a query... but that would need a URI & I'd have to..
> generate one.

Don't follow this point. You need *something*. The information owner has
to provide a mapping somehow.

Either it is a query URI or it is a "generative grammar" URI or it is a
prose email from the information owner.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:960
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-09 18:19:36
Subject:Re: [rest-discuss] Re: More for Paul
Message:

> This is a reasonable request.  I have now marked the documents in question in
> the following manner, at the top of the page:
> 
>     Note:  THIS DOCUMENT CONTAINS REST HERESY.

Thanks. 8-)

> > But back to Jeff's ideas.  Ignoring the so-called dogma for the moment,
> > here's a couple of very practical concerns.
> >
> > First, internationalization.
> 
> It's no more or less a problem here than it is in agreeing on XML tag name
> choices in "standardized" schemas, etc., and then dealing with
> transformations between language representations of tag name choices.

I think it is substantially different.  Representations can be
transformed willy nilly with no implication, but names cannot.

> > You need a layer
> > of indirection here, something to assert "this URI is of this type".
> 
> As mentioned, the semantic information about what particular name elements
> needs to be represented elsewhere.  I'll go further:  not only do complete
> URI need to be typed, but their parts need to be typed.

"need" as in "must"?  If so, you're placing quite a burden on namespace
owners.  I should be able to create http://foo.org/a/b/c/d/e/f/g without
any worry that people will assume certain things about that means, which
may place additional obligations on me as webmaster.

> > Second, if my namespace already includes a "/help" - perhaps I use it
> > as the name for my "happy elves love partying" resource - does that mean
> > that I can't use the help/contact/search system?
> 
> Good question.  The answer at first seems to be yes, and this seems to be a
> weakness.  The mechanism for avoiding this problem is the same as it is in
> XML:  introduce namespaces inside URI components to avoid collision.  But we
> don't even have to do anything to introduce those;  the ';' property space
> does our job for us.  Instead of namestd:help you have help;namestd or what
> have you.

URI parameters have no global meaning, if that's what you're suggesting.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:961
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-09 18:14:08
Subject:Re: [rest-discuss] Onions in the Varnish
Message:

"S. Mike Dierken" wrote:
> 
> >
> > URIs are opaque at the application level. Client software should not
> > inspect URIs to try and figure out the structure of a server's data
> > model.
> 
> Is it okay for a client to be /told/ what the structure of a server's data
> model (with respect to URIs) is? and then do URI munging?

First, let's acknowledge that "URI munging" is sometimes necessary.
That's why the Web infrastructure has explicit support for it, as you
say:

> Aren't HTML FORM elements a set of inputs to some agreed-upon-instructions
> for generating URIs?

So the opacity principle has always been: opacity by default and
transparency when you need it. WRDL even deepens the support for URI
generation through strong typing etc. And this interoperates with the
hierarchical parts of the URI because the query typically generates an
index OVER the hierarchical namespace. It's like a Unix "find" command.
The find command itself is non-hierarchical but the results it returns
are in a hierarchical space.

So now that we've agreed that URI munging is necessary (as Tim
Berners-Lee did in his 1996 document on URI opacity), Jeff's instinct is
to open the floodgates and allow arbitrary manipulations of URIs. In
theory, this is probably okay as long as it is under complete server
control (as HTML forms and query parameters are). But what would it take
to make it really work reliably on the Web? Jeff suggests that we need a
set of generative grammar schema languages that can be shared between
client and server. And we need a form of "namespaces" for URIs. And we
need strong typing for components of namespaces. And...etc. etc.

Can you see that he is going to end up reinventing everything that has
been done in the markup world? And he won't make a single "opaque data
object" addressable that would otherwise be non-addressable because it
will take *effort* on the part of the information owner to generate
these generative grammars and they could just as easily implement an
index using queries today. So we'll put in a bunch of effort inventing a
bunch of new technologies that buy no new power. 

Really, the question boils down to whether the mapping from primitive
values (e.g. dates) to addressable objects (e.g. dated webcam snapshots)
happens on the client or the server. And we all know about the effort it
takes to deploy new technologies on the client (browsed many XML/XSLT
pages lately?) versus the server. So the whole project is doomed from
the start because it doesn't buy anything and it has tremendous costs.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:962
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-09 18:23:44
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

> I have a flat list of 100K users. Each are URI addressable. This is
> goodness.
> I have a username from another source (an email address for example).
> I know they are (or might be) somewhere in that list... how do I get the URI
> for it?
> Sure.... I could do a query... but that would need a URI & I'd have to..
> generate one.
> Sure... I could GET the index (100K times the size of a record in markup...)
> then search locally. But I (a lazy programmer) don't want to.
> I can't go upstream to the original source & tell it to give me identifiers
> used by a different system.
> What now?

If "I" here is just you, the resource publisher, then you do whatever
the heck you want with it because you know what the namespace semantics
are.

The issue is, can somebody else infer that because they see;

http://www.dierken.com/email/foo@...

that there exists a URI

http://www.dierken.com/email/asdfasdf@...

I say no, unless somehow dierken.com asserts that /email is a container
of arbitrary email addresses.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:963
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-09 18:18:50
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

"S. Mike Dierken" wrote:
> 
>...
> 
> Examples help. How do I take an email address and get a users profile from a
> URI addressable directory service?

People do this stuff on the Web every day:

http://www2.1800ussearch.com/search/teaser.cgi?searchLName=Prescod&searchMName=&searchCity=&searchState=&searchApproxAge=&searchFName=Paul&resultID=115672819--9649017-0&adID=1007001

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:964
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-09 18:48:48
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

Mark Baker wrote:
> 
>...
> 
> If "I" here is just you, the resource publisher, then you do whatever
> the heck you want with it because you know what the namespace semantics
> are.
> 
> The issue is, can somebody else infer that because they see;
> 
> http://www.dierken.com/email/foo@...
> 
> that there exists a URI
> 
> http://www.dierken.com/email/asdfasdf@...
> 
> I say no, unless somehow dierken.com asserts that /email is a container
> of arbitrary email addresses.

I agree 100%. And if they want to make this assertion on *today's web*
they use a servlet with query parameters. Of course for now the
assertion probably has both prose and declarative components. The prose
part is: "you can plug in an email address from X". The declarative part
is that the syntax of the parameter must be an email address. As the
semantic web progresses we'll hopefully move more of the semantics into
the declarative bit...

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:965
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-09 19:13:53
Subject:Re: [rest-discuss] Algorithms and Data Structures
Message:

Jeff Bone wrote:
> 
> It's seeming to me like generative naming vs. hypermedia discussion all boils
> down to algorithms and data structures.  An XML document is a data structure;
> the hyperstructure of the Web is a data structure.  Some data structures can
> encode algorithms --- for example, an XSLT transform is an XML data structure
> that is also a Turing-complete algorithmic language.  The hyperstructure of the
> Web is not an algorithmic language.

Sounds like hand waving to me. As you admit below, Turing-completeness
is irrelevant because neither model is Turing-complete.

> It is well-known that algorithms can represent things that cannot be explicitly
> represented without computation.  If URIspace is intended to contain all possible
> information --- and I assume that it is --- then non-generative naming and
> hypermedia are not sufficient by themselves to refer to all the things URIspace
> is intended to contain.  Generative names are not Turing-complete algorithmic
> languages either, of course, but they do provide a mechanism by which references
> to objects may be computed. 

As do query parameters.

> ....  Without generative names, the Web can contain things
> that cannot be referred to without a priori knowledge of the thing.

If someone tells you that his website is organized as
/foo/$year/$month/$index then you HAVE a priori knowledge of all of the
things so addressed. It's just a very compact syntax for that knowledge.
Using a query you can reference the *same thing*, through one level of
indirection.

document(http://www.foo.com/bar?year=...&$month=...&index=...#xptr(//@href))

The only question is whether the $-variable to URI mappings happens on
the client or the server. The set of addressable objects is exactly the
same.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:966
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-09 19:26:48
Subject:Re: [rest-discuss] Onions in the Varnish
Message:

>
> So now that we've agreed that URI munging is necessary (as Tim
> Berners-Lee did in his 1996 document on URI opacity), Jeff's instinct is
> to open the floodgates and allow arbitrary manipulations of URIs.

I think this is incorrect. Defining a subset of all possible URI
manipulation along with rules doesn't sound like 'floodgates'. Clarifying
existing practice and extending that to other declarative forms sounds like
it will strengthen the Web, not weaken it.
JeffB consistently says that it is only one of many tools and can/should be
used only in certain classes of problems, and he says that otherwise a pure
hyperlink approach is better.

http://conveyor.com/RESTwiki/moin.cgi/GenerativeNaming
"It's not good for characterizing sparse or irregular information spaces.
And generally, they are no substitute for hypertext unless the abstraction
being represented just cannot be efficiently represented in hypertext"

"The bottom line is that names and graphs are different tools that are
*both* fundamental components of the Web architecture, and you should use
the right tool for the job"

Take the example of 100K user profiles, indexed by email address. JeffB &
PaulP - show me each of your approaches. More than one example is fine,
since that helps explain things to me.






-----------------------------------------------------------------------------------
Post ID:967
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-09 19:41:27
Subject:Onions
Message:

Jeff Bone wrote:
> 
> Mark Baker wrote:
> 
> > Ditto.  There are a lot of people learning REST via the Wiki.  We should
> > take care to tag those more, <ahem/>, "controversial" pages as "Not
> > generally accepted as RESTful".
> 
> This is a reasonable request.  I have now marked the documents in question in
> the following manner, at the top of the page:
> 
>     Note:  THIS DOCUMENT CONTAINS REST HERESY.

While we're making editorial changes, its a weak rhetorical trick to
equate the opacity axiom to the onion analogy. The onion was a bit of
superstitious nonsense with no chemical backing whatsoever. The fact
that we've been arguing about this for several days indicates that we
have a legitimate technical disagreement like the difference between the
Java and C# floating point models.

> ... I'd like to communicate the problem well
> enough for people to understand --- but this may indeed be as
> subtle and thorny a topic to the RESTful as REST itself is to the
> RPC enthusiast or Web layman.

Actually, we've had pretty good success explaining the benefits of REST
to the RPC crowd. There are things you can do with hypertext and
addressing that are painful to the extent of being impossible to do
without them. RPC people who are willing to think about it long enough
to argue about it tend to come around. I don't see it in this case.
Every time you present a use-case that doesn't explicitly deny me the
right to use hypertext, I can present a hypertext solution to the
problem. In fact, I can mechanically translate your generative grammars
definitions into hypertext solutions. It's just a matter of moving the
string replacement from the client to the server and adding a level of
indirection.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:968
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-09 20:02:16
Subject:Re: [rest-discuss] Re: More for Paul
Message:

> > And, in general, they are only reachable if somebody wants you to reach
> > them.
> 
> But linking to them via hypertext is *explicitly* not the only means of making them available and communicating that
> availability.  Napkins, billboards, voice convo, e-mail, etc.

That's the same thing.  There is no "linking to them" separate from
simply "writing down their URI".

> > Once I type them in I defacto have a hyperlink.
>
> No, you de facto have a URI.  A URI is not a hyperlink --- a URI embedded in hypertext is a hyperlink.  Whether you have
> a hyperlink or not depends on whether it occurs in a recognizable hypertext.

Well, "hypertext" is just text with URIs.  Nothing says the text has to
give URIs special status.  For example, email clients are doing the
right thing when they make URIs clickable that are embedded in a plain
text email.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:969
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-09 21:19:38
Subject:Re: [rest-discuss] Re: More for Paul
Message:

Jeff Bone wrote:
> 
>...
> 
> > def natural_numbers(startpos, endpos):
> >    for i in xrange(startpos, endpos):
> >       print "<num>%d</num>" % i
> >
> > Now you can "address" all of the natural numbers through this function.
> 
> No, I didn't say in some range, I said *all of them.*  (Hint:  it was a joke, Paul.  The point should be clear:  you
> can't list an infinite set.)

No, you can't list them. You can *represent them*. On the web we do that
with query-generated indexes. You want to do it with client-side
generative grammars. I'm waiting for a *concrete* benefit.

> > You don't have to enumerate them because you are only ever interested in
> > a subset.
> 
> But the server cannot a priori know what subset I'm interested in.  

That's why you supply *query parameters*.

> ... Therein lies the problem.  Consider a resource
> representing the digits of pi.  I'd like to be able to address 
> specifically the digits of pi.  The ordinal position of a
> digit of pi bears a subordinate, hierarchical relationship to 
> the sequence of digits that make up pi.  I'd like to be
> able to say
> 
>     http://www.constants.com/pi/2036
> 
> rather than
> 
>     http://www.constants.com/pi?digit=2036

That's absolutely fine. The latter can be either a redirect to the
former or an index page that returns a link to the former or both.

> Why?  Because the meaning of the first is clearer by virtue of the use of the hierarchical path syntax, while the
> meaning of the second is not as clear.  This is a bit of a weak example, because the first is not a *lot* clearer than
> the second, but you get my drift.  

Do you have any examples that are not a bit weak???

> ... At least, in the first example, the index *is* the namespace rather than being an
> adjunct to it.  Pi and pi's 2036th digit are both equally first-class entities, though the latter is "subordinate" to
> the former.

That's fine. Use the query as an index over or redirect to the
hierarchical version. Anyhow, you're begging the question. You start
with the premise that it is important to represent hierarchies in the
URI. Actually, this is just a convenience that makes mapping between
file systems and URIs easier. It is not core to the web architecture at
all.

> > I feel like I'm arguing with you about libertarianism.
> 
> This is a scientific and engineering discussion, not a political discussion.  At least it should be --- that's what I'm
> trying to keep it at.

My point is that your arguments in each situation are not
problem-driven, they are theory-driven. If you had approached this whole
situation like: "I was working on this problem and I found it very hard
to solve with existing techniques." I can solve your problem of finding
graphics that have no links on the Web using CGI. Yes, it requires
coordination with the server creator. BUT SO DOES YOUR SOLUTION.

>...
> > No, it doesn't lose information. Queries generate *indexes* over
> > hierarchical information space. The existence of the Google index does
> > not destroy the hierarchy of MSDN, one of the things it may index.
> 
> It loses information *in the URI.*  This is clear.  Think about it.

Google loses information in MSDN's URIs? That's ridiculous! The object's
canonical URI does not change because someone, somewhere has indexed it.

> > The relevant subsets of the information can be enumerated.
> 
> Again the problem is that the server cannot know a priori which subset is interesting, so it cannot be enumerated in
> hypertext, only indirectly represented via a partial name.  This name *can* be represented as a query string, at the
> expense of losing information about the relationships between the query parameters and between those parameters and the
> overall information space being modeled.

The query-based URI does not necessarily reference the resource. It can
be the canonical name for the object, or an alternate name for the
resource, or a redirect to the resource or provide a reference to the
resource.

>...
> > builds on existing web infrastructure better.
> > http://www.somefiles.com/images?subset=/1999/*/02
> 
> This is a good and noble goal, and should be pursued wherever possible.  Sometimes, though, these indices cannot be
> reified;  rather, the relevant information must be computed.

What do you think images.cgi does? It's a computation!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:970
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-09 21:37:57
Subject:Re: [rest-discuss] Onions in the Varnish
Message:

"S. Mike Dierken" wrote:
> 
> JeffB consistently says that it is only one of many tools and can/should be
> used only in certain classes of problems, and he says that otherwise a pure
> hyperlink approach is better.
> ...

That sounds very reasonable. But the hyperlink model is complete, in the
same way that GET/PUT/POST/DELETE is complete. In the same way that
lambda calculus primitives are complete. So Jeff needs to show that his
way is simpler. Rather, he's shown how he can recreate all of the
complexity of markup (namespaces, interfaces, generative schemas) in
namespaces. So we double the complexity without increasing the
descriptive power at all.

>...
> 
> Take the example of 100K user profiles, indexed by email address. JeffB &
> PaulP - show me each of your approaches. More than one example is fine,
> since that helps explain things to me.

I thought I did this already. There are 100K user profiles. There are
100K email addresses somewhere else. Somehow we have to communicate from
the client to the server that there is a mapping from email addresses to
URIs. I can only roughly guess at Jeff's approach (he hasn't elaborated
it except in bits and pieces) but it seems like it would involve sending
something like this from server to client:

<uri_remapping>
  <variable name="userid" type="EmailAddress">
  <remapping href="http://www.userprofiles.com/profiles/$userid">
</uri_remapping>

The client needs to know how to interpret this as an assertion that
email addresses can be plugged in to get back URIs.

Whereas, I would send something like:

<form method="GET" target="http://www.profiles.com/profile_for_id">
  <input name="userid" type="email_address"/>
</form>

A three-line servlet returns a redirect to
http://www.userprofiles.com/profiles/$userid

My solution is equally powerful, uses only currently-deployed
technologies and lets the server name things however it wants.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:971
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-03-09 22:21:06
Subject:Re: [rest-discuss] Onions
Message:

On Sat, Mar 09, 2002 at 11:41:27AM -0800, Paul Prescod wrote:

> While we're making editorial changes, its a weak rhetorical trick to
> equate the opacity axiom to the onion analogy. The onion was a bit of
> superstitious nonsense with no chemical backing whatsoever. The fact

No, not superstition. It was a kludge that was later taken to have been
a design decision. Though that may not make the argument any stronger.

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:972
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 01:15:26
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:


Paul Prescod wrote:

> > I have a username from another source (an email address for example).
>
> I feel a query coming on....

Semantic names are queries.

> > I know they are (or might be) somewhere in that list... how do I get the URI
> > for it?
>
> You can't.

Only because of the delusion of opacity!  You can't use the axiom of opacity to
argue for the axiom of opacity, Paul!  In fact you *can* get that URI if you know
how to build it.

> The Web way is for the informatoin owner to create a
> query that maps from email addresses to URIs. The

In other namespace-oriented applications, the namespace can *encode* that query in
a useful, meaningful way.

> Web way allows 50K of
> the users to live at one domain and 40K at another and 10K at another.

This ability is not unique to the "Web way" of having part of that information in
an opaque string and part in a transparent string.

jb







-----------------------------------------------------------------------------------
Post ID:973
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 01:25:43
Subject:Re: [rest-discuss] Onions in the Varnish
Message:


Paul Prescod wrote:

> Can you see that he is going to end up reinventing everything that has
> been done in the markup world? And he won't make a single "opaque data
> object" addressable that would otherwise be non-addressable because it
> will take *effort* on the part of the information owner to generate
> these generative grammars and they could just as easily implement an
> index using queries today. So we'll put in a bunch of effort inventing a
> bunch of new technologies that buy no new power.

Aha!  Here's another one that's easy to knock down.  It's often a *lot* easier
to write down a scheme for naming in a useful manner than it is to provide
either a query capability *beyond* namespace organization *or* an explicit which
can be used to find things.  If namespace owners can describe the structures of
their information spaces as easily as something like

    http://smartspace.com/<user>/<building>/<room>/<device>

then more structure will be imposed, resulting in better organized and more
useful information on the Web.  To the extent that "new technology" needs to be
invented in order to use semantic naming, the power it "buys" is expressivity.
And that *is* important and useful.

> And we all know about the effort it
> takes to deploy new technologies on the client (browsed many XML/XSLT
> pages lately?) versus the server. So the whole project is doomed from
> the start because it doesn't buy anything and it has tremendous costs.

This is an absolutely ridiculous non-sequiter conclusion, you know?  I'm not
quite sure what all this scary "new technology" you think is necessary actually
is.  At a minimum, all a server would need to do to use structured names is
write the rules down in English on a Webpage for how to construct URI to their
resources of interest.  Humans *and* developers could then use those rules as
they saw fit, or not.

jb








-----------------------------------------------------------------------------------
Post ID:974
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 01:28:20
Subject:Re: [rest-discuss] Re: More for Paul
Message:


Mark Baker wrote:

> > It's no more or less a problem here than it is in agreeing on XML tag name
> > choices in "standardized" schemas, etc., and then dealing with
> > transformations between language representations of tag name choices.
>
> I think it is substantially different.  Representations can be
> transformed willy nilly with no implication, but names cannot.

Hmmm....  is that true?  Think about it.

> > Good question.  The answer at first seems to be yes, and this seems to be a
> > weakness.  The mechanism for avoiding this problem is the same as it is in
> > XML:  introduce namespaces inside URI components to avoid collision.  But we
> > don't even have to do anything to introduce those;  the ';' property space
> > does our job for us.  Instead of namestd:help you have help;namestd or what
> > have you.
>
> URI parameters have no global meaning, if that's what you're suggesting.

That's not what I'm suggesting --- the mechanism I'm talking about is a way to
distinguish otherwise identical parts at some position in the path, i.e. /help;mine
from /help;std etc.

jb








-----------------------------------------------------------------------------------
Post ID:975
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 01:31:03
Subject:Re: [rest-discuss] Algorithms and Data Structures
Message:


Paul Prescod wrote:

> If someone tells you that his website is organized as
> /foo/$year/$month/$index then you HAVE a priori knowledge of all of the
> things so addressed. It's just a very compact syntax for that knowledge.

Yes!!  YES!!!  This is EXACTLY what I'm talking about!!!

> Using a query you can reference the *same thing*, through one level of
> indirection.
>
> document(http://www.foo.com/bar?year=...&$month=...&index=...#xptr(//@href))

No.  It's not the same.  The case above is both more complex syntactically and *less*
meaningful.  By pushing things into the query string, you've lost the knowledge that
$month bears a subordinate relationship to $year.

jb








-----------------------------------------------------------------------------------
Post ID:976
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 01:33:40
Subject:Re: [rest-discuss] Onions
Message:


Paul Prescod wrote:

> While we're making editorial changes, its a weak rhetorical trick to
> equate the opacity axiom to the onion analogy. The onion was a bit of
> superstitious nonsense

So is the opacity axiom.

jb








-----------------------------------------------------------------------------------
Post ID:977
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 01:32:42
Subject:Re: [rest-discuss] Algorithms and Data Structures
Message:


Paul Prescod wrote:

> The only question is whether the $-variable to URI mappings happens on
> the client or the server. The set of addressable objects is exactly the
> same.

BTW, of *course* the set of addressible objects is going to be the same as long as
opacity is allowed to be violated somewhere in the name.  My contention is simply that
--- contrary to popular mistaken belief --- the world isn't going to come to an end if
we start allowing all the various pieces of the URI syntax to be usefully exploited.

jb








-----------------------------------------------------------------------------------
Post ID:978
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 01:38:38
Subject:Re: [rest-discuss] Onions in the Varnish
Message:


Paul Prescod wrote:

> That sounds very reasonable. But the hyperlink model is complete, in the
> same way that GET/PUT/POST/DELETE is complete. In the same way that
> lambda calculus primitives are complete.

How many times to I have to demonstrate that it's *not* complete?

> So Jeff needs to show that his
> way is simpler.

How many examples do you need?  Tell me what it requires, I'll provide it.

jb







-----------------------------------------------------------------------------------
Post ID:979
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-10 02:18:40
Subject:Re: [rest-discuss] Re: Offer/acceptance
Message:

> Ok, so we got:
> http://seller.com/thing
> 
> -To which URI the Buyer POSTs an offer to buy (i.e. Purchase Order).
> 
> And I'll focus on the case where the Seller responds to the Buyer 
> with an "Ack" document including a URI referring to an Acceptance or 
> Rejection document in the future.  Which the Buyer will check in the 
> future.  All the documents except the "Ack" are in the control of the 
> Seller.
> 
> Sorry if this is tedious, but if I rephrase, it may tell you if I 
> understand or not.  Did I?

I think so, except perhaps for that last sentence.  The ack is
returned as a response, not as a POST request, so technically
the seller still "controls" it.

> Ok, then, next complication:  the offer to buy should not be good 
> forever, it should have a time constraint.  At the appointed time, 
> the Buyer could check the URI for the Acceptance or Rejection 
> document and if it's not there, the deal is off.  How would you 
> handle that?  We want it to be clear to both parties that the deal is 
> off, so they don't end up in court because the Seller tried to keep 
> going.

You could do this two ways.  One would be as Mike said, to include
the time information in the document.  There's nothing wrong with
this at all.

Another way would be to generalize the whole "message validity"
mechanism and build an extension header with HTTP or SOAP to support
it for any message.  You'd need a mandatory extension mechanism to
deploy it, otherwise you'd never know if the receiver knew what you were
talking about.  That would be an interesting extension, for sure.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:980
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-10 03:07:43
Subject:[admin] rest-explore
Message:

I've created a new mailing list, rest-explore[1], which I would like to
ask that folks use for "exploratory" discussions, such as the current
discussion on opacity.

rest-discuss is gaining new members, most of whom are likely REST
beginners.  They may easily be turned-off by these types of discussions.

Thanks.

 [1] http://groups.yahoo.com/group/rest-explore/

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:981
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 03:43:52
Subject:Re: [rest-discuss] Re: More for Paul
Message:


Mark Baker wrote:

> That's the same thing.  There is no "linking to them" separate from
> simply "writing down their URI".

My point is that there are many ways to "write them down" that do not involve embedding them in a recognized, machine-usable
hypertext.

jb









-----------------------------------------------------------------------------------
Post ID:982
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 03:53:33
Subject:Re: [rest-discuss] Re: More for Paul
Message:

Paul Prescod wrote:

> Do you have any examples that are not a bit weak???

That depends on whether you can shake off the doctrine long enough to process the examples objectively.

> That's fine. Use the query as an index over or redirect to the
> hierarchical version.

I don't want or need to provide two versions when a single one suffices.

> Actually, this is just a convenience that makes mapping between
> file systems and URIs easier.

This is a false assertion.  It's not that (hierarchy, or more correctly graph-structuring a namespace) is a convenience for
mapping to filesystems, it's that it is (often) an appropriate information modeling technique.

> It is not core to the web architecture at
> all.

No, of course not.  The Web shouldn't prescribe particular information models for particular information spaces.

> My point is that your arguments in each situation are not
> problem-driven, they are theory-driven. If you had approached this whole
> situation like: "I was working on this problem and I found it very hard
> to solve with existing techniques."

Sod off, Paul, really.  If you yourself and your own efforts were subject to the same standards that you apparently want to
subject everybody else to, nobody'd be willing to discuss WRDL or HttpEvents or whatever with you, either.

> Google loses information in MSDN's URIs? That's ridiculous! The object's
> canonical URI does not change because someone, somewhere has indexed it.

I'm not saying the canonical URI changes, I'm saying that when you represent what is conceptually hierarchical information in
query strings you're losing the conceptual hierarchy.  This is a simple point.  I know you can get it.

jb








-----------------------------------------------------------------------------------
Post ID:983
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 03:58:15
Subject:Re: [rest-discuss] Onions in the Varnish
Message:


Paul Prescod wrote:

> "S. Mike Dierken" wrote:
> >
> > JeffB consistently says that it is only one of many tools and can/should be
> > used only in certain classes of problems, and he says that otherwise a pure
> > hyperlink approach is better.
> > ...
>
> That sounds very reasonable. But the hyperlink model is complete, in the
> same way that GET/PUT/POST/DELETE is complete.

This is a very sloppy statement.  What do you mean by complete?  What do you mean
by "hyperlink model"?  And how do you respond to the many, many examples that
have been offered where objects nameable by URI are added to the Webspace but are
not added to a hyperstructure.

> In the same way that
> lambda calculus primitives are complete. So Jeff needs to show that his
> way is simpler.

First, I'm happy to work on that if I can stop swatting away your spurious
assertions long enough.  Second, your sloppy claim above is the extraordinary
claim.

jb








-----------------------------------------------------------------------------------
Post ID:984
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 04:08:26
Subject:Re: [rest-discuss] [admin] rest-explore
Message:

This leaves a bad taste in my mouth.  The "axiom" of URI opacity is --- for
better or worse --- a part of the REST "doctrine."  This list is --- I
thought --- for discussing REST.  Punting anything that questions any given
part of the "official" REST dogma over somewhere else smacks of doctrinal
purification, in some sense changing this list from a true, open discussion
forum into an indoctrination forum.

Having said that, I do agree that the back-and-forth with me and Paul mostly
ceased to be useful or interesting some dozens of messages back.  I'll kill
that thread, and simply provide pointers to pages on the Wiki which are
appropriately indicated as being "heretical."

:-/

jb








-----------------------------------------------------------------------------------
Post ID:985
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-10 04:22:25
Subject:Re: [rest-discuss] [admin] rest-explore
Message:

> This leaves a bad taste in my mouth.  The "axiom" of URI opacity is --- for
> better or worse --- a part of the REST "doctrine."  This list is --- I
> thought --- for discussing REST.  Punting anything that questions any given
> part of the "official" REST dogma over somewhere else smacks of doctrinal
> purification, in some sense changing this list from a true, open discussion
> forum into an indoctrination forum.

That isn't the intent at all.  It's basically a "rest-discuss-advanced",
where any advanced topic should be discussed, from very REST-friendly
stuff, to pure unadulterated REST heresy.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:986
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-03-10 06:47:46
Subject:Resource modeling
Message:

Just curious -

One of the things that Mark talks about from time to time is 'resource 
modeling' - as I understand it, the process of finding the most RESTful 
way to express an application as a resource or group of resources.

To me, understanding of resource modeling is one of the things that 
blocks people from actually using REST and producing RESTful 
applications.

Considering that process modeling / architecture tools are fairly 
well-known and valued tools these days, how much of a leap is it from 
them to expressing an application in REST? For example, can one reuse 
UML and the tools available for working with it to model an application 
using REST?

(I'm asking from ignorance here; I know of these tools and appreciate 
their place in the universe, but don't use them.)

Regards,







-----------------------------------------------------------------------------------
Post ID:987
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-10 07:11:12
Subject:Re: [rest-discuss] Resource modeling
Message:

> Considering that process modeling / architecture tools are fairly 
> well-known and valued tools these days, how much of a leap is it from 
> them to expressing an application in REST? For example, can one reuse 
> UML and the tools available for working with it to model an application 
> using REST?

For some stuff, probably.  I stopped using these tools about the time I
grokked REST, so it's hard for me to say for sure.  You'd just have to
start out with some common classes, such as those I define in RestRDF,
from which all distributed components inherit their interfaces.

Beyond that, most of these tools use methodologies which are not well
suited to a data-transfer centric architecture such as REST, so any type
of simulation or execution would likely be problematic.

I'm sure we'll see the tools vendors catch up soon enough.

> (I'm asking from ignorance here; I know of these tools and appreciate 
> their place in the universe, but don't use them.)

I used to use them extensively.  I'm glad I don't anymore.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:988
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-10 07:46:45
Subject:Re: [rest-discuss] Algorithms and Data Structures
Message:

> > Using a query you can reference the *same thing*, through one level of
> > indirection.
> >
> >
document(http://www.foo.com/bar?year=...&$month=...&index=...#xptr(//@href))
>
> No.  It's not the same.  The case above is both more complex syntactically
and *less*
> meaningful.  By pushing things into the query string, you've lost the
knowledge that
> $month bears a subordinate relationship to $year.
>
I know that using the '/' as a 'sub' concept is easy to do and useful, but
it probably is better to treat it as a sequence rather than containment (in
general).

The path part is a sequence of values (accessed by index or position) and
the query part is a set of properties (named values - a point in a
multi-dimensional information space) accessed by name. The sequence of
values does not always imply containment though, especially of 'deep'
sequences.

for paths
 "/a/b" != "/b/a" (pretty obvious)

for query terms (and path segment properties)
 "year=1999&month=june" == "month=june&year=1999" (another obvious example)

so
 "/a/b/c/d" !imply "/a/*/c/d" (this is probably what you mean when you say
generative naming works best in non-sparse and regular information
structures [i'd call it a structure not a space, cause you traverse to data
rather than vector to data {or maybe that's the point, when a structure is
really a space}])

But it might be useful to be able to tell clients under what situations and
for what resources that containment does hold though.

mike







-----------------------------------------------------------------------------------
Post ID:989
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-10 07:56:22
Subject:Re: [rest-discuss] Re: More for Paul
Message:


> I'm not saying the canonical URI changes, I'm saying that when you
represent what is conceptually hierarchical information in
> query strings you're losing the conceptual hierarchy.  This is a simple
point.  I know you can get it.

So, like you are claiming that taking a sequence of values (like an array)
and converting it to named values (like a hashtable) then you lose
information? Well you might be right.
But what about the names that are introduced? are those an artifact of the
conversion or 'more authoritative' information.

And what about the inverse - taking a set of properties (named values) and
turning them into a sequence of values. The names disappear, but a sequence
(relationships) appear. Where did this presto magico information come from?
(...and don't start on about zero-point energy...)

Its interesting to think about function calls in procedural languages - some
have parameters that are named but not sequenced (like Ada I think) and
others have parameters that are sequenced but not named (like assembly) and
others have source code with name and sequence but have compiled code with
only sequence. Well, okay, its interesting to me...








-----------------------------------------------------------------------------------
Post ID:990
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-10 15:44:45
Subject:Re: Offer/acceptance
Message:

Mark Baker wrote:

> > Ok, then, next complication:  the offer to buy should not be good 
> > forever, it should have a time constraint.  At the appointed 
time, 
> > the Buyer could check the URI for the Acceptance or Rejection 
> > document and if it's not there, the deal is off.  How would you 
> > handle that?  We want it to be clear to both parties that the 
deal is 
> > off, so they don't end up in court because the Seller tried to 
keep 
> > going.
> 
> You could do this two ways.  One would be as Mike said, to include
> the time information in the document.  There's nothing wrong with
> this at all.
> 
> Another way would be to generalize the whole "message validity"
> mechanism and build an extension header with HTTP or SOAP to support
> it for any message.  You'd need a mandatory extension mechanism to
> deploy it, otherwise you'd never know if the receiver knew what you 
were
> talking about.  That would be an interesting extension, for sure.

Regardless of how the time constraint is expressed (an element of the 
Order document is fine with me), the issue I was trying to raise was 
how to make the order explicitly defunct.  Could be deleted, but 
that's often disallowed in business.  So it should be canceled.  And 
let's say that it is the Buyer's responsibility to do so.

Just to indicate more where I am going with this line of inquiry, the 
next problem I want to think about is the "counteroffer pending" 
response, where the Seller will next make a counteroffer to the 
Buyer.  

Where I am trying to go is into the resource model for this stuff: 
what becomes a Web resource, where?  

-Bob Haugen 







-----------------------------------------------------------------------------------
Post ID:991
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-10 16:53:14
Subject:Re: [rest-discuss] Onions in the Varnish
Message:

Jeff Bone wrote:
> 
>...
> 
> This is a very sloppy statement.  What do you mean by complete?  What do you mean
> by "hyperlink model"?  

If an information provider wants to provide access to information
objects, no matter how many or how opaque, and they have control over a
web server then they can provide this access using hypertext documents.
We have twelve years of experience to back that up. I can point to
dozens of applications where opaque, regularly named information objects
were served through the web without client-side URI munging. If an
information provider chooses not to use the standard web mechanisms to
reference their data objects then they are simply being irresponsible
and shifting the burden onto their information consumers. 

As an information consumer, of course I may choose to "hack" based on
things I notice about their namespaces. I might also choose to take
advantage of things I know about their HTTP Server implementation or
cache too. But that doesn't mean that it is *good practice* to make
client-side assumptions about either namespace structure or web server
implementation.

> ... And how do you respond to the many, many examples that
> have been offered where objects nameable by URI are added to the Webspace but are
> not added to a hyperstructure.

If somebody chooses not to give something a hypertext interface on the
Web then I don't really see why I have any responsibility to help them.
They could similarly complain that the Web forces you to give everything
a URI. Yep. That's how it works. Anything can be given a URI without
great expense and anything can be addressed through hypertext without
great expense. REST is about simplifying component interfaces through
constraints. These are two simplifying constraints. I would be similarly
frustrated if someone started a big discussion about "should web
addressing really be limited to URIs?"

That's the last I'll say on rest-discuss on the issue.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:992
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 17:50:11
Subject:Re: [rest-discuss] [admin] rest-explore
Message:

Fair enough.

Mark Baker wrote:

> > This leaves a bad taste in my mouth.  The "axiom" of URI opacity is --- for
> > better or worse --- a part of the REST "doctrine."  This list is --- I
> > thought --- for discussing REST.  Punting anything that questions any given
> > part of the "official" REST dogma over somewhere else smacks of doctrinal
> > purification, in some sense changing this list from a true, open discussion
> > forum into an indoctrination forum.
>
> That isn't the intent at all.  It's basically a "rest-discuss-advanced",
> where any advanced topic should be discussed, from very REST-friendly
> stuff, to pure unadulterated REST heresy.
>
> MB
> --
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@...
> http://www.markbaker.ca   http://www.planetfred.com
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:993
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 17:56:50
Subject:Re: [rest-discuss] Algorithms and Data Structures
Message:


"S. Mike Dierken" wrote:

> I know that using the '/' as a 'sub' concept is easy to do and useful, but
> it probably is better to treat it as a sequence rather than containment (in
> general).

Yes!  This is absolutely correct.  In fact, this parallels how '/' is viewed and
what paths mean in some of the more advanced filesystem namespace uses.  Path
elements can be more profitably viewed as named "views" on some part of an
information space, and "/" becomes a mechanism for composing those views,
expressing in some sense subordinate views which "narrow" a larger view.

This is a general problem with modeling, too.  This problem actually bit us in
the ass at Clickfeed.  We had "feeds" --- i.e., categories --- which contained
"items" --- i.e., blogged or grazed metadata and annotations about blog items or
external news articles.  The problem was that, because of a strict notion of
containment, it was difficult for a single item to be in more than one feed.
Our 2nd-gen architecture addressed this by separating the feedspace from the
itemspace, making feedspace a richer, composable namespace which indirectly and
dynamically provided views on itemspace.

jb








-----------------------------------------------------------------------------------
Post ID:994
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 18:00:48
Subject:Re: [rest-discuss] Re: More for Paul
Message:


"S. Mike Dierken" wrote:

> So, like you are claiming that taking a sequence of values (like an array)
> and converting it to named values (like a hashtable) then you lose
> information? Well you might be right.
> But what about the names that are introduced? are those an artifact of the
> conversion or 'more authoritative' information.

Yes, there are pros and cons.  A strings of things separated with "/"-type
delimiters contains ordinal information and structural information.  Pushing the
same thing into named but non-ordinal query strings loses the ordinal and
structural information but introduces descriptive information about the "type"
of the elements.

I'm working on a detailed example of using structured names to represent
taxonomy that I'll post a link to later;  hopefully, it addresses Paul's
questions by providind a detailed and realistic example of why you don't want to
just shove everything into the query string to accomodate some notion of what
part of the URI should be "opaque."

jb









-----------------------------------------------------------------------------------
Post ID:995
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 18:06:11
Subject:Re: [rest-discuss] Onions in the Varnish
Message:


Paul Prescod wrote:

> If somebody chooses not to give something a hypertext interface on the
> Web then I don't really see why I have any responsibility to help them.
> They could similarly complain that the Web forces you to give everything
> a URI. Yep. That's how it works.

Let's review this again.  Sure, the Web forces you to give everything a URI.  HTTPspace
is a subspace of URIspace.  However, the Web *specifically* and *by design* does not
force a hypertext interface for everything.  The HTTP and URI specs have very little to
say about hypertext specifically.  HTMLspace / XMLspace are subspaces of HTTPspace.
Anything in HTTPspace, or indeed in URIspace, can be addressed from *MLspace, but the
extent of the larger spaces is not constrained by what is reified in the smaller
spaces.

I think it's a bad idea to assume equivalence.

> Anything can be given a URI without
> great expense and anything can be addressed through hypertext without
> great expense. REST is about simplifying component interfaces through
> constraints. These are two simplifying constraints.

IMO, it's not a "simplifying" or empowering constraint to assume that, in order to use
something, I have to reify a reference to it in hypertext.

> That's the last I'll say on rest-discuss on the issue.

Ditto.

jb








-----------------------------------------------------------------------------------
Post ID:996
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-10 21:06:03
Subject:Re: [rest-discuss] Re: Offer/acceptance
Message:

> Regardless of how the time constraint is expressed (an element of the 
> Order document is fine with me), the issue I was trying to raise was 
> how to make the order explicitly defunct.  Could be deleted, but 
> that's often disallowed in business.  So it should be canceled.  And 
> let's say that it is the Buyer's responsibility to do so.

If the seller wants to give the buyer that option, I suppose it
could return a 201 (Created) response with the URI of the offer
in the Location header of the response.  Then the buyer would
just DELETE it to cancel the order.

If richer cancellation semantics are required, a separate "cancel"
document should be used, since I would expect that somebody would
want to track that as a separate document.  i.e the buyer POSTs a
"cancel order" document which includes a link to the offer resource
URI returned on the aforementioned 201 response.

> Just to indicate more where I am going with this line of inquiry, the 
> next problem I want to think about is the "counteroffer pending" 
> response, where the Seller will next make a counteroffer to the 
> Buyer.

Does the offer of a counteroffer infer a rejection of the original
offer?  I would expect so.  So in that case, the response to the
offer document being POSTed could be a rejection document which
included a URI to a counteroffer.  Or it could be included inline
as part of the rejection.

> Where I am trying to go is into the resource model for this stuff: 
> what becomes a Web resource, where?  

Everything with identity is a resource.  That doesn't mean that a
representation has to be retrieved with a GET though; it's fine for it
to be sent as a request or response, with the Content-Location header
included so that the recipient can do a GET later if required.

In this case, the initial offer from buyer to seller would be POSTed
with a Content-Location header, and the seller *could* invoke GET if
they lost their copy 8-) (other cases might have a better use of GET).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:997
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-10 21:32:20
Subject:Paths And Query Strings
Message:

I've added another heretical ;-) page [1] to the RESTWiki about
the use of paths vs. query strings.  It includes a semi-detailed
taxonomic example and comparisons of the pros and cons of
structural path-based URI, ordinal query-based URI, and keyword
query-based URI.

Followups on rest-explore.

jb

[1] http://conveyor.com/RESTwiki/moin.cgi/PathsAndQueryStrings







-----------------------------------------------------------------------------------
Post ID:998
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-03-10 21:42:30
Subject:Re: Offer/acceptance
Message:

Mark Baker wrote:
> If the seller wants to give the buyer that option, I suppose it
> could return a 201 (Created) response with the URI of the offer
> in the Location header of the response.  Then the buyer would
> just DELETE it to cancel the order.
> 
> If richer cancellation semantics are required, a separate "cancel"
> document should be used, since I would expect that somebody would
> want to track that as a separate document.  i.e the buyer POSTs a
> "cancel order" document which includes a link to the offer resource
> URI returned on the aforementioned 201 response.
> 
> > Just to indicate more where I am going with this line of inquiry, 
the 
> > next problem I want to think about is the "counteroffer pending" 
> > response, where the Seller will next make a counteroffer to the 
> > Buyer.
> 
> Does the offer of a counteroffer infer a rejection of the original
> offer?  I would expect so.  

Yes. You understand contract negotiation rules.

> So in that case, the response to the
> offer document being POSTed could be a rejection document which
> included a URI to a counteroffer.  Or it could be included inline
> as part of the rejection.
> 
> > Where I am trying to go is into the resource model for this 
stuff: 
> > what becomes a Web resource, where?  
> 
> Everything with identity is a resource.  That doesn't mean that a
> representation has to be retrieved with a GET though; it's fine for 
it
> to be sent as a request or response, with the Content-Location 
header
> included so that the recipient can do a GET later if required.
> 
> In this case, the initial offer from buyer to seller would be POSTed
> with a Content-Location header, and the seller *could* invoke GET if
> they lost their copy 8-) (other cases might have a better use of 
GET).

Ok, I am happy with this discussion at this stage.  Thank you very 
much. 

I am now in the midst of working through this same example with a lot 
more detail in a couple of ebXML-related work groups.  When they get 
done, I'll come back here and see if I can take the various clues and 
propose a RESTful offer-acceptance model that will also satisfy the 
ebXML groups.

Then I will invite them to comment.

In the meantime, I'm still reading most of the list traffic and may 
chip in from the peanut gallery now and then.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:999
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-10 22:26:25
Subject:Re: [rest-discuss] Paths And Query Strings
Message:

Jeff Bone wrote:
> 
>...
> 
> Followups on rest-explore.
> 
> jb
> 
> [1] http://conveyor.com/RESTwiki/moin.cgi/PathsAndQueryStrings

My take: http://conveyor.com/RESTwiki/moin.cgi/UriFormsAreIrrelevantImho

Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1000
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-11 08:42:46
Subject:Serialized RDF messages and REST
Message:

Has anyone done any serialized RDF as request messages?

--
Here's an interesting message from the past:

direct:
http://lists.w3.org/Archives/Public/www-rdf-interest/1999Nov/0060.html

google[0]: http://www.google.com/search?hl=en&q=serialized+rdf+request








-----------------------------------------------------------------------------------
Post ID:1001
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-11 08:47:49
Subject:RDF Database Access Protocol
Message:

Cool, another protocol from the W3C.

--
RDF Database Access Protocol
http://www.w3.org/2002/01/rdf-databases/protocol

--
Protocol Abstraction
We'll say that RDF Database Clients communicate with RDF Database Servers by
exchanging serialized objects. The serialization may look like SQL, LISP,
XML, N-Triples, etc. The underlying protocols may be TCP, UDP, HTTP, SMTP,
etc. In other words, something like

  INSERT
    INTO DATABASE <http://example.com/temperature-readings>
    TRIPLE (<http://example.com/temperature-readings#reading311232>,
            <http://example.com/temperature-readings#locationName>,
     "Waltham");

is basically the same as
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
           xmlns="http://www.w3.org/2002/01/rdap/ont-1#" >
    <InsertionRequest>
       <database rdf:resource="http://example.com/temperature-readings" />
       <rdf:subject
        rdf:resource="http://example.com/temperature-readings#reading311232"
/>
       <rdf:predicate
        rdf:resource="http://example.com/temperature-readings#locationName"
/>
       <rdf:object>Waltham</rdf:object>
    </InsertionRequest>
  </rdf:RDF>

and we wont worry about which kind of syntaxes people are using for now.
(These are just vague examples; I don't know if they are really workable
syntaxes.)

Note that we cannot nicely map this to an API, because some of the
operations have a recursive structure. For example we'd like "delete
triple(a,b,c)" and "foreach ?x where ?x=c do delete triple(a,b,?x)" to use
the same "delete" operation. We'd also like to be able to nest foreach
within foreach, etc. We can only do this with an API like "do(RequestObject)
returns ResponseObject". So our focus remains on designing Request and
Response objects.

We'll consider HTTP GET of an XML/RDF file as a kind of degenerate
query-for-everything, PUT as a replace-entire-database-contents. That works
for some things, but many other times we'll want more fine-grained access.








-----------------------------------------------------------------------------------
Post ID:1002
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-11 13:27:21
Subject:Re: [rest-discuss] Serialized RDF messages and REST
Message:

> Has anyone done any serialized RDF as request messages?

This was one of the things I've considered doing with RestRDF.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1003
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-11 17:46:17
Subject:Re: [rest-discuss] RDF Database Access Protocol
Message:

>   INSERT
>     INTO DATABASE <http://example.com/temperature-readings>
>     TRIPLE (<http://example.com/temperature-readings#reading311232>,
>             <http://example.com/temperature-readings#locationName>,
>      "Waltham");
> 
> is basically the same as
>   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>            xmlns="http://www.w3.org/2002/01/rdap/ont-1#" >
>     <InsertionRequest>
>        <database rdf:resource="http://example.com/temperature-readings" />
>        <rdf:subject
>         rdf:resource="http://example.com/temperature-readings#reading311232"
> />
>        <rdf:predicate
>         rdf:resource="http://example.com/temperature-readings#locationName"
> />
>        <rdf:object>Waltham</rdf:object>
>     </InsertionRequest>
>   </rdf:RDF>

Tunneling alert!  "InsertionRequest" is a verb dressed up as noun.  POST
is sufficient for meaning "insert".  Also, the database should be the
URI that is being POSTed to.

I think I've figured out how to "resource model" SQL.  I'll add it to my
todo list to writeup.  Nothing earth shattering, but it should hopefully
put this issue to rest (so to speak 8-).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1004
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-09 19:31:48
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>

>
> The issue is, can somebody else infer that because they see;
>
> http://www.dierken.com/email/foo@...
>
> that there exists a URI
>
> http://www.dierken.com/email/asdfasdf@...
>
> I say no, unless somehow dierken.com asserts that /email is a container
> of arbitrary email addresses.
>

Me too. So now on to the 'somehow' part. If dierken.com were to express that
fact, what would it look like?

Also, would it be 'dierken.com' asserting that, or 'www.dierken.com' or
'www.dierken.com/email' that did the asserting? What's the 'logical
information authority' for asserting statements about resources?






-----------------------------------------------------------------------------------
Post ID:1005
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-11 21:16:46
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:

> > The issue is, can somebody else infer that because they see;
> >
> > http://www.dierken.com/email/foo@...
> >
> > that there exists a URI
> >
> > http://www.dierken.com/email/asdfasdf@...
> >
> > I say no, unless somehow dierken.com asserts that /email is a container
> > of arbitrary email addresses.
> >
> 
> Me too. So now on to the 'somehow' part. If dierken.com were to express that
> fact, what would it look like?

Actually, I'd like to change my mind and say that this still isn't a
great idea because a query term already allows it.  And the way that is
currently asserted is if you see a HTML FORM that says;

  <form action="http://www.dierken.com/email/" method="get">
   <input type="text" name="email"/>
  </form>

> Also, would it be 'dierken.com' asserting that, or 'www.dierken.com' or
> 'www.dierken.com/email' that did the asserting? What's the 'logical
> information authority' for asserting statements about resources?

Sorry, I mistyped.  It's up to the registrant of dierken.com to decide
this stuff.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1006
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-11 21:37:12
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re: Opacity Reconsidered
Message:


Mark Baker wrote:

> Actually, I'd like to change my mind and say that this still isn't a
> great idea because a query term already allows it.  And the way that is
> currently asserted is if you see a HTML FORM that says;
>
>   <form action="http://www.dierken.com/email/" method="get">
>    <input type="text" name="email"/>
>   </form>

So:  in order to access the resource in question, a "client" needs to be able to
understand not only URI+HTTP, but also HTML?

jb








-----------------------------------------------------------------------------------
Post ID:1007
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-11 21:54:26
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re:
Message:

> > Actually, I'd like to change my mind and say that this still isn't a
> > great idea because a query term already allows it.  And the way that is
> > currently asserted is if you see a HTML FORM that says;
> >
> >   <form action="http://www.dierken.com/email/" method="get">
> >    <input type="text" name="email"/>
> >   </form>
> 
> So:  in order to access the resource in question, a "client" needs to be able to
> understand not only URI+HTTP, but also HTML?

Not at all.  I said "currently".  Any machine processable format would
suffice.  I don't know that RDF has anything to say about query terms
(hmm), but things like WRDL and WSDL do.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1008
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-11 22:35:20
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re:
Message:


Mark Baker wrote:

> > > Actually, I'd like to change my mind and say that this still isn't a
> > > great idea because a query term already allows it.  And the way that is
> > > currently asserted is if you see a HTML FORM that says;
> > >
> > >   <form action="http://www.dierken.com/email/" method="get">
> > >    <input type="text" name="email"/>
> > >   </form>
> >
> > So:  in order to access the resource in question, a "client" needs to be able to
> > understand not only URI+HTTP, but also HTML?
>
> Not at all.  I said "currently".  Any machine processable format would
> suffice.  I don't know that RDF has anything to say about query terms
> (hmm), but things like WRDL and WSDL do.

So let me restate my question:  in order to access the resource in question, a
"client" needs to be able to understand not only URI+HTTP, but also some form of
hypermedia?

jb








-----------------------------------------------------------------------------------
Post ID:1009
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-11 22:48:37
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re:
Message:

> So let me restate my question:  in order to access the resource in question, a
> "client" needs to be able to understand not only URI+HTTP, but also some form of
> hypermedia?

Of course.  The client needs additional info, even in your solution.
Otherwise they're just assuming stuff which doesn't help with the
"uniform" part of "URI".

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1010
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-11 22:45:42
Subject:What breaks if path opacity is ignored?
Message:

(NB:  I'm posting this to rest-discuss as well as rest-explore
because it's a reasonably fundamental question that may be useful
in helping even newcomers to REST understand the doctrine.)

So, simple question:  *what breaks* if you allow clients and
servers to agree on mechanisms for clients to generate /
construct URI in the server's address space by name?  As an
example, The Wayback Machine at archive.org provides explicit
details [1] on how users (and software) can construct strings to
reference resources in the archive.

Why this this a bad, subversive, dangerous thing?

jb

[1] http://web.archive.org/collections/web/advanced.html









-----------------------------------------------------------------------------------
Post ID:1011
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-11 22:48:57
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re:
Message:


Mark Baker wrote:

> > So let me restate my question:  in order to access the resource in question, a
> > "client" needs to be able to understand not only URI+HTTP, but also some form of
> > hypermedia?
>
> Of course.  The client needs additional info, even in your solution.

Not necessarily.  If my goal is to, for instance, simply provide a naked,
hierarchical, filesystem like space in which containers can be created and deleted and
opaque blobs created, updated, and deleted --- all by name --- then I don't really
need any more information at all other than the hierarhical organization.  URI+HTTP
suffice.

jb








-----------------------------------------------------------------------------------
Post ID:1012
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-11 23:18:31
Subject:Re: [rest-discuss] What breaks if path opacity is ignored?
Message:

Jeff Bone wrote:
> 
>...
> 
> So, simple question:  *what breaks* if you allow clients and
> servers to agree on mechanisms for clients to generate /
> construct URI in the server's address space by name?  As an
> example, The Wayback Machine at archive.org provides explicit
> details [1] on how users (and software) can construct strings to
> reference resources in the archive.
> 
> Why this this a bad, subversive, dangerous thing?

Nothing breaks. Things start to break if the *only way* to find out how
to get information out of a web-based service is through generated URIs.
The first thing that would break if this convention became common on the
Web is the Wayback Machine itself (and Google!). After all, it collects
information by spidering the web and spiders work through links, not
generated URI names.

I don't mind the half of your philosophy that says: "consistent,
guessable names are usually a good idea." The part that I disagree with
is: "Hey, if I use consistent, guessable names, I can get away without
hypertext indexes of my data." If you have a collection of data on the
web that you want people to treat as a true collection then you should
provide an index to it.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1013
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-11 23:19:49
Subject:Names as Queries, Names as Commands
Message:

(NB:  I'm crossposting this one as well because I think a
detailed response to this might be useful both the the neophyte
and the enlightened. Warning:  this document does touch on some
REST heresy.  ;-)

There are basically three ways to think about URI:  they are
pointers, or they are queries, or they are commands in an
arbitrarily expressive (possibly computationally-complete)
language.  The official REST position is that they are pointers
*only,* and provide a limited form of pointer arithmetic
(relative URI) in a rigidly constrained context (embedded in
hypermedia.)  (Well, okay, even a REST purist agrees that
pointers are not sufficient, and we must supplement opaque
pointers with arbitrary query strings to make them useful.  Thus
the slippery slope begins...)

The "heretical" position that I've been exploring is the
treatment of URI as queries rather than pointers.  By opening up
the URI to interpretation and construction on both ends of a
communication instead of just at the server, we turn the URI
namespace into a robust query engine and open up the model space.

Yet another way, even more questionable way to view URI is as
commands.  One very interesting piece of work that does this is
AT&T Research's iProxy.  iProxy is an application server deployed
as a personal client-side proxy;  it sits in the HTTP stream
doing normal proxy-like stuff (e.g. caching) but supports
arbitrary local applications (e.g. archiving) as well as stream
applications on proxied HTTP traffic (e.g. filtering).  It does
this by allowing actual request URI to be supplemented by,
essentially, appending "command strings" on the end of the URI.
These commands are parsed out and interpreted by iProxy.  The
particular way they are doing it seems rather icky to me, but
it's an interesting thought --- and I waffle between thinking
that this is a decidedly non-RESTful thing (in particular,
iProxy's own resource model isn't obvious or usefully exposed)
and thinking it's very RESTful.

Anyone (Mark, Paul, Mike?) care to take a look at iProxy and
render an opinion?  Cf. [1-5]

jb

[1] http://www.research.att.com/sw/tools/iproxy/
[2] http://www.research.att.com/~iproxy/webnet99
[3] http://www.research.att.com/~iproxy/archive
[4] http://www.research.att.com/~iproxy/papers/imobile.pdf
[5] http://www.research.att.com/~iproxy/iproxy-api.doc







-----------------------------------------------------------------------------------
Post ID:1014
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-11 23:40:03
Subject:Re: [rest-explore] Re: [rest-discuss] What breaks if path opacity is ignored?
Message:


Paul Prescod wrote:

> I don't mind the half of your philosophy that says: "consistent,
> guessable names are usually a good idea." The part that I disagree with
> is: "Hey, if I use consistent, guessable names, I can get away without
> hypertext indexes of my data."

I have never, ever, ever said this in the course of our discussion.  This is
ghost of your own creation haunting your perception of this debate.  I have
been very explicit that, in the general case, hypertext indexes (lists,
navigational structures, etc. --- the namespace is the query space
regardless) are desirable wherever they are possible.

> If you have a collection of data on the
> web that you want people to treat as a true collection then you should
> provide an index to it.

So:  drill down on what you mean, specifically, by index.

jb








-----------------------------------------------------------------------------------
Post ID:1015
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-12 00:01:33
Subject:Re: [rest-discuss] Re: Teaching Paul about Filesystems ;-) was re:
Message:

> Not necessarily.  If my goal is to, for instance, simply provide a naked,
> hierarchical, filesystem like space in which containers can be created and deleted and
> opaque blobs created, updated, and deleted --- all by name --- then I don't really
> need any more information at all other than the hierarhical organization.  URI+HTTP
> suffice.

I wonder how this is different from a company which permits personal
homepages (just as an example).  At some point in the hierarchy, the
company basically relinquishes any control over the namespace and the
authority becomes the employee.  But the "containment" relationship
persists between authorities, whether that relationship represents
"employment" (in this case) or "customer of" (in the case of, say,
Yahoo/Geocities).  Definitely a "Web of Trust" topic.

But in your example, is it your intent that the person PUTting into
this empty namespace be the authority for it?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1016
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-03-11 23:58:12
Subject:Re: [rest-explore] Re: [rest-discuss] What breaks if path opacity is ignored?
Message:

I'm taking this back to rest-explore...if the rest-discuss people wanted
to be in on it they would have joined rest-explore.

Jeff Bone wrote:
> 
> Paul Prescod wrote:
> 
> > I don't mind the half of your philosophy that says: "consistent,
> > guessable names are usually a good idea." The part that I disagree with
> > is: "Hey, if I use consistent, guessable names, I can get away without
> > hypertext indexes of my data."
> 
> I have never, ever, ever said this in the course of our discussion.  This is
> ghost of your own creation haunting your perception of this debate.  I have
> been very explicit that, in the general case, hypertext indexes (lists,
> navigational structures, etc. --- the namespace is the query space
> regardless) are desirable wherever they are possible.
> 
> > If you have a collection of data on the
> > web that you want people to treat as a true collection then you should
> > provide an index to it.
> 
> So:  drill down on what you mean, specifically, by index.
> 
> jb
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/






-----------------------------------------------------------------------------------
Post ID:1017
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-12 00:41:45
Subject:Query Strings Considered Harmful
Message:

NB:  REST heresy?  Or REST clarification?

I've added a page to the Wiki exploring the implications of
applying the axiom of opacity too strongly.  It results again in
a paradoxical result:  if interpreted too stringently, it (or
rather the (ab)use of its loophole, the query string) results in
the inability to treat URI as opaque in contexts where that's
necessary.  I conclude that the axiom of opacity should be
discarded and replaced by two better axioms, the "axiom of
lexical equivalence" and the "axiom of canonical names."


http://conveyor.com/RESTwiki/moin.cgi/QueryStringsConsideredHarmful

jb









-----------------------------------------------------------------------------------
Post ID:1018
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-12 01:43:11
Subject:Re: [rest-discuss] What breaks if path opacity is ignored?
Message:

I agree with Paul, mostly, but from my investigation into URI opacity,
I basically concluded that;

http://foo.com/bar?a=b

implies the existance of a resource identified by;

http://foo.com/bar

There's no such inferred relationship between

http://foo.com/bar/b

and

http://foo.com/bar/ (or http://foo.com/bar - another reason why "/"
has to be opaque)

It's not clear to me what this means right now, but it is extra
information that can be extracted from a URI that is unavailable in
"/" based URI.  Who knows what neat stuff we might be forgoing in the
future by not using it?

Also, a practical issue is that any web server I've used typically
makes it a lot easier to bind a chunk of code to query based URI than
hierarchical based URI.  By that I mean that foo.com/bar?a=b, by
default, gets processed by the processor bound to foo.com/bar, but you
often have to jump through hoops (URI rewriting, etc..) to get
foo.com/bar/baz/ processed by the processor bound to foo.com/bar/.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1019
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-12 02:01:06
Subject:Re: [rest-discuss] What breaks if path opacity is ignored?
Message:


Mark Baker wrote:

> I agree with Paul, mostly, but from my investigation into URI opacity,
> I basically concluded that;
>
> http://foo.com/bar?a=b
>
> implies the existance of a resource identified by;
>
> http://foo.com/bar
>
> There's no such inferred relationship between
>
> http://foo.com/bar/b
>
> and
>
> http://foo.com/bar/ (or http://foo.com/bar - another reason why "/"
> has to be opaque)

This is all true.  However, if in a hyptertext representation of
http://foo.com/bar/b I encounter <a href=".."> I can infer --- indeed, the
hypertext processor is being explicitly told --- that http://foo.com/bar/ is
a resource.  So my question is this:  what is special about hypertext and
hypertext processors that they should be allowed to do this?  I'm not
suggesting that this kind of inference is valid in the absence of explicit
information, but I am wondering why the contract between client and server
must be markup.  There are cases where this is desirable, but there are cases
where it is not.

> It's not clear to me what this means right now, but it is extra
> information that can be extracted from a URI that is unavailable in
> "/" based URI.  Who knows what neat stuff we might be forgoing in the
> future by not using it?

If I'm parsing this correctly, then this is precisely the point I'm making.
The axiom of opacity is vague and --- clearly, given the discussion we've had
about it --- open to interpretation, even among smart folks who would work
hard to do things "the right way."  The problem is we may be throwing the
baby out with the bathwater.

My conclusion from looking at how the axiom is used and abused and the
implications of such abuse is that the real *technical* motivation for
opacity is to allow (a) lexical equivalence testing by spiders, proxies,
mapping systems, and so forth, and (b) canonical URI for resources.  This is
all well and good and desirable, but a too-strict interpretation of the axiom
ironically encourages URI that do not achieve these goals.  It would be
better to state these goals explicitly as axioms rather than state an
overgeneralization with paradoxical implications as an axiom.

> Also, a practical issue is that any web server I've used typically
> makes it a lot easier to bind a chunk of code to query based URI than
> hierarchical based URI.

Without a doubt.  It's unfortunate that the very software that builds the
most powerful namespace in the world so completely fails to give us tools for
using that namespace in powerful, flexible ways.

jb








-----------------------------------------------------------------------------------
Post ID:1020
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-12 05:29:05
Subject:Re: [rest-discuss] What breaks if path opacity is ignored?
Message:

>
> Also, a practical issue is that any web server I've used typically
> makes it a lot easier to bind a chunk of code to query based URI than
> hierarchical based URI.  By that I mean that foo.com/bar?a=b, by
> default, gets processed by the processor bound to foo.com/bar, but you
> often have to jump through hoops (URI rewriting, etc..) to get
> foo.com/bar/baz/ processed by the processor bound to foo.com/bar/.

In addition JSP and ASP prevent path based processing - you can't do
foo.com/bar.asp/baz/ or foo.com/bar.jsp/baz/ - which just plain sucks rocks.
(I built a system that /depended/ on path based access to sub-information.
Its all broken now. Thanks JCP.)








-----------------------------------------------------------------------------------
Post ID:1021
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-03-12 18:18:52
Subject:Re: [rest-discuss] What breaks if path opacity is ignored?
Message:

On Monday, March 11, 2002, at 06:01  PM, Jeff Bone wrote:
>
> This is all true.  However, if in a hyptertext representation of
> http://foo.com/bar/b I encounter <a href=".."> I can infer --- indeed, 
> the
> hypertext processor is being explicitly told --- that 
> http://foo.com/bar/ is
> a resource.  So my question is this:  what is special about hypertext 
> and
> hypertext processors that they should be allowed to do this?

Absolutely nothing. This behaviour is specified by RFC1808, not the HTML 
spec. If you want to use a relative URI in Flash, in RDF, in SVG, in 
MIME messages, in XML - it acts the same way. It just happens that HTML 
is the most widely deployed.


>> Also, a practical issue is that any web server I've used typically
>> makes it a lot easier to bind a chunk of code to query based URI than
>> hierarchical based URI.
>
> Without a doubt.  It's unfortunate that the very software that builds 
> the
> most powerful namespace in the world so completely fails to give us 
> tools for
> using that namespace in powerful, flexible ways.

I so agree. This is one of the things that URISpace [1] groped around; 
having one flexible, URI-savvy format for configuring your server 
(including authentication, authorisation, processing, http headers, 
etc.), your surrogate (aka reverse proxy), as well as things like robots 
control and privacy policies would be very powerful.

1. http://www.w3.org/TR/urispace.html

--
Mark Nottingham
http://www.mnot.net/







-----------------------------------------------------------------------------------
Post ID:1022
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-12 18:37:35
Subject:Re: [rest-discuss] What breaks if path opacity is ignored?
Message:


Mark Nottingham wrote:

> Absolutely nothing. This behaviour is specified by RFC1808, not the HTML
> spec. If you want to use a relative URI in Flash, in RDF, in SVG, in
> MIME messages, in XML - it acts the same way. It just happens that HTML
> is the most widely deployed.

Exactly! :-)

> I so agree.

Fabulous! :-)

jb








-----------------------------------------------------------------------------------
Post ID:1023
Sender:Michael Brennan <michael_brennan@...>
Post Date/Time:2002-03-12 21:41:07
Subject:RE: [rest-discuss] What breaks if path opacity is ignored?
Message:

> From: S. Mike Dierken [mailto:mdierken@...]

<snip/>

> In addition JSP and ASP prevent path based processing - you can't do
> foo.com/bar.asp/baz/ or foo.com/bar.jsp/baz/ - which just 
> plain sucks rocks.
> (I built a system that /depended/ on path based access to 
> sub-information.
> Its all broken now. Thanks JCP.)

Actually, more recent versions of the servlet specs provide a standard
mechanism for mapping paths to servlets. Using this, you can implement your
own dispatcher in the form of a servlet. It just needs some URL base mapped
to it. You could (I believe) have the dispatcher invoke JSPs.

This is certainly more work, though, and current tools are certainly not
geared toward the sort of approach to web development advocated by REST. And
for ASP, AFAIK you'd have to implement an ISAPI filter to do this, which is
not trivial and is beyond the skill set of the typical web developer.






-----------------------------------------------------------------------------------
Post ID:1024
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-03-13 07:16:57
Subject:Re: [rest-discuss] What breaks if path opacity is ignored?
Message:

----- Original Message -----
From: "Michael Brennan" <michael_brennan@...>

>
> Actually, more recent versions of the servlet specs provide a standard
> mechanism for mapping paths to servlets. Using this, you can implement
your
> own dispatcher in the form of a servlet. It just needs some URL base
mapped
> to it. You could (I believe) have the dispatcher invoke JSPs.
The standard mechanism for mapping paths to servlets is conceptually broken.

From the servlet 2.3 spec (in web friendly PDF) on the JCP site:
http://jcp.org/aboutJava/communityprocess/first/jsr053/servlet23_PFD.pdf
"If the last node of the url-path contains an extension (.jsp for example),
the servlet container will try to match a servlet that handles requests for
the extension. An extension is defined as the part of the path after the
last '.' character."

The section is ambigous about handling urls of the form
"/a/b/foo.xap/x/y/z" - it implies that "/a/b/foo.xap" must be registered
with the servlet container (often via a manually edited text file). I was
going for any number of *.xap files on disk.

I've never met an ASP/JSP programmer that cared in the least what this meant
for their larger design. They didn't notice that relative URLs aren't
possible and the server has to compute static text constantly.

The dispatcher that I wrote a few years ago was a servlet. It handled files
with an extension of .xap (xml application page) anywhere in a URI path. The
'extra path info' that many web server environments provides became
unavailable after a certain version of the servlet specification (it was
working earlier). You can find the code at http://xml.apache.org/xang/ (the
dispatching framework in that project geared writing servlets in a 'resource
modeling' fashion, it also did some rpc-ish stuff but after actually
building stuff with it, I moved away from custom verbs into a minimal common
set - hence my interest in rest)


> And for ASP, AFAIK you'd have to implement an ISAPI filter to do this,
which is
> not trivial and is beyond the skill set of the typical web developer.
Nah, implementing ASP is easy, its a file format after all.
 - parse text into script sections
 - load up JavaScript engine (Rhino is really good, FESI is okay too)
 - provide java objects that implement MS's Request and Response interfaces
 - provide some global functions/classes like ActiveXObject("classId")
 - ignore the existing body of COM objects and just use Java class
identifiers instead.

But it doesn't matter because ASP/JSP is just wrong anyways (mixing
user-agent specific ui with data access as code).








-----------------------------------------------------------------------------------
Post ID:1025
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-15 16:49:48
Subject:What Is The Web?
Message:

REST purports to be an architectural style that embodies the principled
design of the Web.  That sort of statement generates lots of questions,
the first being "what is the Web?"  If REST is an architectural style
that rests on certain principles, what are those principles, what
motivates them, how do they relate, what tradeoffs have been made or
considered?  Asking such questions may yield many useful insights and
answers;  unf., merely studying The RFCs and The Thesis and The Paper
and The Apocrypha often don't yield good answers.

All the following describe different sets with different relationships
to each other.  By studying the relationships between these and other
similar sets, it may be possible to produce a stratified scheme for
assessing and categorizing the various principles that guide Web
architecture and consequently achieve a reasonable separation of
concerns with respect to architectural concepts and components.

Is the Web:

(U) ...all things that have URI?
(B) ...all things that a browser can get, given a URI?
(H) ...all things that a browser can get, given an HTTP URI?
(G) ...the transitive closure of all URI-addressible hypergraphs (i.e.,
linked to or from)?
(J) ...the transitive closure of all HTTP URI-addressible hypergraphs?
(L) ...all things that are linked from some piece of hypermedia?
(M) ...all things in markup-with-links, regardless of having
dereferenceable URI?

Opinions and drill-down appreciated.

jb










-----------------------------------------------------------------------------------
Post ID:1026
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-15 17:12:22
Subject:Re: [rest-discuss] What Is The Web?
Message:

> (U) ...all things that have URI?

I'd say this one, but I'd add;

 ... and whose access and manipulation can be achieved via a
     REST interface (including through an intermediary)

It's a tautology really, as all things with URIs *can* be accessed and
manipulated in this way.  But it highlights the role of REST.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1027
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-15 17:32:05
Subject:Re: [rest-discuss] What Is The Web?
Message:


Mark Baker wrote:

> > (U) ...all things that have URI?
>
> I'd say this one, but I'd add;
>
>  ... and whose access and manipulation can be achieved via a
>      REST interface (including through an intermediary)
>
> It's a tautology really, as all things with URIs *can* be accessed and
> manipulated in this way.  But it highlights the role of REST.

I like this.  But...

What is a "REST interface?"  Does that mean:

* any form of representational state transfer, i.e., ftp:// is encompassed?
* an HTTP interface?
* an HTTP + any hypermedia interface(s) for representations?
* an HTTP + some specific hypermedia interface(s) for representations?

jb








-----------------------------------------------------------------------------------
Post ID:1028
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-03-15 20:31:33
Subject:Re: [rest-discuss] What Is The Web?
Message:

> What is a "REST interface?"  Does that mean:
> 
> * any form of representational state transfer, i.e., ftp:// is encompassed?
> * an HTTP interface?
> * an HTTP + any hypermedia interface(s) for representations?
> * an HTTP + some specific hypermedia interface(s) for representations?

It means any interface for which the semantics are generic to all
things with identity.

So ftp: is encompassed, because I can map GET and PUT to FTP RETR and
STOR.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1029
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-03-15 20:27:57
Subject:Re: [rest-discuss] What Is The Web?
Message:

Good answer! :-)

jb

Mark Baker wrote:

> > What is a "REST interface?"  Does that mean:
> >
> > * any form of representational state transfer, i.e., ftp:// is encompassed?
> > * an HTTP interface?
> > * an HTTP + any hypermedia interface(s) for representations?
> > * an HTTP + some specific hypermedia interface(s) for representations?
>
> It means any interface for which the semantics are generic to all
> things with identity.
>
> So ftp: is encompassed, because I can map GET and PUT to FTP RETR and
> STOR.
>
> MB
> --
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@...
> http://www.markbaker.ca   http://www.planetfred.com
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:1030
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-03-21 23:25:39
Subject:FYI: Clarifying the fundamentals of HTTP
Message:

Jeff Mogul has a paper that's been accepted to WWW2002 which may be of 
interest; it calls out problems in the HTTP's terminology and 
specification (mostly regarding clarity) that give a nice counterpoint 
to REST.

http://www.research.compaq.com/wrl/people/mogul/www2002/mogulwww2002preprint.
pdf

This may also be useful in the context of the current discussions on the 
TAG.

--
Mark Nottingham
http://www.mnot.net/







-----------------------------------------------------------------------------------
Post ID:1031
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-04 18:42:37
Subject:Restifying Available to Promise
Message:

Assuming this group is still alive (I know everybody's been busy 
evangelizing in W3C lists), I have a followup question on the 
purchase order scenarios.

There is a standard function in an ERP system called Available to 
Promise, or ATP for short. 

"Available" means "not already promised to somebody".

It is used to decide if a purchase order can be fulfilled or not.
It is usually used for purchase orders for products, so that is what 
I will describe here.

There are a variety of APIs and algorithms, but they boil down to two 
main queries, which I will describe in plain English, not code:

1.  How much of a product is available to promise at a future time? 
For example, how many blue shoes can I get by tomorrow?
The answer is a quantity.

2. Is a specified quantity of a product at a specified time?
For example, can I get 100 blue shoes tomorrow?
The answer is a boolean.

This query might be offered to a customer to use before they place an 
order, or it might be used by the order-taking Web resource before 
accepting an order.

In REST terms, I assume this is a GET with parameters, and the Web 
resource to address is the Product (i.e. BlueShoe).

How would you say it?

Thanks,
Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1032
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-04 22:40:14
Subject:Re: [rest-discuss] Restifying Available to Promise
Message:

Interesting.

The URI (path+query) would point to the answer you want to give, having the
'path only' point to the product is neato, but not required.

To get the availability:
http://www.myinventory.foo/products/blueshoes/availability/?when=tomorrow

To get the threshold (more than 100)
http://www.myinventory.foo/products/blueshoes/availability/?when=tomorrow&ab
ove=100

But of course there are a million ways to slice it.
You can narrow down the choices based on whether PUT/DELETE/POST are needed
on the same resource - and they probably aren't. POST might be used to
allocate out of the availability - but a business document probably will
have that information & so you'd just submit it to the 'orders' collection &
let the values be updated via business logic (meaning that the values from
these two sample queries are 'synthetic' properties, derived from data
manipulated via other actions)


----- Original Message -----
From: "bhaugen32" <bhaugen32@...>
To: <rest-discuss@yahoogroups.com>
Sent: Thursday, April 04, 2002 10:42 AM
Subject: [rest-discuss] Restifying Available to Promise


> Assuming this group is still alive (I know everybody's been busy
> evangelizing in W3C lists), I have a followup question on the
> purchase order scenarios.
>
> There is a standard function in an ERP system called Available to
> Promise, or ATP for short.
>
> "Available" means "not already promised to somebody".
>
> It is used to decide if a purchase order can be fulfilled or not.
> It is usually used for purchase orders for products, so that is what
> I will describe here.
>
> There are a variety of APIs and algorithms, but they boil down to two
> main queries, which I will describe in plain English, not code:
>
> 1.  How much of a product is available to promise at a future time?
> For example, how many blue shoes can I get by tomorrow?
> The answer is a quantity.
>
> 2. Is a specified quantity of a product at a specified time?
> For example, can I get 100 blue shoes tomorrow?
> The answer is a boolean.
>
> This query might be offered to a customer to use before they place an
> order, or it might be used by the order-taking Web resource before
> accepting an order.
>
> In REST terms, I assume this is a GET with parameters, and the Web
> resource to address is the Product (i.e. BlueShoe).
>
> How would you say it?
>
> Thanks,
> Bob Haugen
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:1033
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-04 22:46:46
Subject:Re: Restifying Available to Promise
Message:

"S. Mike Dierken" wrote:
> 
> Interesting.
> 
> The URI (path+query) would point to the answer you want to give, 
having the
> 'path only' point to the product is neato, but not required.
> 
> To get the availability:
> http://www.myinventory.foo/products/blueshoes/availability/?
when=tomorrow
> 
> To get the threshold (more than 100)
> http://www.myinventory.foo/products/blueshoes/availability/?
when=tomorrow&ab
> ove=100

I like it!
Maybe just plain
http://www.myinventory.foo/products/blueshoes/availability
would present something like an MRP inquiry, starting with the blue 
shoes on hand, followed by a list of scheduled receipts.

(That's the way an ATP report often looks.)

> But of course there are a million ways to slice it.
> You can narrow down the choices based on whether PUT/DELETE/POST 
are needed
> on the same resource - and they probably aren't. POST might be used 
to
> allocate out of the availability - but a business document probably 
will
> have that information & so you'd just submit it to the 'orders' 
collection &
> let the values be updated via business logic (meaning that the 
values from
> these two sample queries are 'synthetic' properties, derived from 
data
> manipulated via other actions)

I agree.  Allocation requires a business commitment from a customer, 
usually in the form of an order.

Thanks, Mike.

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:1034
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-05 06:16:45
Subject:MVC and The Web
Message:

I had a good friend ask me about whether Model-View-Controller is a good
framework for building apps on a Java App Server.
This led me to thinking about how different people view the job of building
'web applications'.
I've always thought of MVC as useful way of building
single-user/single-machine apps - classical programming.
But I also see the separation of data, presentation and logic being very
important and used in multi-tier large-scale systems - the two are very
related.

The interesting part is that I think different audiences view 'the web' as
one of these three facets of a large system;
 - REST advocates view the Web as an information system - the 'model' part
 - majority of web app developers and web app tools (asp/jsp/etc.) view it
as user interface - the 'view' part
 - many soap developers view it as functional services - the 'controller'
part (sort of, i'm probably stretching the analogy here)

I think it is wonderful that the Web is rich enough to be viewed in these
different ways, but I see it as a wholistic blending of all these. Knowing
where other people are coming from can help in understanding each other and
in communicating with and educating each other.

In my view, the current crop of Web application development tools is overly
focused on user interface aspects.
When I see development tools and servers project 'MVC' as a good way to
build applications, it seems like they are looking from the server inward
and applying MVC, where I see the value in looking at the server outward and
applying MVC concepts. Design a system to separate data, presentation and
logic /outside/ the web server. This lets you build applications that span a
single server - whether clustered or not.

Another thought I had was to daydream about what a real REST oriented Web
server development environment would look like. I'm imagining a blend of a
RDBMS interface with HTTP/REST concepts - rather than saying "create table
users (userid int, email varchar(255))" we could say "create collection
users (userid uri)" or something. And we could easily build user interface
without putting the UI template in the URI. "when user-agent like mozilla%"
or "when accept like text/%" or something.

Mike








-----------------------------------------------------------------------------------
Post ID:1035
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-05 12:32:15
Subject:Re: MVC and The Web
Message:

"S. Mike Dierken" wrote:
> I had a good friend ask me about whether Model-View-Controller is a 
good
> framework for building apps on a Java App Server.
>  - REST advocates view the Web as an information system - 
the 'model' part
>  - majority of web app developers and web app tools (asp/jsp/etc.) 
view it
> as user interface - the 'view' part
>  - many soap developers view it as functional services - 
the 'controller'
> part (sort of, i'm probably stretching the analogy here)

Alternatively, in REST:
'model' = resource
'view' = representation
'controller' = handler of GET, POST, PUT, DELETE, etc.

(I'm less sure of the controller.)

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1036
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-04-07 05:09:50
Subject:Re: [rest-discuss] Re: MVC and The Web
Message:


bhaugen32 wrote:

> Alternatively, in REST:
> 'model' = resource
> 'view' = representation
> 'controller' = handler of GET, POST, PUT, DELETE, etc.

Right on the money, IMHO.

jb








-----------------------------------------------------------------------------------
Post ID:1037
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-15 16:28:30
Subject:Session state
Message:

I suppose everybody is tired of Yahoo groups
by now, but the REST gang doesn't seem to want
discussion on the Wiki, so I don't know where
else to post this question-for-discussion.

How much of the current kludges for session
state management could be avoided by making
session state(s) into Web resources?

Paul Prescod has hinted at this a couple of
times.  

Here's an example of people struggling with
the issues without considering REST:
http://c2.com/cgi/wiki?DoesAnyoneActuallyUseStatefulSessionBean 

Thanks,
Bob Haugen








-----------------------------------------------------------------------------------
Post ID:1038
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-04-15 19:33:49
Subject:Re: [rest-discuss] Session state
Message:

> How much of the current kludges for session
> state management could be avoided by making
> session state(s) into Web resources?

> Thanks,
> Bob Haugen

I think there's a project to be done of working out a RESTy session
management protocol.  ...just have to sit down and do it, that's all.

- Lucas








-----------------------------------------------------------------------------------
Post ID:1039
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-15 19:48:13
Subject:Re: [PMX:#] [rest-discuss] Session state
Message:

bhaugen32 wrote:
> 
>...
> 
> How much of the current kludges for session
> state management could be avoided by making
> session state(s) into Web resources?

I tend not to think about session state as a thing. A client interacts
with a service and in so doing the service may create new resources.
They may be short or long-lived. Is there, in general, a requirement to
reify this as a "session"? Opinions requested.

One reason that I resist this is because I would like for it to be
possible to construct a single logical client from many different "HTTP
clients". i.e. for me to dispatch part of the job to a totally different
software component merely by sending it a URI. "Tax form verification
code service, please check my tax form before I send it. It is at
http:///". This gets much more complicated if the client and server have
a shared, implicit notion of where we are in the multi-step process.

One way it would help deal with the issues discussed on that c2.com wiki
is by spreading out the state among multiple resources so that you might
not need to load balance any particular resource. As the "state" is
spread among different URIs, each new step in the process can switch
machines if necessary. Still, the steps will often need to share
information so you still need to push this back to the database and that
will still be somewhat expensive.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1040
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-15 21:24:29
Subject:Re: [PMX:#] [rest-discuss] Session state
Message:

Paul Prescod wrote:
> bhaugen32 wrote:
> > 
> >...
> > 
> > How much of the current kludges for session
> > state management could be avoided by making
> > session state(s) into Web resources?
> 
> I tend not to think about session state as a thing. A client 
interacts
> with a service and in so doing the service may create new resources.
> They may be short or long-lived. Is there, in general, a 
requirement to
> reify this as a "session"? Opinions requested.

No.  I wish I had not framed the question that way.
In fact, the reason I asked it was because you hinted in some 
previous messages that the resources created by interactions would 
eliminate the need to reify and keep track of "sessions".

To the extent that the idea holds up, it could also eliminate all 
kinds of crufty buggy baggage.

> One reason that I resist this is because I would like for it to be
> possible to construct a single logical client from many 
different "HTTP
> clients". i.e. for me to dispatch part of the job to a totally 
different
> software component merely by sending it a URI. "Tax form 
verification
> code service, please check my tax form before I send it. It is at
> http:///". This gets much more complicated if the client and server 
have
> a shared, implicit notion of where we are in the multi-step process.

Unfortunately, business exchanges require trading partners to agree 
on states, but they could be states of resources, not processes.
(Or to put it another way, the states of a business process can be 
modeled as states of resources.)  For example, trading partners need 
to know if an order has been accepted, rejected, fulfilled, etc. but 
those are states of the order, and both the order and its state(s) 
could be Web resources.

-Bob Haugen

P.S. Paul, I could search for the hints in previous messages if you 
want me to, but maybe you remember them?  I didn't bookmark any of 
them, unfortunately - a lightbulb went on when I was reading the Wiki 
page and thinking you had the seed of a better way.







-----------------------------------------------------------------------------------
Post ID:1041
Sender:"eterps73" <erik@...>
Post Date/Time:2002-04-16 09:59:10
Subject:REST by example?
Message:

Hi,

I would like to see a document where you can learn REST by example.
For one reason, to understand it better and also because there is
growing interest in the Ruby community to consider using a REST
architecture as an alternative to a SOAP based approach. This document
would start with very simple examples and gradually evolve into more
complex situations (along with explanations why thing should be done
that way).
What would be good examples to start with? I was thinking about things
like 'hello world', a calculator, an addressbook, a simple chat program.
Is the REST wiki a good place to start such a document, or should I
put it on the Ruby wiki? (the document could have different versions
for other programming languages as well).
Any suggestions would be most welcome.

  Erik Terpstra.







-----------------------------------------------------------------------------------
Post ID:1042
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-16 15:48:10
Subject:Re: Session state
Message:

Lucas Gonze wrote:
> I think there's a project to be done of working out a RESTy session
> management protocol.  ...just have to sit down and do it, that's 
all.

What would be the simplest or most generally congenial environment 
where a group could collaborate in some REST experiments? 








-----------------------------------------------------------------------------------
Post ID:1043
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-17 02:34:53
Subject:Re: [rest-discuss] REST by example?
Message:

> What would be good examples to start with? I was thinking about things
> like 'hello world', a calculator, an addressbook, a simple chat program.
The calculator might be a bad sample problem, because it doesn't show the
utility of REST - transferring the state of a calculator is unnecessary
because the state can be completely algorithmically regenerated on the
client. A 'shared calculator' might be interesting though.
The addressbook is a really good example - there is a wide range of
approaches, from simple ones to get the general feel and style of REST, and
some more complex ones that get into the tougher areas of collections,
nesting, multi-protocol linking, security, etc.
The chat might be better cast as discussion groups, since 'hot live chat'
isn't that common with pure HTTP (unless you use KnowNow technology.)

Another thing to think about is to avoid the 'browser == web' mentality that
throws people off the http trail. Toss XML around (without worring about
using 'industry standard schemas') and do some linking between things
(possibly between apps...).


> Is the REST wiki a good place to start such a document, or should I
> put it on the Ruby wiki? (the document could have different versions
> for other programming languages as well).
> Any suggestions would be most welcome.
>
>   Erik Terpstra.
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:1044
Sender:"eterps73" <erik@...>
Post Date/Time:2002-04-16 11:43:22
Subject:REST by example?
Message:

Hi,

I would like to see a document where you can learn REST by example.
For one reason, to understand it better and also because there is
growing interest in the Ruby community to consider using a REST
architecture as an alternative to a SOAP based approach. This document
would start with very simple examples and gradually evolve into more
complex situations (along with explanations why thing should be done
that way).
What would be good examples to start with? I was thinking about things
like 'hello world', a calculator, an addressbook, a simple chat program.
Is the REST wiki a good place to start such a document, or should I
put it on the Ruby wiki? (the document could have different versions
for other programming languages as well).
Any suggestions would be most welcome.

  Erik Terpstra.







-----------------------------------------------------------------------------------
Post ID:1045
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-04-17 11:16:26
Subject:Re: [rest-discuss] Re: Session state
Message:

Don't know, and I think this list is for more general things, but I'd be
happy to participate wherever the work ends up happening.  A year ago I
would have said Yahoogroups.  ...suppose the thing to do is set up a mail
list anywhere convenient.

- Lucas

On Tue, 16 Apr 2002, bhaugen32 wrote:

> Lucas Gonze wrote:
> > I think there's a project to be done of working out a RESTy session
> > management protocol.  ...just have to sit down and do it, that's
> all.
>
> What would be the simplest or most generally congenial environment
> where a group could collaborate in some REST experiments?







-----------------------------------------------------------------------------------
Post ID:1046
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-04-17 11:28:17
Subject:Re: [rest-discuss] REST by example?
Message:

Hi Erik,

There is already a page on the Wiki ("How to convert RPC to REST") for
what you are thinking about.  The fact that you didn't find it means that
there's a UI problem.  I have edited the text of the front page to
indicate that the "how to convert..." page includes examples.

Changed title
== Comparing REST to Other Things ==
to
== Comparing REST to Other Things: REST by Example ==

More examples on the HowToConvertRpcToRest page would be a good thing.

- Lucas







-----------------------------------------------------------------------------------
Post ID:1047
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-17 11:33:32
Subject:Re: Session state
Message:

Lucas Gonze wrote:
> Don't know, and I think this list is for more general things, but 
I'd be
> happy to participate wherever the work ends up happening.  A year 
ago I
> would have said Yahoogroups.  ...suppose the thing to do is set up 
a mail
> list anywhere convenient.

A Wiki works for me for conversation and documentation.  If the REST 
Wiki admins don't want it, maybe set up another somewhere.

But I was also thinking about development environment, language, 
server, etc. so components might work together more easily.  I know 
REST doesn't care, but some of the head-scratching about REST that I 
go through includes what happens behind the representation. 

I don't care if it's something I don't know now (e.g. Ruby).
Should just be lightweight and simple and cheap (I think).  







-----------------------------------------------------------------------------------
Post ID:1048
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-04-17 14:19:32
Subject:Re: [rest-discuss] REST by example?
Message:

Erik wrote:
> However, I am not particularly interested in converting any existing
> technology into REST based ones.
>
> I am interested in simple (small) examples that demonstrate the REST
> approach with a 'readable' language like Ruby or Python, using only HTTP
> and URIS (and in more complex examples XML).

During the morning commute I came to more or less the same conclusion.
In general there needs to be a listing of design issues with an example
for each.  The stuff on the REST Wiki right now is too abstract.

Design issue: resources not methods
Example: SQL insert

One way to do a SQL insert over the web is to wrap the SQL in HTTP syntax.
For example,
GET /doInsert?cols=id,val&vals=25,fooVal&table=myTable

A REST way of doing this would
* be strict about not using GET to change server state
* have the back end target be a resource rather than a procedure

New way:
POST /tables/myTable?id=25&val=fooVal

- Lucas








-----------------------------------------------------------------------------------
Post ID:1049
Sender:Erik Terpstra <erik@...>
Post Date/Time:2002-04-17 12:24:38
Subject:Re: [rest-discuss] REST by example?
Message:

Lucas Gonze wrote:
> There is already a page on the Wiki ("How to convert RPC to REST") for
> what you are thinking about.  The fact that you didn't find it means that

Thanks, but the top of that page states:
---
Here we aim to demonstrate by example how to convert existing XML-RPC or 
SOAP/RPC based services into REST based ones that used only HTTP and 
URIs (and optionally XML).
---

However, I am not particularly interested in converting any existing 
technology into REST based ones.

I am interested in simple (small) examples that demonstrate the REST 
approach with a 'readable' language like Ruby or Python, using only HTTP 
and URIS (and in more complex examples XML).

   Erik.







-----------------------------------------------------------------------------------
Post ID:1050
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-04-17 14:58:39
Subject:Things that make you go "Grrrr!"
Message:

http://api.google.com/search/beta2

Grrrr!






-----------------------------------------------------------------------------------
Post ID:1051
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-18 02:20:34
Subject:Re: [rest-discuss] Things that make you go "Grrrr!"
Message:

They used to have an XML interface via POST/GET. But you had to pay to get
in.
Don't know what happened to it.

----- Original Message -----
From: "Mark Baker" <distobj@...>
To: <rest-discuss@yahoogroups.com>
Sent: Wednesday, April 17, 2002 7:58 AM
Subject: [rest-discuss] Things that make you go "Grrrr!"


> http://api.google.com/search/beta2
>
> Grrrr!
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:1052
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-18 02:35:25
Subject:Re: [rest-discuss] REST by example?
Message:

----- Original Message -----
From: "Erik Terpstra" <erik@...>
>
> However, I am not particularly interested in converting any existing
> technology into REST based ones.
>
> I am interested in simple (small) examples that demonstrate the REST
> approach with a 'readable' language like Ruby or Python, using only HTTP
> and URIS (and in more complex examples XML).
>

What kind of code examples do you want - client or server?
How about Java code?

Regarding server based code, I have some Java code from a few years ago that
tried to be HTTP and resource oriented.
It's a still available at http://xml.apache.org/xang/ - there are two
pieces, a Servlet based framework for dispatching requests into 'resource
managers'. There is also a part that let you build the url structure and
method handlers in xml and script, but that might not be what you are
looking for (but xml and script do make for easy visual communication).

I also have some examples of a servlet using that approach to expose LDAP
and NNTP through simple URIs and as XML.
http://www.xmldatasource.com:7779/xds/ldap2xml/db.debian.org/ou=users/

There is also a project to do a 'canonical HTTP API for JMS' on sourceforge
(java & servlet based):
http://sourceforge.net/projects/destiny/

Something I haven't done but would like to is to write an HTTP client
library in Java that is an application API rather than a protocol API -
rather than talking about headers and stuff, talk about resources,
representations, etc.









-----------------------------------------------------------------------------------
Post ID:1053
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-18 07:36:14
Subject:Re: [rest-discuss] Things that make you go "Grrrr!"
Message:

Mark Baker wrote:
> 
> http://api.google.com/search/beta2
> 
> Grrrr!

I am half-way though an xml.com article on this topic. The argument in
favor of HTTP is so overwhelming that i would hope and expect that beta3
will have both interfaces. In fact, the SOAP interface feels like a
light layer of SOAP over a native HTTP interface already!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1054
Sender:Holden Glova <dsafari@...>
Post Date/Time:2002-04-18 07:42:29
Subject:RE: REST by example?
Message:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Lucas,

On Thu, 18 Apr 2002 02:19, Lucas Gonze wrote:
>�Erik wrote:
>�> However, I am not particularly interested in converting any existing
>�> technology into REST based ones.
>�>
>�> I am interested in simple (small) examples that demonstrate the REST
>�> approach with a 'readable' language like Ruby or Python, using only HTTP
>�> and URIS (and in more complex examples XML).

Erik: along side the address book example, what about a bookmark manager? It
could manage bookmarks in one central place.

>�During the morning commute I came to more or less the same conclusion.
>�In general there needs to be a listing of design issues with an example
>�for each. �The stuff on the REST Wiki right now is too abstract.

As a very new comer to REST I am still having a hard time thinking about how
it works with a real application from an implementation point of view.

>�Design issue: resources not methods
>�Example: SQL insert
>
>�One way to do a SQL insert over the web is to wrap the SQL in HTTP syntax.
>�For example,
>�GET /doInsert?cols=id,val&vals=25,fooVal&table=myTable
>
>�A REST way of doing this would
>�* be strict about not using GET to change server state
>�* have the back end target be a resource rather than a procedure
>
>�New way:
>�POST /tables/myTable?id=25&val=fooVal
>
>�- Lucas

Surely this would be very bad as anyone could insert whatever data they
wanted into your database. Database access/manipulation IMHO is something
that should definately live behind a facade. I would generally prefer to not
even expose dataaccess routines to the outside world but wrap those up in
something that communicates what the data is doing. Without doing a REST
example, because I don't understand it yet.

I would do something like employee.create, or update etc...This is commonly
termed as the CRUD approach. In REST would this be something like the
following?

http://somehost.com/employee/create?id=12345
http://somehost.com/employee/update?id=12345

Then on the server side there would be a create, update method on the
employee that takes an id parameter?

- -- 
Signed,
Holden Glova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8vnjn+mF116Lw2cQRAoddAJ9HIDZXui5D0I6yumnsY5kUVVE9QQCZAXdM
j3S51ro8ojOn+3kG4PMZqBE=
=uvr+
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:1055
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-18 09:29:02
Subject:Comments Welcome
Message:

Please do not forward this too widely yet. I intend to publish it on
xml.com. In particular, please don't forward links to it yet. It's
canonical home should be xml.com. Still needs proof reading and comments
are welcome, as always.

=====

                        Google's Gaffe
                               
Google's release of an Application Programming Interface has
been heralded as a bright moment for web services. It is true
that it is an exciting development, but at the same time there
is a subset of the programmer community that is disappointed.
Google had a similar XML-based API a year ago, but did not
document it or hype it. Merely by adding the URL fragment
"/xml" to your query, you could get back an XML representation
of a query, for processing by any XML-aware programming
language or tool. It became a pay-only service last fall. We
were disappointed but understood why that would happen -
lacking in advertisements, the service was a straight money
loser.

Imagine our surprise when we heard the big announcement
recently. Google had revived the service, added new features,
documented it and promoted it, but had moved it to a an
inferior technical platform: SOAP. Over dozens of mailing
lists, weblogs and discussion groups the reaction was mixed:
"An official Google API! But why use SOAP?" It feels like one
step forward and two backwards.

This article will demonstrate that the choice to use SOAP was
a poor one. The much simpler HTTP URI technique was easier to
use and more powerful at the same time. I will recast the new
Google API back into a URI and HTTP-based API and demonstrate
the virtues of the simpler HTTP strategy.

                     Why Google Is Special
                               
In the past, I have demonstrated how SOAP-based services can
be re-engineered around pure HTTP. These services can be
arbitrarily complex, transactional, read-write and secure.
There are thousands of web services out there and I do not
have time to re-invent each and every one of them as
HTTP-based service. But the new Google API is special for a
variety of reasons.
 * Google has had an XML and HTTP based API in the past.
   Their choice to use SOAP would seem to indicate a need to
   move beyond HTTP. My experiment demonstrates that this is
   not so.
 * Google's service seems almost unique in how simply and
   clearly one can establish an HTTP interface. In essence,
   it feels like a thin SOAP wrapper over a simple HTTP
   service. Making an HTTP interface for Google is a
   "no-brainer".
 * Google the corporation has always been known for its
   technological acumen and general cluefulness. I think that
   they can be convinced to do the right thing and restore
   the HTTP interface (perhaps alongside the buzzword
   compliant SOAP interface).
   
In addition, I think that the Google move is important
symbolically. I take the SOAP-ifying of Google as a sign that
the web services hype has now reached overdrive. I now
regularly hear from customers that they have working XML
systems but: "we know we'll have to move to SOAP soon." This
is simply not true.

SOAP is an unproven technology with a questionable design.
Worse, when it is misused (as in the Google API) it has a
detrimental effect on the growth of the Web. As I will
demonstrate, at the heart of the Web is the concept of URIs.
The Google API substitutes a proprietary addressing mechanism
for URIs and thus hides information from Web-based software
such as XSLT engines and XInclude implementations.

                       Google's SOAP API
                               
Let's take a look first at Google's SOAP API. This is our
starting point. Here is a complete message from client to
server using their API:

I set maxResults to 0 so that I won't actually get any
results. Google returns a ton of XML metadata about the query
itself so working with query "hits" would make my examples too
long.

The message starts with HTTP headers because the Google API
runs SOAP over HTTP. The only SOAP-specific header is the
SOAPAction header which is theoretically useful for filtering
SOAP traffic. Practically speaking it is optional and thus not
a good basis for filtering.

The XML part of the message starts with some namespace
declarations, and a SOAP encodingStyle declaration (more or
less boilerplate). After that comes a set of ordered
parameters. The parameters to the operation consist of an
ordered list of values. The allowed values for the
doGoogleSearch command is are "key" (userid/password), "q"
(query text), "start" (where in the results to start
returning), "maxResult" (number of allowed results), "filter"
(filtering out very similar results), "restrict" (country or
topic restrictions), "safeSearch" (pornography filter), "lr"
(language restrict), "ie" (input encoding) and "oe" (output
encoding) properties.

The "key" property is special. It is more or less a password
assigned to a particular software developer. The Google API
seems not to support SSL so these always pass across the wire
in cleartext.

As you can see, parameters are strongly typed. The client and
server know the types in advance but for some reason, most
SOAP toolkits will inline the types into the messages. As you
will see, this is entirely unnecessary.

Here is the message Google returns:

Note that the resultElements element is empty. I warned you
that we would have quite a bit of XML to work with even
without looking at any hits!

There are two more methods. doSpellingSuggestion requests a
spelling correction suggestion. For instance it would suggest
that "britney speers" be corrected to "britney spears". It
takes only a key and string as parameters, and returns only a
string for the suggestion.

doGetCachedPage requests a cached page from Google. It takes a
key and a URI as parameters and returns Base64-encoded data
for the cached page.

                        HTTP Equivalent
                               
To reinvent this as an HTTP-based web service, I merely have
to translate the properties into "query parameters" in a URI.
A couple of hundred lines of Python serve to implement the
mapping from these query parameters into Google SOAP.

Here is the sort of URI used to address into my version of the
service:
http://localhost/scripts/search.py?key=0000&q=constantrevolution+rules+
xml&maxResults=10

That's pretty ugly, but consider that nobody (even a
programmer) ever needs to look at this URI. It can be
generated, just as the SOAP message is. For instance here is a
complete Python program to fetch the information from that
URI:
import urllib

params = {"key":"0000",
      "q":"constantrevolution rules xml",
      "maxResults":"0",
        }
urllib.urlopen("http://localhost/scripts/search.py?" +
    urllib.urlencode(params))

HTTP deals with optional arguments much more gracefully than
do most WSDL-based SOAP toolkits, so I've left out any of the
arguments that can be inferred or omitted.

Let's zoom in on the special key parameter. HTTP has a
built-in authentication mechanism so really that would be a
better way to handle it. Recent implementations of HTTP have a
challenge/response [1]authentication scheme which is more
secure than simply passing a key in cleartext. Of course for
ultimate security (at a price in performance), I would
recommend you SSL encrypt the entire message. SOAP does not
itself support authentication yet, and authentication is (as
of this writing) still an [2]open issuefor SOAP's
RPC-over-HTTP binding. I will leave key as a parameter for
simplicity and to more closely parallel the SOAP version.

Here is the message that gets sent on the wire:
GET /scripts/search.py?maxResults=0&key=XXX&q=constantrevolution+rules+
xml HTTP/1.0
Host: localhost
User-agent: Python-urllib

That's all!

Now some might complain that the query parameters are all
"just strings" whereas the SOAP parameters were strongly
typed. This is not necessarily true. On the wire, of course
the parameter are just strings, just as SOAP messages are just
strings. Only at the client and the server are the strings
interpreted as other types. The client must know the types of
the parameters in order to have made the call. The server must
know the types of the parameters in order to have implemented
the service. Given both parties already know the types, it is
a waste of bandwidth to declare the types of the parameters in
each and every message. Even SOAP does not require this. It is
merely a common SOAP idiom.

This leaves the question of how that is communicated. Later I
will show a way to declare the types strongly and statically
enough to satisfy the most ardent Java or C# masochist.

HTTP allows any media type in the response to a message. It
could return any XML vocabulary whatsoever. Insofar as the
Google SOAP API already embeds a simple schema, it makes sense
to use that. I merely have to remove a few SOAP-isms (the
arrayType attribute, the SOAP-env element, etc.) and choose a
new root element type (I chose searchResult). I hereby
christen the purified language GoogleML. I've written an XSLT
stylesheet that I call "pureGoogle.xsl" which translates
GoogleSOAP into GoogleML. The resulting documents are much
smaller, simpler and easier to read.

Here is the stylesheet (minus a few namespace declarations):

And here's a GoogleML equivalent to the response from before:

HTTP provides the envelope so there would be no need for a
redundant, second SOAP envelope. The types are known in
advance so they are stripped (although I could just as easily
have left them in). GoogleML documents are not constrained to
the features of XML supported by SOAP. GoogleML documents can
use a DOCTYPE and DTD, and could use processing instructions.

The most dramatic improvement comes in the getCachedPage
request. HTTP can efficiently handle non-XML data. HTTP
delivers terabytes of binary data every day. Conversely, SOAP
requires non-XML data to be Base-64 encoded (unless the use of
the non-standards-track SOAP With Attachments specification).
Base64 data is always more verbose than unencoded binary data
so the HTTP/URI/GoogleML version of the service will always
save bandwidth and CPU power.

Compare the SOAP doGetCachedPage request:

Now compare that to an HTTP-style cachedPage request:
    
    

Compare the SOAP response (embedding base64-encoded data):

to the HTTP-style response:

Because HTTP has no problem directly embedding HTML
(well-formed or not!), there is no reason to base64-encode the
data.

Finally compare the old-style SOAP doSpellingSuggestion
response:

To the HTTP version:

I could have used XML for the response, but why? It is
overkill for this job.

                        Declaring Types
                               
Unfortunately many believe that the difference between
HTTP-based services and RPC-based services is that the former
are loosely or dynamically typed and the latter are strongly
or statically typed. This is not really true. The choice
between HTTP and SOAP is a choice between protocols. The
decision to statically type-check information passing across
the wire is more concerned with service description. The two
issues are totally separate.

I've already demonstrated how one can strongly type-declare
the responses to HTTP-based services using XML Schema. If you
want to type-declare the query parameters then you can use a
language designed for type-declaring HTTP-based services like
my Web Resource Description Language (WRDL).

WRDL is still under development but in fact you can already
solve this problem today using the more popular "industry
standard" language WSDL. WSDL has some basic HTTP-declaration
features. Although WSDL is most often used with SOAP, it can
in fact type-declare the parameters for simple HTTP services.
Here is the relevant bit of a WSDL for my HTTP version of the
doGetCachedPage method:

It turns out that WSDL's handling for the <http:urlEncoded/>
works almost perfectly. It gets the parameter names from the
operation's part names. If you know WSDL then that will
probably be clear to you. If not, don't worry about it. The
input description for the other two methods is identical, so
we will concentrate on the output element.

The output for the doSpellingSuggestion has a media-type of
"text/plain":

Finally, the output for doGoogleSearch

This refers to a part named searchResult which is based upon
an element type of the same name.

Now I do not want to oversell WSDL's HTTP features. You cannot
define sophisticated HTTP-based web services with WSDL. WSDL
falls down as soon as a web resource generates links to
another web resource. WSDL cannot express the data type of the
target resource. In other words it can describe only one
resource and not the links between Web resources. SOAP lacks a
first-class concept "of resource" and especially lacks a
syntax for linking them. It is thus not surprising that WSDL
inherits this flaw. Nevertheless, I hope that this weakness
will be corrected in future versions of WSDL. In the meantime,
this is the primary reason for the existence of the WRDL
language.

For instance, imagine if the search API returned a URI to the
cached page, just as it does in the HTML version of Google.
You could declared in WRDL (as opposed to WSDL) that the
cachedPage element of searchResult resources points to a
document of type text/html. I could also define a resource
type for Google "directory catalogs", then I have strong types
for the links from search results to the directory catalogs
and back. WRDL is designed (okay, being designed) to mirror
the structure of the Web, rather than impose a
component-oriented view on top of it.

Still and all, you do not have to wait for WRDL. WSDL is
sufficient for Google's current API because the API does not
make use of hyperlinks. This is a common failing of SOAP-based
APIs which follows from the component-centric thinking that
pervades the SOAP community.

                  Advantages of the HTTP API
                               
Let's consider the benefits of the HTTP version. First, I have
already discussed how HTTP has standardized ways of doing
authentication and of handling non-XML (including non-textual)
data.

The message size is a tiny fraction of the original. More
important, it is much, much easier for a typical system
security administrator to read. It is also vastly easier to
filter, log and monitor. The CPU load is also likely to be
significantly smaller. I don't even want to know how many
cycles are being wasted around the world building those silly
Google SOAP messages (sometimes base64'ing data!) and then
parsing them down again on the other side. Remember that each
and every message is also an HTTP message and must be built
and parsed as such. Californian readers should remind Google
that electricity is precious. They could switch to HTTP and
turn off a couple of wasted server clusters.

I have no need to install a SOAP implementation like .NET's or
Apache's. You can use any HTTP implementation, including
Internet Explorer, Netscape, Mozilla, Lynx, Opera, wget,
"java.net.URL", Python's httplib.HTTPConnection, Perl's LWP,
etc. In fact, you could easily test the API through a plain
old HTML form!

The HTTP version is highly amenable to caching. You can set up
a standard HTTP cache on your local network, or use one at
your ISP. Google could also do server-side caching using
something as simple as Squid. Of course caching of SOAP is
also possible: if you write the cache implementation yourself.
With HTTP, you can install any one of a variety of free or
commercial caching proxy implementations.

The HTTP version could use the little-known feature of HTTP
known as content negotiation. "Conneg" as it is known to its
fans, allows each URI to map to a resource that can deliver up
various representations of itself. For instance the service
could return the same URI in GoogleML, SOAP, XML-RPC and HTML,
depending on the preferences of the caller.

But all of these advantages are like the tiny diamonds that
ring the Big Rock.

                   The Web's Crowning Glory
                               
The most important advantage is that an HTTP version is part
of the Web rather than merely being behind the web. This point
is subtle but the most central. A piece of information is on
the Web if it has a URI or is embedded in a resource with a
URI. When I expose the Google API through SOAP it is behind
the Web because the object with the web URI is the SOAP
component, not the actual query results. Only the component is
on the Web. But in the HTTP way of thinking about it, every
possible query result has its own URI and thus is a
first-class web data object.

This assigning of URIs is incredibly powerful. First, it means
that in standard hypertext documents it is possible to link to
query results. There are thousands of links around the Web to
Google search result resources. Google's HTML incarnation is
an important part of the web community as a service but it is
also an important part of the web through the thousands of
virtual "resource documents" it hosts like:
[3]http://www.google.com/search?hl=en&q=xml+-soap

Now it is time to move this concept into XML. You may recall
the days when XML was intended to be a way of publishing
structured information on the Web. One of the great virtues
was [4]supposed tobe that result sets could be more compact
and could be manipulated (e.g. sorted and filtered) using
client-side scripting. Somehow I got sidetracked with RPC
models and SOAP, but the core idea of delivering XML to the
desktop is alive and well in [5]Internet Explorer and
[6]Mozilla.

Of course public websites cannot depend upon client-side XML
support being widely deployed yet, but companies like Google
should be laying the groundwork for a future XML-based Web
rather than burying XML for use only in machine to machine
applications. One of the virtues of XML we promoted in the
1997 edition of the XML Handbook was that XML brought the
representation of information for machines and humans
together. We still have not achieved that and will not until
machines and humans use the same access protocol: HTTP.

But URI-addressability is important even for information that
will never be seen by humans. Addressable XML can be composed
into extremely sophisticated "compound-documents" using
technologies like XInclude, XSLT, XLink, RDF and Topic Maps.
For instance, consider a document that uses XInclude to
aggregate query results:

Now consider an XSLT template that does the inclusions:

And then a template in another XSLT transform could collect
the URL and snippet elements in the merged data, sort them by
URL and transform them to HTML:

Next consider an RDF assertion that related the query results
to an individual's home pages:

This is the fundamental power of the Web. The Web's strength
is that it allows us to address, link, compare, relate and
otherwise combine resources. The point that has not yet
filtered through to the mainstream of web services
implementors is that this is just as important for machine to
machine applications as it is for human-facing applications.
To repeat: linking is just as important for machine to machine
applications as it is for human-facing applications. If it is
impossible to link to SOAP-exposed resources then they are
less powerful and useful than HTTP-exposed ones. Let me
rephrase that: until SOAP has an addressing mechanism as rich
as HTTP URIs, SOAP is less, not more, powerful than HTTP.

A less generous person might argue that SOAP services are
called "web services" because they wish to partake of the
Web's success -- yet do not wish to build upon its core
technologies: URIs and HTTP.

                        Service as API
                               
An important issue in all of this is ease-of-use. If it is no
longer simple for programmers to access the information then
the service will fail.

Let's start from the point of view of a programmer with no
special toolkit at all, just a standard programming language
distribution or IDE. Obviously the HTTP solution wins because
SOAP and WSDL support is not yet embedded in most programming
language distributions. It takes five lines of Java to get a
cached page or spelling correct from my version of the
service. You don't need even an XML parser installed. Of
course working through search results will require an XML
parser but it will not require a SOAP engine on top.

On the other hand, what if you already have a SOAP/WSDL
toolkit? Well if the toolkit is complete (good luck!) then it
will support WSDL's HTTP binding. You can use exactly the same
API to access the service as if you were using the SOAP
version. For instance I can generate a statically typed C#
interface from my WSDL description and it is functionally
identical to the SOAP version. Truth in advertising: to get it
actually working I did have to work around a few small bugs in
Microsoft's WSDL toolkit. WSDL implementors: please take
WSDL's HTTP bindings seriously and implement them properly!
Note that there is also a prototype of a WRDL->C# tool which
will do the same for WRDL descriptions.

If you are opposed to external service descriptions, there are
a variety of inline-type annotation techniques you could use.
Examples include the OMG's XMI, Jacobson's MIME-RPC, Winer's
XML-RPC, Allaire's WDDL and even SOAP's "section 5" encoding.
No one of these has become standardized because the common
wisdom in the strongly typed XML world is that it will be much
more common to express the types in some form of external
schema such asXML Schema, RELAX NG, Schematron or DT4DTDs.
HTTP/WRDL works perfectly with all of these and unlike the
SOAP/WSDL combination has no preference for one over the
other.

If you like neither inline typing nor schemas then you have a
third choice: you can use a language-specific databinding
technology such as Castor, JAXB or [7].NET Data Binding.

In other words, parsing XML into language-native data types is
a problem that has been solved over and over again. If you
happen to prefer the SOAP solution then use the SOAP encoding.
SOAP is XML and can be used with various XML technologies. But
remember that you can use the SOAP encoding without buying the
whole SOAP RPC-over-HTTP model. If you use the SOAP encoding
with HTTP-based URIs then you preserve the essential heart of
the Web: the ability to address information.

                     What Would Frodo Do?
                               
Back in the days where XML was called SGML, we enthusiasts
were like Hobbits in the Shire, hearing tales of the distant
wars between Wizards (tools vendors), Dragons (database
vendors) and Armies (MIS departments). But we were relatively
sheltered from them. Those days have long since passed. XML
users have a special understanding of the possibilities of the
marriage of hyperlinks, XML and the Web. We have a
responsibility to go out of the Shire and educate the other
residents of Middle Earth. Google is like the wizard Saruman,
a benign and powerful force inexplicably turned from the path
of virtue. Nevertheless, I am confident that they can be won
back! The white robe awaits on the delivery of the Google API
beta 3.

What we need to do is gather together a fellowship of
like-minded Hobbits, Dwarves, Elves and men and go on a quest
to improve the world in whatever small way we can. You can
join the quest by signing the [8]petition available , and if
you don't mind registering for Yahoo Groups, you can also
participate in the thread discussing this topic. Please
forward this article to mailing lists.

We must help our fellow technologists to use SOAP only after
they have understood its limitations and to understand that
they can make the Web a richer place by putting XML-based data
on the Web rather than behind it Yes, there are Wizards,
Dragons and Armies about, but Hobbits can influence events
also.

References

1. http://www.ietf.org/rfc/rfc2617.txt
2. http://www.w3.org/TR/soap12-part2/#simpleauthfeat
3. http://www.google.com/search?hl=en&q=xml+-soap

5. http://www.xml.com/pub/a/2000/05/03/msie/
6. http://www.mozilla.org/newlayout/xml/
7.
http://msdn.microsoft.com/msdnmag/issues/01/03/cutting/cutting0103.asp?frame=true






-----------------------------------------------------------------------------------
Post ID:1056
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-04-18 11:12:16
Subject:Re: [rest-discuss] RE: REST by example?
Message:

> Surely this would be very bad as anyone could insert whatever data they
> wanted into your database. Database access/manipulation IMHO is something
> that should definately live behind a facade. I would generally prefer to not
> even expose dataaccess routines to the outside world but wrap those up in
> something that communicates what the data is doing. Without doing a REST
> example, because I don't understand it yet.
>
> I would do something like employee.create, or update etc...This is commonly
> termed as the CRUD approach. In REST would this be something like the
> following?
>
> http://somehost.com/employee/create?id=12345
> http://somehost.com/employee/update?id=12345
>
> Then on the server side there would be a create, update method on the
> employee that takes an id parameter?

Hey Holden,

The REST answer to CRUD is that employee.create should not be exposed in a
broadly distributed setting because it is a method as opposed to a
resource.  So http://somehost.com/employee/create?id=12345 should be,
instead,

POST http://somehost.com/new_employees
(get back an ID, and then do...)

POST http://somehost.com/employees/$ID?department=accounting

So you wouldn't expose data access routines to the outside world, but you
would expose data access resources.  Then you just control access to the
data access resources using standard HTTP access control.  The net effect
is precisely to wrap up the SQL in something that controls access, a.k.a.
by exposing a public representatation of a private resource.

- Lucas








-----------------------------------------------------------------------------------
Post ID:1057
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-18 16:35:52
Subject:You lose some, you win some
Message:

http://xmlhack.com/read.php?item=1615

"Amazon goes REST, Google goes SOAP"

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1058
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-18 15:35:07
Subject:IBM patent is REST opportunity
Message:

IBM just dropped a submarine patent on ebXML.
http://zdnet.com.com/2100-1106-884681.html 

Follow this thread a little to see the consequent turmoil in ebXML-
related projects:
http://lists.ebtwg.org/archives/ebtwg/200204/msg00056.html 

I work with ebXML and UN/CEFACT projects that model business 
protocols independently of technical implementation.  I have been 
looking very seriously at REST (as some of you know from previous 
posts) and think that REST could handle all of the required business 
protocols.

While I think the IBM will probably do something to remove the cloud 
over ebXML, the fact remains that everything they said they 
contributed and now claim patents over can be done in other ways, 
that is, REST.

I am not a lawyer, but my guess is that using REST would have a 
pretty good chance of avoiding the patent claims.  People who are 
lawyers are examining the claims as we speak, and I'll post more 
details as they become available (assuming there is interest).

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1059
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-18 21:27:21
Subject:Re: IBM patent is REST opportunity
Message:

Patent number: 6,148,290
http://www.uspto.gov/patft/ 

or (the long URL):
http://patft.uspto.gov/netacgi/nph-Parser?
Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=5
0&s1='6,148,290'.WKU.&OS=PN/6,148,290&RS=PN/6,148,290

Seems to cover almost any kind of agreement on how to do business 
electronically, including those conducted by humans at each end.

Lots of prior art has already come out of the woodwork.

I can't believe this.  Ok, I can.








-----------------------------------------------------------------------------------
Post ID:1060
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-18 21:35:38
Subject:Re: Comments Welcome
Message:

Paul, it's wonderful!
Great argument, lots of convincing detail.

Suggestion for improvement:
If you could put something really short illustrating the difference 
right after this paragraph, the attention-deficit reader (vast 
majority) would not need to wade through so much before getting the 
main point:

"This article will demonstrate that the choice to use SOAP was
a poor one. The much simpler HTTP URI technique was easier to
use and more powerful at the same time. I will recast the new
Google API back into a URI and HTTP-based API and demonstrate
the virtues of the simpler HTTP strategy."

<Put the main contrast here>
Google SOAP:
Google HTTP:










-----------------------------------------------------------------------------------
Post ID:1061
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-19 05:31:17
Subject:Re: [rest-discuss] RE: REST by example?
Message:

----- Original Message -----
From: "Holden Glova" <dsafari@...>

>
> I would do something like employee.create, or update etc...This is
commonly
> termed as the CRUD approach. In REST would this be something like the
> following?
>
> http://somehost.com/employee/create?id=12345
> http://somehost.com/employee/update?id=12345
>
> Then on the server side there would be a create, update method on the
> employee that takes an id parameter?

The URLs should be objects that support the generic methods of get, put,
post, and delete rather than urls with the methods themselves (no matter how
tempting it may be, and I'm just as guilty of ignoring that as anyone.).
The 'post' operations means 'modify' and it could be implemented to
add/subtract/extend/whatever. It can also optionally return the ID of a
newly created resource.

In HTTP there are similar but different operations for CRUD type of
functionality.
Two are easy, GET=Read and DELETE=Delete. With HTTP you have two choices to
create new data, POST and PUT, depending on who knows the desired ID, as
well as how you want to deal with safely repeatable operations
(idempotency).
You use PUT when the client knows the desired ID and POST when the server
will generate the ID. So in your example, you only need to use one HTTP
method (since the client is providing the ID of the new employee)
PUT http://somehost.com/employee/12345/

In a database if you INSERT with a duplicate key, it fails. If you UPDATE a
record that doesn't exist it fails.
With PUT the record is created if it doesn't exist or updated if it does -
an 'upsert'.
With POST a record is created and the key is returned - and wacky things
happen if you call it twice...

CRUD (create, read, update, delete) is a framing of REST over relational
databases (or vice-versa...)
REST has the attitude of 'lots of nouns, few verbs'.
Databases follow this very succesfully. Although we always talk about
GET/PUT/POST/DELETE, those are just one example as applied by the HTTP. It
is useful to compare the two (and others.. I should start a page on the
Wiki...) and consider issues like:
 - are the operations safely repeatable
 - who controls the ID (primary key, etc)
 - can you create an empty resource and fill it in later










-----------------------------------------------------------------------------------
Post ID:1062
Sender:Holden Glova <dsafari@...>
Post Date/Time:2002-04-17 20:21:22
Subject:Re: [rest-discuss] REST by example?
Message:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Lucas,

On Thu, 18 Apr 2002 02:19, Lucas Gonze wrote:
> Erik wrote:
> > However, I am not particularly interested in converting any existing
> > technology into REST based ones.
> >
> > I am interested in simple (small) examples that demonstrate the REST
> > approach with a 'readable' language like Ruby or Python, using only HTTP
> > and URIS (and in more complex examples XML).

Erik: along side the address book example, what about a bookmark manager? It 
could manage bookmarks in one central place.

> During the morning commute I came to more or less the same conclusion.
> In general there needs to be a listing of design issues with an example
> for each.  The stuff on the REST Wiki right now is too abstract.

As a very new comer to REST I am still having a hard time thinking about how 
it works with a real application from an implementation point of view.

> Design issue: resources not methods
> Example: SQL insert
>
> One way to do a SQL insert over the web is to wrap the SQL in HTTP syntax.
> For example,
> GET /doInsert?cols=id,val&vals=25,fooVal&table=myTable
>
> A REST way of doing this would
> * be strict about not using GET to change server state
> * have the back end target be a resource rather than a procedure
>
> New way:
> POST /tables/myTable?id=25&val=fooVal
>
> - Lucas

Surely this would be very bad as anyone could insert whatever data they 
wanted into your database. Database access/manipulation IMHO is something 
that should definately live behind a facade. I would generally prefer to not 
even expose dataaccess routines to the outside world but wrap those up in 
something that communicates what the data is doing. Without doing a REST 
example, because I don't understand it yet.

I would do something like employee.create, or update etc...This is commonly 
termed as the CRUD approach. In REST would this be something like the 
following?

http://somehost.com/employee/create?id=12345
http://somehost.com/employee/update?id=12345

Then on the server side there would be a create, update method on the 
employee that takes an id parameter?

- -- 
Signed,
Holden Glova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8vdlD+mF116Lw2cQRAsc4AJ4nsg8pRCE7YdYpTK8DQs8ve1x9jQCdEJFI
LrLuNyMH2c/Z+MhKwJlI/m0=
=/bI4
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:1063
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-19 11:24:53
Subject:IBM says no royalties on patent
Message:

> While I think the IBM will probably do something to remove the 
cloud 
> over ebXML, the fact remains that everything they said they 
> contributed and now claim patents over can be done in other ways, 
> that is, REST.

IBM statement, prodded by ebXML threats to vote against any 
encumbered feature and probably also general uproar:
(my comments below)

>>From: Robert S Sutor [mailto:sutor@...]
>>Sent: Thursday, April 18, 2002 6:27 PM
>>
>>1. ebXML followed the OASIS intellectual property policy.
>>2. IBM believes we followed the OASIS intellectual property policy
process.
>>3. IBM will NOT charge royalties on either the patent related to 
TPA or
>>the additional one whose application we disclosed.
>>We will not be amending our declaration to you, just qualifying it 
to you
>>as above. * * *
>>IBM is proud of our work in ebXML and proud of our past and current
>>participation in OASIS. OASIS will be an important organization for 
IBM
>>and the industry as we all move to a common infrastructure for
>>successfully conducting business on the Internet.  * * *
>>
>>Robert S. Sutor, Ph.D.
>>   Director, IBM e-business Standards Strategy

I won't comment on Sutor's statement.
The fact remains that these particular patterns were not the only 
ones lurking behind the Web service technologies.  And I'm still 
guessing, but can't prove, that REST would be more free of such 
encumbrances.  (Although IBM's patent was very broad, and I guess 
that's the way the patent lawyers write them.)










-----------------------------------------------------------------------------------
Post ID:1064
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-04-19 12:05:45
Subject:Event notifications in http
Message:

I am just getting to grips with REST and its ramifications and have a question on event notifications. Are there any attempts  being made to standardise event notifications (ala http events, http notifications) at the w3 level or similar and are there any projects implementing these ideas?

TIA

Robert







-----------------------------------------------------------------------------------
Post ID:1065
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-04-19 15:01:32
Subject:Re: [rest-discuss] Event notifications in http
Message:

Per the W3C and standardization, I believe consensus is that it is too
soon.

- Lucas

Robert Leftwich wrote:
> I am just getting to grips with REST and its ramifications and have a
> question on event notifications. Are there any attempts being made to
> standardise event notifications (ala http events, http notifications) at
> the w3 level or similar and are there any projects implementing these
> ideas?







-----------------------------------------------------------------------------------
Post ID:1066
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-04-19 14:13:12
Subject:Re: [rest-discuss] Event notifications in http
Message:

You have wandered into a deep swamp, Robert.  There has been a _lot_ of
discussion about http notifications here -- probably too much.  See Mark
Nottingham's work (sorry, I don't have a URL handy on my work computer),
Paul Prescod et al on the REST Wiki
(http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents), and my own
http://www.gonze.com/http-notifications.html

- Lucas

On Fri, 19 Apr 2002, Robert Leftwich wrote:

> I am just getting to grips with REST and its ramifications and have a
> question on event notifications. Are there any attempts being made to
> standardise event notifications (ala http events, http notifications) at
> the w3 level or similar and are there any projects implementing these
> ideas?
>
> TIA
>
> Robert







-----------------------------------------------------------------------------------
Post ID:1067
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-19 19:54:54
Subject:Capturing HTTP userid in CGI
Message:

I'm trying to make a passthrough app that will restify the Google API. I
want to allow the end-user to choose whether they want to pass the
Google "key" (essentially a username) as a keyword parameter or as an
HTTP user name. I think this would be not too tricky except that I need
to capture the HTTP user name *as* a key and pass that on to Google. The
code is just simple CGI for portability. The problem is that I don't
think that Apache is sending me the username, password or anything else
I can use. In particular I don't get the HTTP_AUTHORIZATION header. Any
ideas?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1068
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-04-19 22:37:42
Subject:Re: [rest-discuss] Event notifications in http
Message:

At 12:13 AM 20/04/2002, Lucas Gonze wrote:

>You have wandered into a deep swamp, Robert.  

I'm hoping that a lot of people have wandered into the same swamp before me and I can stand on the shoulders of some giants :-)

>There has been a _lot_ of
>discussion about http notifications here -- probably too much.  See Mark
>Nottingham's work (sorry, I don't have a URL handy on my work computer),
>Paul Prescod et al on the REST Wiki
>(http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents), and my own
>http://www.gonze.com/http-notifications.html

Yes, I have seen those proposals and am now contemplating how best to move forward.

Robert







-----------------------------------------------------------------------------------
Post ID:1069
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-04-19 22:34:35
Subject:Re: [rest-discuss] Event notifications in http
Message:

At 01:01 AM 20/04/2002, Lucas Gonze wrote:

>Per the W3C and standardization, I believe consensus is that it is too
>soon.

That was my impression, I wanted to make sure I hadn't missed anything.

The question then becomes, if I want to implement a REST-full solution and I require notifications, which path is the best one to take? Do I base my implementation on one of the proposed solutions (all of which have merit - at least to my not yet fully REST-ified mind) or do I not support notifications and rely on a polling solution instead (which in my case is probably borderline acceptable, at least for the initial phase)?

Robert







-----------------------------------------------------------------------------------
Post ID:1070
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-20 04:21:48
Subject:Re: [rest-discuss] Event notifications in http
Message:

Robert Leftwich wrote:
> 
>...
> 
> The question then becomes, if I want to implement a REST-full 
> solution and I require notifications, which path is the best 
> one to take? Do I base my implementation on one of the proposed 
> solutions (all of which have merit - at least to my not yet 
> fully REST-ified mind) or do I not support notifications and rely 
> on a polling solution instead (which in my case is probably 
> borderline acceptable, at least for the initial phase)?

Doing notifications using HTTP is not difficult. At its heart all you
are doing is setting up an HTTP server on both sides. We got bogged down
trying to work out models that would be applicable to all or almost all
possible event notification situations. It is highly likely that doing
notifications for your particular application is relatively simple. If
you discuss your requirements maybe we can help.

I think that the biggest PRACTICAL issue with HTTP notifications is the
same as with every other protocol: firewalls, NAT and other types of
assymettric connectivity at the IP level.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1071
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-20 05:13:57
Subject:Re: [rest-discuss] Event notifications in http
Message:

I don't think there are any W3C projects, there may be some related IETF and
other projects that did events with HTTP.
Search for "GENA General Event Notification Architecture"
http://www.isr.uci.edu/events/twist/wisen98/presentations/Cohen/
and "ISEN Internet Scale Event Notification"
http://www.ics.uci.edu/pub/ietf/notify/

You may also be interested in  "A Survey of Event Systems, by Adam Rifkin
and Rohit Khare" http://www.cs.caltech.edu/~adam/isen/event-systems.html

I started a project on SourceForge to expose JMS via HTTP
http://sourceforge.net/projects/destiny
Its an example of how HTTP can be used for asynchronous things. Its rough
and only in the early stages, but its a place to start for some things.

Mike

----- Original Message -----
From: "Robert Leftwich" <robert@...>
To: <rest-discuss@yahoogroups.com>
Sent: Friday, April 19, 2002 5:05 AM
Subject: [rest-discuss] Event notifications in http


> I am just getting to grips with REST and its ramifications and have a
question on event notifications. Are there any attempts  being made to
standardise event notifications (ala http events, http notifications) at the
w3 level or similar and are there any projects implementing these ideas?
>
> TIA
>
> Robert
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:1072
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-20 05:20:11
Subject:Re: [rest-discuss] Capturing HTTP userid in CGI
Message:

It's possible that Apache doesn't pass the raw headers through to prevent
security holes.
They might extract, validate and passthrough the account name, though in a
CGI environment variable REMOTE_USER.

-- old bits --
http://www.w3.org/1999/02/26-modules/User/Apache-defer-auth.html
Abstract
Currently apache requires recompilation to allow a CGI script access to the
authorization information. The maintainer must recompile
with -DSECURITY_HOLE_PASS_AUTHORIZATION. There are security vulnerablilties
associated with this patch:

system users
All information is passed from the web server to the CGI script via
environment variables. Users on the system may examine the environment of a
spawned script and extract the authentication credentials for that were
passed to the script.
script authors
Any script author may get the authentication credentials for a user in any
realm on the server. This means you have to trust all script authors to be
resoponsible with user credentials. If
These patches are for a system where there are no untrusted users but there
may be unstrusted scripts. The patch allows the administrator to defer
authentication to scripts on a per-directory basis. On systems with remote
authoring, ie no untrusted users with shell access, but untrusted users able
to insert scripts of their choosing into the resource tree. It would
probably be prudent to disable Options in .htaccess files (AllowOverride
None).

Status
This patch is not submitted to apache as it has not been tested. It is
unlikely to be incorporated if it is submitted as it marginally increases
the ease of introducing a security hole (editing httpd.conf or .htaccess
instead of recompiling apache).



----- Original Message -----
From: "Paul Prescod" <paul@...>
To: <rest-discuss@yahoogroups.com>
Sent: Friday, April 19, 2002 12:54 PM
Subject: [rest-discuss] Capturing HTTP userid in CGI


> I'm trying to make a passthrough app that will restify the Google API. I
> want to allow the end-user to choose whether they want to pass the
> Google "key" (essentially a username) as a keyword parameter or as an
> HTTP user name. I think this would be not too tricky except that I need
> to capture the HTTP user name *as* a key and pass that on to Google. The
> code is just simple CGI for portability. The problem is that I don't
> think that Apache is sending me the username, password or anything else
> I can use. In particular I don't get the HTTP_AUTHORIZATION header. Any
> ideas?
>
>  Paul Prescod
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:1073
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-20 05:28:11
Subject:Re: [rest-discuss] Event notifications in http
Message:

----- Original Message -----
From: "Robert Leftwich" <robert@...>
>
> Yes, I have seen those proposals and am now contemplating how best to move
forward.
>

What's the problem you are trying to solve? What constraints do you have?
Bringing up the problem domain may result in someone with experience with
event systems and another with HTTP/REST and we may get some collaboration
going.

In general REST and event notification go hand in hand. When applied to
HTTP, I take the point of view that "events are messages about changes to
information". The 'about' part implies a reference or URI. The 'changes'
part implies a set of operations. The message part doesn't necessarily imply
who initiates the message - which means you can poll for messages or receive
them spontaneously.

My view on events is that they allow talking 'about information' across a
lifetime of a resource - before it exists and after it is gone. I also think
the 'changes' that are broadcast should be restricted to the methods of the
generic interface you are using.







-----------------------------------------------------------------------------------
Post ID:1074
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-04-20 22:51:50
Subject:REST and travel agents (warning: long) (was Re: [rest-discuss] Event notifications in http)
Message:

At 03:28 PM 20/04/2002, S. Mike Dierken wrote:

>What's the problem you are trying to solve? What constraints do you have?
>Bringing up the problem domain may result in someone with experience with
>event systems and another with HTTP/REST and we may get some collaboration
>going.

For the sake of discussion and to (eventually) serve as a well understood example of REST in action, assume I am implementing a fully REST-ified, event-driven version of the ticket order example described in Appendix D of the Web Services Flow Language document (http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf).

 From this document:

"The overall flow of this example is as follows: A traveler will plan her trip by specifying the various stages of his overall journey and all of its participants. For each of the stages, the traveler specifies the location that she wants to visit as well as the date when she wants to begin and the date when she wants to end the particular stay. When the traveler is finished with this, she sends this information together with the list of all participants of the trip as well as the information about the credit card to be charged for the ordered tickets to the travel agent. The credit card information has been passed when the business process was instantiated. Next, the traveler will await the submission of the electronic tickets as well as the final itinerary for the trip. When the agent receives the traveler�s trip order, he will determine the legs for each of the stages, which includes an initial seat reservation for each of the participants as well as the rate chosen. To actuall
y make the corresponding ticket orders the agent submits these legs together with the information about the credit card to be charged to the airline company. Then, the agent will wait for the confirmation of the flights, which especially includes the actual seats reserved for each of the participants. This information is completed into an itinerary, which is then sent to the traveler.

When the airline receives the ticket order submitted by the agent, the requested seats will be checked and if available assigned to the corresponding participants. After that, the credit card will be charged, and the updated leg information is sent back to the agent as confirmation of the flights. After that, the airline sends the electronic tickets by e-mail to the traveler. Information about the recipient of the tickets has been specified by the traveler when instantiating the trip order process and this information is passed to the agent as well as to the airline."

In order to focus on the event notification issues, assume that the rest of the system is implemented using REST (we might return to this later). The points of interest are as follows 
    1. Trip information to the travel agent
    2. Ticket orders to the airline(s)
    3. Confirmation from the airline(s) to the agent
    4. Itinerary from agent to the traveller
    5. e-tickets from airline(s) to the traveller and notification to agent

Some other requirements may include a monitoring service that registers an interest in all the points above to make sure things are happening in a timely manner, an auditing service and an operations management reporting service for the agents.

So the events of interest may be :
   Trip request received
   Trip created
   Ticket order required
   Ticket ordered
   Ticket confirmed
   Itinerary creation required
   Itinerary created
   Itinerary delivery required
   Itinerary delivered
  E-ticket received
   Trip completed

How is this for a starting point?

Robert







-----------------------------------------------------------------------------------
Post ID:1075
Sender:Seth Johnson <seth.johnson@...>
Post Date/Time:2002-04-23 03:14:07
Subject:The JISC Information Environment and Web Services
Message:

An interesting article on JISC's Information Environment,
part of the Electronic Libraries Program
(http://www.ukoln.ac.uk/services/elib/), and how it compares
to the web services model.  Andy Powell is asking for
comments.

JISC: http://www.jisc.ac.uk/

Seth Johnson

-------- Original Message --------
Subject: The JISC Information Environment and Web services
Date: Mon, 22 Apr 2002 15:17:38 +0100
From: Andy Powell <a.powell@...>


People might be interested in the following article in the
current Ariadne (issue 31):

The JISC Information Environment and Web services
http://www.ariadne.ac.uk/issue31/information-environments/

I'd certainly be interested in hearing any comments that
people have about this article.

For info, a couple of new FAQs are also available on UKOLN's
JISC Information Environment Web pages

  http://www.ukoln.ac.uk/distributed-systems/dner/arch/faq/

A general FAQ and an OAI FAQ have been added to the existing
RSS FAQ. I've tried to base at least some of the questions
and answers on the issues that came up at the 5/99 projects
meeting in Manchester a while back.  Again, comments
welcome.

Andy

--

Distributed Systems, UKOLN, University of Bath, Bath, BA2
7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell       +44 1225
383933
Resource Discovery Network http://www.rdn.ac.uk/







-----------------------------------------------------------------------------------
Post ID:1076
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-23 21:03:31
Subject:HTTP's Page-Enter header`
Message:

I feel like I'm totally out of touch with HTTP's formatting features...

http://www.dynamicdrive.com/dynamicindex3/document2.htm

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1077
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-24 02:34:51
Subject:Re: [rest-discuss] HTTP's Page-Enter header`
Message:

Good lord, they used <html><head><meta http-equiv="">
(html/head/meta/@http-equiv) for that?



----- Original Message -----
From: "Paul Prescod" <paul@...>
To: <fork@...>; <rest-discuss@yahoogroups.com>
Sent: Tuesday, April 23, 2002 2:03 PM
Subject: [rest-discuss] HTTP's Page-Enter header`


> I feel like I'm totally out of touch with HTTP's formatting features...
>
> http://www.dynamicdrive.com/dynamicindex3/document2.htm
>
>  Paul Prescod
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:1078
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-24 04:44:25
Subject:Re: REST and travel agents (warning: long) (was Re: [rest-discuss]Event notifications in http)
Message:

Robert Leftwich wrote:
> 
> At 03:28 PM 20/04/2002, S. Mike Dierken wrote:
> 
> >What's the problem you are trying to solve? What constraints do you have?
> >Bringing up the problem domain may result in someone with experience with
> >event systems and another with HTTP/REST and we may get some collaboration
> >going.
> 
> For the sake of discussion and to (eventually) serve as a well understood example of REST in action, assume I am implementing a fully REST-ified, event-driven version of the ticket order example described in Appendix D of the Web Services Flow Language document (http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf).

I haven't forgotten about or ignored this -- I want to read the appendix
carefully and think it through.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1079
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-04-24 09:20:17
Subject:Re: REST and travel agents
Message:

At 02:44 PM 24/04/2002, Paul Prescod wrote:
>Robert Leftwich wrote:
>> 
>> At 03:28 PM 20/04/2002, S. Mike Dierken wrote:
>> 
>> >What's the problem you are trying to solve? What constraints do you have?
>> >Bringing up the problem domain may result in someone with experience with
>> >event systems and another with HTTP/REST and we may get some collaboration
>> >going.
>> 
>> For the sake of discussion and to (eventually) serve as a well understood example of REST in action, assume I am implementing a fully REST-ified, event-driven version of the ticket order example described in Appendix D of the Web Services Flow Language document (http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf).
>
>I haven't forgotten about or ignored this -- I want to read the appendix
>carefully and think it through.

I look forward to any and all thoughts on this subject.
Given the intense debate on the TAG list, I would be surprised if anyone who is subscribed to it has any spare time :-)

Robert









-----------------------------------------------------------------------------------
Post ID:1080
Sender:Chris Croome <chris@...>
Post Date/Time:2002-04-24 13:04:31
Subject:Re: [rest-discuss] Comments Welcome
Message:

Hi Paul

Great article :-)

On Thu 18-Apr-2002 at 02:29:02AM -0700, Paul Prescod wrote:
> 
> I hereby christen the purified language GoogleML. I've written an XSLT
> stylesheet that I call "pureGoogle.xsl" which translates GoogleSOAP
> into GoogleML. The resulting documents are much smaller, simpler and
> easier to read.

Have you considered RSS 1.0 [1] for this rather than / in addition to
'GoogleML'? The things that can't be done with RSS 1.0 could be added
to RSS with a Google RSS module.

The advantage of not inventing a new language is that there are lots of
tools out there for processing RSS and it's perhaps the widest used XML
variety after XHTML and as result developers who are familiar with RSS
might 'get it' (advantages of REST) quicker?  

Using RSS as a format for returning search engine results has been
suggested before and was mentioned in an article on xml.com almost two
years ago [2].

Chris


[1] http://pulr.org/rss/1.0/

[2] http://www.xml.com/pub/a/2000/07/05/deviant/rss.html

-- 
Chris Croome                               <chris@...>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   
everything else                               http://chris.croome.net/  






-----------------------------------------------------------------------------------
Post ID:1081
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-04-24 14:07:18
Subject:Re: REST and travel agents (warning: long) (was Re: [rest-discuss]Event notifications in http)
Message:

> I haven't forgotten about or ignored this -- I want to read the appendix
> carefully and think it through.

Yah, ditto.  My first impression is that it looks really good from a
resource modelling point of view, but it appears to break down in the
WSDL where operations rather than types are defined.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1082
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-24 15:44:39
Subject:REST and travel agents (warning: long) (was Re: [rest-discuss]Event notifications in http)
Message:

Mark Baker wrote:
> > I haven't forgotten about or ignored this -- I want to read the 
appendix
> > carefully and think it through.
> 
> Yah, ditto.  My first impression is that it looks really good from a
> resource modelling point of view, but it appears to break down in 
the
> WSDL where operations rather than types are defined.

I think workflow is a bad model for the Web for reasons that are 
analogous to why RPC is a bad model.

Workflow is organized around procedures, not resources.

RosettaNet started by trying to use a procedural workflow model but 
abandoned it for a conversational state alignment model.  I'm not 
suggesting the RosettaNet model for REST, becsuse RNet is a message-
passing system, as in message-oriented SOAP.  

But I am pretty sure that REST also needs to adopt an appropriate 
orchestration model that is different from procedure-oriented 
workflow.  And that the REST model should be oriented around resource 
state.  (Others have said similar things on the REST wiki.)

I also think that a resource state model will end up being much 
simpler than workflow.  

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1083
Sender:"tlainevool" <tlainevool@...>
Post Date/Time:2002-04-25 07:04:30
Subject:Re: Restifying Available to Promise
Message:

I was wondering if there might be a way to "slice" this that may be a 
little more RESTful.  In REST a resource represents a service or a 
data element, and every significant resource should have a URI.  In 
the given system there were two services: "availabiltiy amount" 
and "is quantity available", and one data element: the BlueShoe 
product.  It seems that each of these should have their own URI so:

Availability amount service: 
http://www.myinventory.com/services/availablequantity

Is quantity availabilty service: 
http://www.myinventory.com/services/isavailable

BlueShoe: http://www.myinventory.com/product/blueshoe

Then to do the queries the following URIs would be used:

1) http://www.myinventory.com/services/availablequantity?
product=http://www.myinventory.com/product/blueshoe&when=tomorrow

2) http://www.myinventory.com/services/isavailable?
product=http://www.myinventory.com/product/blueshoe&when=tomorrow
&above=100

Like I said, this seems a little more RESTful to me, and I'm trying 
to figure out what the advantages of this approach would be other 
than that it just seems to be the right way.  One thing is that it 
uses a standard way of naming the products (via URIs) instead of 
naming them by adding to a sub-path of an existing URI.  This seems 
more extensible: to add new products into the system, you don't add 
new paths to the URI, just use new query strings.  I

Is this a real advantage? Are there any other advantages to doing it 
this way?  Opinions would be appreciated.

Thanks,

Toivo Lainevool
New Iron Systems

--- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote:
> 
> Interesting.
> 
> The URI (path+query) would point to the answer you want to give, 
having the
> 'path only' point to the product is neato, but not required.
> 
> To get the availability:
> http://www.myinventory.foo/products/blueshoes/availability/?
when=tomorrow
> 
> To get the threshold (more than 100)
> http://www.myinventory.foo/products/blueshoes/availability/?
when=tomorrow&ab
> ove=100
> 
> But of course there are a million ways to slice it.
> You can narrow down the choices based on whether PUT/DELETE/POST 
are needed
> on the same resource - and they probably aren't. POST might be used 
to
> allocate out of the availability - but a business document probably 
will
> have that information & so you'd just submit it to the 'orders' 
collection &
> let the values be updated via business logic (meaning that the 
values from
> these two sample queries are 'synthetic' properties, derived from 
data
> manipulated via other actions)
> 
> 
> ----- Original Message -----
> From: "bhaugen32" <bhaugen32@y...>
> To: <rest-discuss@y...>
> Sent: Thursday, April 04, 2002 10:42 AM
> Subject: [rest-discuss] Restifying Available to Promise
> 
> 
> > Assuming this group is still alive (I know everybody's been busy
> > evangelizing in W3C lists), I have a followup question on the
> > purchase order scenarios.
> >
> > There is a standard function in an ERP system called Available to
> > Promise, or ATP for short.
> >
> > "Available" means "not already promised to somebody".
> >
> > It is used to decide if a purchase order can be fulfilled or not.
> > It is usually used for purchase orders for products, so that is 
what
> > I will describe here.
> >
> > There are a variety of APIs and algorithms, but they boil down to 
two
> > main queries, which I will describe in plain English, not code:
> >
> > 1.  How much of a product is available to promise at a future 
time?
> > For example, how many blue shoes can I get by tomorrow?
> > The answer is a quantity.
> >
> > 2. Is a specified quantity of a product at a specified time?
> > For example, can I get 100 blue shoes tomorrow?
> > The answer is a boolean.
> >
> > This query might be offered to a customer to use before they 
place an
> > order, or it might be used by the order-taking Web resource before
> > accepting an order.
> >
> > In REST terms, I assume this is a GET with parameters, and the Web
> > resource to address is the Product (i.e. BlueShoe).
> >
> > How would you say it?
> >
> > Thanks,
> > Bob Haugen
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@y...
> >
> >
> >
> > Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/
> >
> >
> >







-----------------------------------------------------------------------------------
Post ID:1084
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-25 11:34:27
Subject:Re: Restifying Available to Promise
Message:

"tlainevool" wrote:
> I was wondering if there might be a way to "slice" this that may be 
a 
> little more RESTful.  In REST a resource represents a service or a 
> data element, and every significant resource should have a URI.  

"Service" seems to me a lot more like SOAP than REST.
I think of resource as a significant business entity
or an aggregation of business entities.
Usually larger granularity than a data element.

> In 
> the given system there were two services: "availabiltiy amount" 
> and "is quantity available", and one data element: the BlueShoe 
> product.  It seems that each of these should have their own URI so:
> 
> Availability amount service: 
> http://www.myinventory.com/services/availablequantity
> 
> Is quantity availabilty service: 
> http://www.myinventory.com/services/isavailable

Let's contrast that with Mike Dierken's original suggestion:
http://www.myinventory.foo/products/blueshoes/availability/

"Availability" is actually an aggregate business entity.
It is the aggregate of on hand inventory plus the stream
of expected receipts, minus the stream of expected demands.
It might also be called MRP (Material Requirements Plan).

"Availability" even has a standard representation:
a time-phased table of planned inventory inputs and outputs with a 
running balance.

A query into this table can show the available balance at some future 
date.

As an old MRP jock, I like Mike's suggestion better.

As to which is more RESTful, I leave that to further discussion.
I'm a rookie here myself.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1085
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-25 18:51:33
Subject:Re: [rest-discuss] Re: Restifying Available to Promise
Message:

> >
> > Is quantity availabilty service:
> > http://www.myinventory.com/services/isavailable
>
> Let's contrast that with Mike Dierken's original suggestion:
> http://www.myinventory.foo/products/blueshoes/availability/
>

>
> As to which is more RESTful, I leave that to further discussion.
> I'm a rookie here myself.

My thoughts on REST are that one aspect implies 'lots of nouns, few verbs'.
When applied to HTTP, this means each URI would reasonably support
GET/PUT/POST/DELETE.  If the system accepted changes to availability via
HTTP, then a PUT to the URI might make sense - in this example,
'availability' is a very synthesized entity and it probably doesn't make
sense.

The differences between the two are fairly minor.

http://www.myinventory.com/services/availablequantity?product=http://www.myi
nventory.com/product/blueshoe&when=tomorrow

http://www.myinventory.foo/products/blueshoes/availability/?when=tomorrow

I chose not to use full a URI to indicate the product, because I felt the
owner of the resources would have their own 'internal ID' of the product,
and I didn't expect them to be fully URI based for their keys - but they
could just as easily be URIs.

I also didn't break the problem down into functions and parameters - I tried
to break it down into addressable information entities.
This way it would be easy to 'hang new properties' off of a product via the
path segments of a URI. But that is purely a stylistic opinion - I just like
path based rather than query string based addressing. It helps me
concentrate on information rather than function+parameters.

Something I'm still thinking about is how a client acquires the URI to begin
with. Either of these two approaches could return the same data, so they are
equivalent from that point of view - but is one easier to use from the
client? This gets into the "hyperlink .vs. generative" argument. I like the
hyperlink approach because it has the promise of a client talking to these
two different styles of URIs without knowing or caring - more loose
coupling. But I like the generative approach because the client may have a
fragment of information that is not part of the name/location of the
hyperlink that has the URI, but is actually part of the value of the URI.

Here are some concrete examples that help me think about the issues. In both
cases the text 'productId' is a coordinating name. In both cases the client
also knows the value 'blueshoes'. One difference is that the hyperlink
examples has to list all possible values - which might be a bit much.

--hyperlink1--
<stuff>
 <availability
productId='blueshoes'>http://www.myinventory.foo/products/blueshoes/availabi
lity/?when=tomorrow</availability>
</stuff>

--hyperlink2--
<product productId='blueshoes'>

<availability>http://www.myinventory.foo/products/blueshoes/availability/?wh
en=tomorrow</availability>

<description>http://www.myinventory.foo/products/blueshoes/description/</des
cription>
</stuff>

--generative1--
<stuff>

<availability>http://www.myinventory.foo/products/%productId%/availability/?
when=tomorrow</availability>
</stuff>

--generative2--
<stuff>
 <availability>http://www.myinventory.foo/products/<productId
/>/availability/?when=tomorrow</availability>
</stuff>


--generative3 (not recommened, since entities scare the bunnies and break
lots of code)--
<stuff>

<availability>http://www.myinventory.foo/products/&productId;/availability/?
when=tomorrow</availability>
</stuff>








-----------------------------------------------------------------------------------
Post ID:1086
Sender:Andrew Kuchling <akuchlin@...>
Post Date/Time:2002-04-25 20:00:09
Subject:Autogenerating REST code: which format?
Message:

A while ago I wrote up a set of ideas for RESTifying a service.  I
began implementing those ideas, but abandoned them as the code began
to get more and more repetitive.  Writing a REST application seems
naturally suited to a code generator.

However, what description format should this code generator take?
Paul uses a WSDL example in his latest xml.com article, but observes
that WSDL doesn't support links.  I also noticed that the WSDL note
only mentions HTTP GET/POST, and for a code generator you'd want to
say what other HTTP operations (DEL, PUT, &c) are supported on a
resource.  Also, the authors of the note are all from large companies
that have embraced SOAP, making me pessimistic about the likelihood of
improving the WSDL HTTP binding.

The other option is Paul's WRDL, but its current state of completion
isn't clear, though the TODO list does seem to be mostly second-order
things.

Anyone have suggestions on which format would be the best choice?

--amk                                                             (www.amk.ca)
"Symbols have *power*, Netley... Power enough to turn even a stomach such as
yours, or to deliver half this planet's population into slavery."
    -- Gull, in FROM HELL #4






-----------------------------------------------------------------------------------
Post ID:1087
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-25 22:49:12
Subject:Re: [rest-discuss] Autogenerating REST code: which format?
Message:

Code for client or server?
What do you have so far - in terms of common code/api tasks?

----- Original Message -----
From: "Andrew Kuchling" <akuchlin@...>
To: <rest-discuss@yahoogroups.com>
Sent: Thursday, April 25, 2002 1:00 PM
Subject: [rest-discuss] Autogenerating REST code: which format?


> A while ago I wrote up a set of ideas for RESTifying a service.  I
> began implementing those ideas, but abandoned them as the code began
> to get more and more repetitive.  Writing a REST application seems
> naturally suited to a code generator.
>
> However, what description format should this code generator take?
> Paul uses a WSDL example in his latest xml.com article, but observes
> that WSDL doesn't support links.  I also noticed that the WSDL note
> only mentions HTTP GET/POST, and for a code generator you'd want to
> say what other HTTP operations (DEL, PUT, &c) are supported on a
> resource.  Also, the authors of the note are all from large companies
> that have embraced SOAP, making me pessimistic about the likelihood of
> improving the WSDL HTTP binding.
>
> The other option is Paul's WRDL, but its current state of completion
> isn't clear, though the TODO list does seem to be mostly second-order
> things.
>
> Anyone have suggestions on which format would be the best choice?
>
> --amk
(www.amk.ca)
> "Symbols have *power*, Netley... Power enough to turn even a stomach such
as
> yours, or to deliver half this planet's population into slavery."
>     -- Gull, in FROM HELL #4
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:1088
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-25 22:52:22
Subject:Re: [rest-discuss] Autogenerating REST code: which format?
Message:

Andrew Kuchling wrote:
> 
> A while ago I wrote up a set of ideas for RESTifying a service.  I
> began implementing those ideas, but abandoned them as the code began
> to get more and more repetitive.  Writing a REST application seems
> naturally suited to a code generator.

I'm somewhat surprised to hear you say that, because in my experience,
code generators are for people using lesser languages. ;) Python
programmers can typically do at runtime what code generators do at
compile time -- and with more flexibility and ease of use.

So I would say that you are in a good position to start with your code
and factor away the irrelevancies using Python constructs until you have
essentially factored the code into a declarative portion and an
executable portion. If the declarative portion corresponds exactly to
WRDL then I'm on the right track with it.

> However, what description format should this code generator take?
> Paul uses a WSDL example in his latest xml.com article, but observes
> that WSDL doesn't support links.  I also noticed that the WSDL note
> only mentions HTTP GET/POST, and for a code generator you'd want to
> say what other HTTP operations (DEL, PUT, &c) are supported on a
> resource.  Also, the authors of the note are all from large companies
> that have embraced SOAP, making me pessimistic about the likelihood of
> improving the WSDL HTTP binding.

WSDL is not a W3C project so you are not subject to the whims of W3C
politics which may make you feel better or not. They have accepted my
requirement that WSDL should support links as an official requirement
(so far) but in my thinking about this issue, it is not trivial so they
may be tempted to do it in a half-assed way when they actually sit down
to implement.

WSDL is kind of a complicated language with many different layers of
abstraction. This will make code generation a pain in the ass. The AXIS
SOAP toolkit's "wsdl2Java" is almost 9000 lines of non-comment Java
code. Plus, I don't know how far you will get with WSDL given its
current state of link-support. It's not that I'm biased in favor of my
own language: I would love to have an "industry standard" language that
already supported REST. If you can make WSDL work for you then more
power to you, maybe I can learn something.

> The other option is Paul's WRDL, but its current state of completion
> isn't clear, though the TODO list does seem to be mostly second-order
> things.

True. In my mind the primary weakness with WRDL is that it isn't
integrated into any kind of data binding framework. To clarify: WSDL
more or less depends upon XML Schema. That means that if you figure out
a way to map XML Schema into your language (as many languages have done
-- at least for simple stuff) then you can generate wrapper classes that
know how to serialize and deserialize themselves "for free".

If C#/Java programmers have to go back to working with a DOM then they
will not be happy with WRDL. On the other hand, I am loathe to make WRDL
explicitly depend on XML Schema when that is such a hard language to
implement and use. I also don't want to choose RELAX when XML Schema is
where the rest of the industry is going. In theory I could say: "use
whatever schema language you want" but then a WRDL implementation that
uses RELAX will not be entirely interoperable with one that uses XML
Schema. Still, that's probably the way I will go and let the market
decide. A third option is to ignore the schema and make a simple data
binding language -- maybe compile the different schema languages to
that.

Also, as an implementation issue, WRDL should naturally "extend" the
data binding process by making elements and attributes of type anyURI
strongly typed. That could be difficult in many data binding frameworks.
:(

If you are happy working with a DOM instead of data-bound,
bi-directional "objects" then I think WRDL is a good place to start.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1089
Sender:akuchlin@...
Post Date/Time:2002-04-26 04:33:03
Subject:Re: [rest-discuss] Autogenerating REST code: which format?
Message:

On Thu, Apr 25, 2002 at 03:52:22PM -0700, Paul Prescod wrote:
>So I would say that you are in a good position to start with your code
>and factor away the irrelevancies using Python constructs until you have
>essentially factored the code into a declarative portion and an
>executable portion. If the declarative portion corresponds exactly to

There were two problems, at least when doing this in Quixote.  The
first was that I ended up writing a class to represent each object and
sub-object; so if there was a Service URI, and Services contain
Tickets, I needed to write Service and Ticket classes.  The second was
that my method implementations all looked like:

	def metadata (request):
	   rm = request.environ['REQUEST_METHOD']
	   if rm == 'GET':
	       # retrieve data & return it
	   elif rm == 'PUT':
	       # read body & store it
	   elif rm == 'POST':
	       # whatever POST does

I suppose some clever base class could do this work, and call
metadata_get() and metadata_put() methods. 

>They have accepted my
>requirement that WSDL should support links as an official requirement...

Wouldn't PUT/DEL also need to be supported in order to implement all
of REST?

>True. In my mind the primary weakness with WRDL is that it isn't
>integrated into any kind of data binding framework. To clarify: WSDL
>more or less depends upon XML Schema. That means that if you figure out
>a way to map XML Schema into your language (as many languages have done
>-- at least for simple stuff) then you can generate wrapper classes that
>know how to serialize and deserialize themselves "for free".

Does this matter for a dynamic language, though?  You could just
return XML-marshalled objects of whatever type, agreeing on the DTD
beforehand, and let the chips fall at runtime.

--amk                                                             (www.amk.ca)
  "Yes, but who do you work for?"
  "Work for? I don't work *for* anybody; I'm just having fun."
    -- Rigg and the Doctor, in "Nightmare of Eden"






-----------------------------------------------------------------------------------
Post ID:1090
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-26 06:24:35
Subject:Re: [rest-discuss] Autogenerating REST code: which format?
Message:

akuchlin@... wrote:
> 
> ...
> 
> There were two problems, at least when doing this in Quixote.  The
> first was that I ended up writing a class to represent each object and
> sub-object; so if there was a Service URI, and Services contain
> Tickets, I needed to write Service and Ticket classes.  

Some people would call that "resource object binding" and call it a
feature. Plus you could use a base class for anything repetitive.

>...
> I suppose some clever base class could do this work, and call
> metadata_get() and metadata_put() methods.

Good idea. 

> >They have accepted my
> >requirement that WSDL should support links as an official requirement...
> 
> Wouldn't PUT/DEL also need to be supported in order to implement all
> of REST?

I'm planning to submit that as a "WSDL 1.1 bug report" and see if it
gets fixed. I'm somewhat of a REST heretic in that I think that you get
a big chunk of the benefit from GET and POST is a way to handle
non-idempotent stuff. I'm not saying that's ideal but that its probably
sufficient. Worse comes to worse, you 

> >True. In my mind the primary weakness with WRDL is that it isn't
> >integrated into any kind of data binding framework. To clarify: WSDL
> >more or less depends upon XML Schema. That means that if you figure out
> >a way to map XML Schema into your language (as many languages have done
> >-- at least for simple stuff) then you can generate wrapper classes that
> >know how to serialize and deserialize themselves "for free".
> 
> Does this matter for a dynamic language, though?  You could just
> return XML-marshalled objects of whatever type, agreeing on the DTD
> beforehand, and let the chips fall at runtime.

It is nice to know when you see the XML whether it should be treated as
a struct or array, integer, string or boolean. The schema can tell you
that -- otherwise you need to treat all child nodes as a string (in case
you happen to have repeated elements) and all attributes as "just
strings".

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1091
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-04-26 09:22:34
Subject:RE: [rest-discuss] Re: Restifying Available to Promise
Message:


bhaugen32 wrote:
> 
> "tlainevool" wrote:
> > I was wondering if there might be a way to "slice" this that may be
> a
> > little more RESTful.  In REST a resource represents a service or a
> > data element, and every significant resource should have a URI.
> 
> "Service" seems to me a lot more like SOAP than REST.
> I think of resource as a significant business entity
> or an aggregation of business entities.
> Usually larger granularity than a data element.
> 

I'm not sure if this is true. Roy Fielding dissertation defines a
resource as "Any information that can be named can be a resource: a
document or image, a temporal service (e.g. "today's weather in Los
Angeles"), a collection of other resources, a non-virtual object (e.g. a
person), and so on."  HTTP defines it as "A network data object or
service that can be identified by a URI".  It seems like services are a
valid concept to assign a URI to.

Toivo Lainevool







-----------------------------------------------------------------------------------
Post ID:1092
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-04-26 09:50:03
Subject:RE: [rest-discuss] Re: Restifying Available to Promise
Message:

S. Mike Dierken wrote:
> 
> My thoughts on REST are that one aspect implies 'lots of nouns, few
> verbs'.
> When applied to HTTP, this means each URI would reasonably support
> GET/PUT/POST/DELETE.  If the system accepted changes to availability
via
> HTTP, then a PUT to the URI might make sense - in this example,
> 'availability' is a very synthesized entity and it probably doesn't
make
> sense.
> 

This is one concept I keep trying to get my head wrapped around.  I've
been developing and using ORBs for a while, so I always leap to a very
RPCish view.  I see this as one of the main differences between RPC and
REST: RPC's whole reason for existing is to define NEW verbs, REST
limits them so that the underlying architecture can use the verbs
intelligently when doing things like security and caching.  I have to
keep reminding myself that URIs do not identify methods or groups of
methods, they identify resources.

> 
> Something I'm still thinking about is how a client acquires the URI to
> begin
> with. Either of these two approaches could return the same data, so
they
> are
> equivalent from that point of view - but is one easier to use from the
> client? This gets into the "hyperlink .vs. generative" argument. I
like
> the
> hyperlink approach because it has the promise of a client talking to
these
> two different styles of URIs without knowing or caring - more loose
> coupling. But I like the generative approach because the client may
have a
> fragment of information that is not part of the name/location of the
> hyperlink that has the URI, but is actually part of the value of the
URI.
> 

This is an interesting topic.  When it comes to the underlying
components in a RESTful system, the URI are opaque.  The servers,
proxies and gateways don't care what the internal format of the URIs
are, but the system you build on top of it could care about the details.
Having the client be able to work with the format of the URI might make
for a more powerful system.  If the system has a resource for returning
a product catalog, e.g.:

<products>
  <product name="http://www.myinventory.foo/product/blueshoe">
  <product name="http://www.myinventory.foo/product/redshoe">
  ... etc ...
</products>

In that case it would be reasonable for the client to do a GET on the
name URI and receive a product information document.  PUT/POST/DELETE
could also be used for modifying/deleting the product information.

The client could then also use these same product names in the query
part of the availability URIs, as I explained earlier, like this:
http://www.myinventory.com/services/availablequantity?product=http://www
.myi
nventory.com/product/blueshoe&when=tomorrow

In the earlier suggestion where the following URI was used:
http://www.myinventory.foo/products/blueshoes/availability/?when=tomorro
w
The "blueshoe" product would be known by two names by the client, the
URI and the name "blueshoe".  

I guess my point is that since we already have a way of naming things in
a REST system (i.e. URIs), why not use it for every name in the system?
This was one of the points made in Paul Prescod's xml.com article about
a RESTful version of UDDI; why use GUIDs when you already have URIs?

Toivo Lainevool







-----------------------------------------------------------------------------------
Post ID:1093
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-26 12:21:23
Subject:Re: Restifying Available to Promise
Message:

"Toivo \"Deutsch\" Lainevool" wrote:
> 
> 
> bhaugen32 wrote:
> > 
> > "tlainevool" wrote:
> > > I was wondering if there might be a way to "slice" this that 
may be
> > a
> > > little more RESTful.  In REST a resource represents a service 
or a
> > > data element, and every significant resource should have a URI.
> > 
> > "Service" seems to me a lot more like SOAP than REST.
> > I think of resource as a significant business entity
> > or an aggregation of business entities.
> > Usually larger granularity than a data element.
> > 
> 
> I'm not sure if this is true. Roy Fielding dissertation defines a
> resource as "Any information that can be named can be a resource: a
> document or image, a temporal service (e.g. "today's weather in Los
> Angeles"), a collection of other resources, a non-virtual object 
(e.g. a
> person), and so on."  HTTP defines it as "A network data object or
> service that can be identified by a URI".  It seems like services 
are a
> valid concept to assign a URI to.

I am not a purist, and can go along with assigning a URI to a service.

But when you already have a Product resource, it seems to me that 
asking a Service for availability by Product is going backwards to 
something more like a Web service.  I like much better asking the 
Product resource for its availability, especially when "availability" 
itself is a well-recognized business aggregation with a standard 
definition from APICS, the Production and Inventory Control Society.

In a Web business situation, I want my significant business entities 
to be resources with URIs:  products, orders, disbursements and 
receipts, etc.  I want them also to be hyperlinked to each other: 
products to orders, orders to products, disbursements and receipts to 
orders, etc.

All of the above is why REST makes more sense to me from a business 
modeling perspective than SOAP.

As Mike Dierken says, I want more nouns than verbs.  

As I said, this is just the way I think about it as a rookie.
But I've been working my way through some common business situations 
and it's holding up pretty well so far.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1094
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-26 17:09:09
Subject:REST vs SOAP-EDI
Message:

Mark Baker wrote in 
http://lists.w3.org/Archives/Public/www-tag/2002Apr/0290.html 

"I think that if SOAP has a future on the Web (as opposed to on the 
Internet), it will be with the chameleon use where both SOAP and HTTP 
are used by developers at the same time (though an EDI-like use of 
SOAP over POST is fine, it's a niche)."

ebXML (where I still spend a lot of time) is an example of the niche 
of EDI-like use of SOAP over POST.

I'm finding it instructive to consider RESTifying ebXML.

When you do EDI-like messaging over SOAP, all the messages get sent 
to what amounts to a mailbox with a URI.  Behind the mailbox is a 
dispatcher that forwards the messages to some internal system 
function that will handle them.

Which means ebXML messages need to be tagged with a bunch of 
dispatching addresses that are usually not URIs.

ebXML has a collaboration containment hierarchy that goes like:
BusinessCollaboration
..BusinessTransaction
....BusinessAction (Requesting or Responding)

So a message needs to be tagged with identifiers for each layer in 
that hierarchy to get to its eventual destination (the handler for 
the BusinessAction).  And all (or at least many) messages need to go 
through the same dispatcher.

If I consider that from a REST perspective, we're collaborating about 
some business deal which is usually embodied in a common business 
entity: let's say an Order.

So if I make the Order into a Web resource, created by the initial 
POST, then all subsequent POSTs or GETs are addressed either to that 
Order resource or one of its sub-resources (LineItems, Deliveries, 
Invoices, Payments, etc.)

I consider Transactions to be business entities, so they could be sub-
resources.

So I no longer have one gateway URI with a dispatcher behind it, I am 
directly addressing the relevant business resource.

Seems much simpler and more scalable to me.

(By the way, if anybody from ebXML is reading this, I think this is 
all compatible with the business principles behind ebXML...so don't 
shoot me yet.)

Does this make sense to anybody else?

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:1095
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-04-26 18:02:07
Subject:Re: [rest-discuss] REST vs SOAP-EDI
Message:

On Fri, Apr 26, 2002 at 05:09:09PM -0000, bhaugen32 wrote:
> Does this make sense to anybody else?

Yep, that's exactly my thinking too.

Plus, because you're identifying the mailbox at a more granular
level than just a catch-all mailbox, GET, PUT, and DELETE makes
sense.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1096
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-26 18:27:14
Subject:Re: REST vs SOAP-EDI
Message:

Mark Baker wrote:
> because you're identifying the mailbox at a more granular
> level than just a catch-all mailbox, GET, PUT, and DELETE makes
> sense.

If it the resource is not really a mailbox, but a business entity, 
then GET always makes sense.  The business entity can always summon 
up a representation of its current state.

Permission for PUT and DELETE would be up to the resource, and may 
depend on its current state (for example you can't delete the 
resource for an airline ticket after it's been issued, and even 
cancellation may invoke a penalty).

-BH







-----------------------------------------------------------------------------------
Post ID:1097
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-27 00:10:39
Subject:Re: [rest-discuss] Re: Restifying Available to Promise
Message:

----- Original Message -----
From: "Toivo "Deutsch" Lainevool" <tlainevool@...>

>
> In that case it would be reasonable for the client to do a GET on the
> name URI and receive a product information document.  PUT/POST/DELETE
> could also be used for modifying/deleting the product information.
>
> The client could then also use these same product names in the query
> part of the availability URIs, as I explained earlier, like this:
> http://www.myinventory.com/services/availablequantity?product=http://www
> .myi
> nventory.com/product/blueshoe&when=tomorrow
>
> In the earlier suggestion where the following URI was used:
> http://www.myinventory.foo/products/blueshoes/availability/?when=tomorro
> w
> The "blueshoe" product would be known by two names by the client, the
> URI and the name "blueshoe".
>
You are right about the need for two names - I'm just not sure what the best
way of doing it is. It seems that using a URI for everything is a bit
excessive, but I haven't spent a lot of time in this area.









-----------------------------------------------------------------------------------
Post ID:1098
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-27 00:32:34
Subject:Re: Restifying Available to Promise
Message:

"S. Mike Dierken" wrote:
> 
> ----- Original Message -----
> From: "Toivo "Deutsch" Lainevool" <tlainevool@n...>
> 
> >
> > In that case it would be reasonable for the client to do a GET on 
the
> > name URI and receive a product information document.  
PUT/POST/DELETE
> > could also be used for modifying/deleting the product information.
> >
> > The client could then also use these same product names in the 
query
> > part of the availability URIs, as I explained earlier, like this:
> > http://www.myinventory.com/services/availablequantity?
product=http://www
> > .myi
> > nventory.com/product/blueshoe&when=tomorrow
> >
> > In the earlier suggestion where the following URI was used:
> > http://www.myinventory.foo/products/blueshoes/availability/?
when=tomorro
> > w
> > The "blueshoe" product would be known by two names by the client, 
the
> > URI and the name "blueshoe".
> >
> You are right about the need for two names - I'm just not sure what 
the best
> way of doing it is. It seems that using a URI for everything is a 
bit
> excessive, but I haven't spent a lot of time in this area.

I don't understand the two names argument.
What two names do you mean?
URI including "blueshoes" plus "blueshoes" all by itself?  
Why is that a problem?

Nor do I understand "services/availability/?product=" 
vs "products/blueshoes/availability".

What am I missing?

>It seems that using a URI for everything is a bit
> excessive, but I haven't spent a lot of time in this area.

Why isn't it better for more things to have identities?
(I'm not sure where "excessive" begins, but for each product to have 
its own URI does not seem to be even close to the edge.)








-----------------------------------------------------------------------------------
Post ID:1099
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-04-27 01:10:44
Subject:RE: [rest-discuss] Re: Restifying Available to Promise
Message:

> 
> I don't understand the two names argument.
> What two names do you mean?
> URI including "blueshoes" plus "blueshoes" all by itself?

Yes.

> Why is that a problem?

Anytime you have to keep track of one with two names I think you are
asking for trouble.  

> 
> Nor do I understand "services/availability/?product="
> vs "products/blueshoes/availability".
> 
> What am I missing?

The difference is not major.  To the underlying components (HTTP
servers, caches, etc) they are identical.  The difference comes if you
want to be able to generate these URIs and you want to use URIs for the
name of the product.  Then the first one works.

> 
> >It seems that using a URI for everything is a bit
> > excessive, but I haven't spent a lot of time in this area.
> 
> Why isn't it better for more things to have identities?
> (I'm not sure where "excessive" begins, but for each product to have
> its own URI does not seem to be even close to the edge.)
> 
I think he meant "using a URI" is excessive not "a URI for everything"
is excessive.  I personally don't think it is excessive because
hopefully all this is automated so the user never sees these names.
URIs don't cost anything to create vs. a simple string. (Well maybe a
little extra memory, but not enough to really matter.)

Toivo Lainevool







-----------------------------------------------------------------------------------
Post ID:1100
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-27 02:56:48
Subject:Re: [rest-discuss] Re: Restifying Available to Promise
Message:

> >
> > Nor do I understand "services/availability/?product="
> > vs "products/blueshoes/availability".
> >
> > What am I missing?
>
> The difference is not major.  To the underlying components (HTTP
> servers, caches, etc) they are identical.  The difference comes if you
> want to be able to generate these URIs and you want to use URIs for the
> name of the product.  Then the first one works.
I agree that historically it has been easier to construct a uri via query
terms - but that doesn't make path based URI construction difficult, it just
means nobody has provided a commonly recognized way to do it. It ends up
being an implementation preference, in my opinion, because I think you are
right when you point out that the underlying components see them as
identical.

I suppose that the choice between a short identifier and a URI (for product
ID in the examples) depends on how you acquire that product ID - in most
cases you will just echo back what the server gave to you initially (and a
full uri probably works better as a query term). A full-blown hypertext
approach would be URI through and through, but I believe that has problems
with interoperability - every service that wants to participate must know
the full URI of the product, which to me seems very constraining on
implementation choices.  But it also means some sort of correlation ability
needs to exist - which might add too much complexity. I need to spend some
time and try different approaches out (which will be quite a while...)

>
> >
> > >It seems that using a URI for everything is a bit
> > > excessive, but I haven't spent a lot of time in this area.
> >
> > Why isn't it better for more things to have identities?
> > (I'm not sure where "excessive" begins, but for each product to have
> > its own URI does not seem to be even close to the edge.)
> >
> I think he meant "using a URI" is excessive not "a URI for everything"
> is excessive.
Yes.

> I personally don't think it is excessive because
> hopefully all this is automated so the user never sees these names.
> URIs don't cost anything to create vs. a simple string. (Well maybe a
> little extra memory, but not enough to really matter.)
I agree also - but without playing with a couple systems that do this - and
try to connect between them without them being aware of it - I'm not sure if
it is doable. It just seems that to bridge autonomous services (unaware of
each other) you are going to have to do uri mapping (not to mention message
format mapping...)








-----------------------------------------------------------------------------------
Post ID:1101
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-04-27 04:08:43
Subject:Re: [rest-discuss] Re: Restifying Available to Promise
Message:

I'm not sure I understand this "two name" problem.

If I have a URI identifying me, and I want another URI that identifies
the clothes I'm currently wearing, the latter URI does not need to use
the former URI in a query term, or in any other fashion.

Just have;

http://www.markbaker.ca/

and

http://www.markbaker.ca/current-clothes/

Any relationship between the two should be expressed as an assertion
someplace. e.g.

<http://www.markbaker.ca/> :wears <http://www.markbaker.ca/current-clothes/>

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1102
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-04-27 04:14:17
Subject:Re: [rest-discuss] Re: Restifying Available to Promise
Message:

On Fri, 2002-04-26 at 21:56, S. Mike Dierken wrote:
> 
> It ends up
> being an implementation preference, in my opinion, because I think you are
> right when you point out that the underlying components see them as
> identical.
> 

Actually, there are some differences beyond the aesthetic;  cf. the
"generative naming" discussions here on list and on the Wiki about a
month ago.  Short version:  there are things we can guarantee about
path-based URI that can't be easily or at all guaranteed with path-based
constructions.

$0.02,

jb









-----------------------------------------------------------------------------------
Post ID:1103
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-04-27 04:21:35
Subject:Re: [rest-discuss] Re: Restifying Available to Promise
Message:

On Fri, 2002-04-26 at 23:14, Jeff Bone wrote:
> 
> that can't be easily or at all guaranteed with path-based
> constructions.

"with query-based constructions."

jb








-----------------------------------------------------------------------------------
Post ID:1104
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-04-27 06:42:21
Subject:Re: [rest-discuss] Autogenerating REST code: which format?
Message:

Hi amk,

I've been plugging away (slowly) at a framework I'm calling Tarawa for a 
while. It's basically a toolkit for writing RESTful web applications, 
and is an outgrowth/generalisation of the exploration I did in Wallal 
[1].

The idea is to play off of the similarities between objects and REST;

instance -> resource (noun)
method -> method (verb)
parameters -> parameters / query
return value -> representation

Thus, tarawa would define a class, Resource, which you could subclass 
into a specific kind of resource, say a homepage, and then hang methods 
off it, which would handle content negotiation;

class Homepage(tarawa.Resource):
	def GET_text_html(self, parameters, query_args):
		[ process ]
		return representation

	def text_xml_PUT_text_html(self, parameters, query_args, 
representation):
		[ ... ]
		return representation

and so forth. This gives you a nice way to resource-model apps, and the 
ability to drop in a variety of back-ends (e.g., CGI, medusa, etc.) 
State would live with the instance, and can be loaded and stored at 
instance __init__ and __del__ as appropriate. In the future, I'd like to 
have intermediate subclasses to handle things like authentication, 
caching, etc.

It's now mostly a lot of pseudocode, although I think it's mostly 
functional at a high level; the conneg and dispatching stuff is pretty 
much ready for testing. If anyone's interested, I'll document what's 
there and throw it up; I'd be glad for some help / ideas / crit.

Cheers,


1. http://www.mnot.net/wallal/


On Thursday, April 25, 2002, at 09:33  PM, akuchlin@... 
wrote:

> On Thu, Apr 25, 2002 at 03:52:22PM -0700, Paul Prescod wrote:
>> So I would say that you are in a good position to start with your code
>> and factor away the irrelevancies using Python constructs until you 
>> have
>> essentially factored the code into a declarative portion and an
>> executable portion. If the declarative portion corresponds exactly to
>
> There were two problems, at least when doing this in Quixote.  The
> first was that I ended up writing a class to represent each object and
> sub-object; so if there was a Service URI, and Services contain
> Tickets, I needed to write Service and Ticket classes.  The second was
> that my method implementations all looked like:
>
> 	def metadata (request):
> 	   rm = request.environ['REQUEST_METHOD']
> 	   if rm == 'GET':
> 	       # retrieve data & return it
> 	   elif rm == 'PUT':
> 	       # read body & store it
> 	   elif rm == 'POST':
> 	       # whatever POST does
>
> I suppose some clever base class could do this work, and call
> metadata_get() and metadata_put() methods.
>
>> They have accepted my
>> requirement that WSDL should support links as an official 
>> requirement...
>
> Wouldn't PUT/DEL also need to be supported in order to implement all
> of REST?
>
>> True. In my mind the primary weakness with WRDL is that it isn't
>> integrated into any kind of data binding framework. To clarify: WSDL
>> more or less depends upon XML Schema. That means that if you figure out
>> a way to map XML Schema into your language (as many languages have done
>> -- at least for simple stuff) then you can generate wrapper classes 
>> that
>> know how to serialize and deserialize themselves "for free".
>
> Does this matter for a dynamic language, though?  You could just
> return XML-marshalled objects of whatever type, agreeing on the DTD
> beforehand, and let the chips fall at runtime.
>
>
--
Mark Nottingham
http://www.mnot.net/







-----------------------------------------------------------------------------------
Post ID:1105
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-27 12:12:48
Subject:Re: Restifying Available to Promise
Message:

"Toivo \"Deutsch\" Lainevool" wrote:
> > 
> > I don't understand the two names argument.
> > What two names do you mean?
> > URI including "blueshoes" plus "blueshoes" all by itself?
> 
> Yes.
> 
> > Why is that a problem?
> 
> Anytime you have to keep track of one with two names I think you are
> asking for trouble.  

If you mean programmatically or in hyperlinks, if the URI is the 
identifier of the product, why would you ever need to use "blueshoes" 
all by itself?  (Unless you were searching for its URI.)

> > Nor do I understand "services/availability/?product="
> > vs "products/blueshoes/availability".
> > 
> > What am I missing?
> 
> The difference is not major.  To the underlying components (HTTP
> servers, caches, etc) they are identical.  The difference comes if 
you
> want to be able to generate these URIs and you want to use URIs for 
the
> name of the product.  Then the first one works.

Re "name of the product":
The "products/blueshoes" URI *is* the Web resource identifier of the 
product. I don't understand how "services" is a better name for a 
product.

Re availability syntax:
Either way I have to get either a full URI or a partial URI from 
somewhere: sent in a message or found by query or navigation.

In your "services/availability/?product=" notation, I needed to know 
not only that syntax plus the URI of the product.

If I have the URI of the product, I can ask it for its business 
protocols which could be expressed in some as-yet-to-be-defined 
business protocol representation, related to Paul's WRDL.
If I want to find "services/availability", I would need to do 
something similar.

In other words, I don't see any big technical advantage to 
the "services/availability/?product=" notation.
And semantically it seems like a Web service, not a resource.

But I am pretty sure that the product will have its own URI, 
and "availability" is a natural property (thus sub-resource) of a 
product.

So semantically I like it better.  I think it will be a better way to 
compose relationships between resources.







-----------------------------------------------------------------------------------
Post ID:1106
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-27 20:57:24
Subject:Re: [rest-discuss] Re: Restifying Available to Promise
Message:

Mark Baker wrote:
> 
> I'm not sure I understand this "two name" problem.
> 
>...
> 
> Any relationship between the two should be expressed as an assertion
> someplace. e.g.
> 

I want to stress this point. If you can connect things through
hyperlinks rather than URI combinations then increasingly your "service
description" can be considered an outgrowth of your "vocabulary
description". I think of REST as pushing as much of the incompatibility
of the world down into the vocabulary description. Vocabularies *must*
vary (that's the whole point of XML). As we've demonstrated, method name
do NOT NEED to vary, so push the incompatibility OUT of the method names
and down into the markup.

> <http://www.markbaker.ca/> :wears <http://www.markbaker.ca/current-clothes/>

Mark uses RDF. I would typically use plain old xml.

<person>
  <clothes href="/current-clothes"/>
...
</person>

Of course the virtue of RDF is that it is easily done out-of-line but
IMO, out-of-line declarations are much harder to discover and maintain
(were it otherwise, XML markup itself would be out-of-line). So I would
say that out-of-line declarations are a fallback and inline I would
discriminate against RDF because I wouldn't want to add syntactic
complexity to my documents.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1107
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-27 23:11:42
Subject:Re: [rest-discuss] Autogenerating REST code: which format?
Message:

----- Original Message -----
From: "Mark Nottingham" <mnot@...>
>
> The idea is to play off of the similarities between objects and REST;
>
> instance -> resource (noun)
> method -> method (verb)
> parameters -> parameters / query
> return value -> representation
>
With HTTP the 'parameters' (query strings) aren't separate from the resource
identifier. It makes for a nice code framework though.
I built something with the same goals a number of years ago (with java in a
servlet environment) and found that the system of objects exposed tended to
be addressed purely through path segments and the parameters tended to be
negotiation things (I wasn't able to use actual headers, as I was operating
in a browser client environment) - for example I would put
"do:accept=text/xml" in a query term in order to request an xml
representation. I like the approach and encourage you to keep on going with
your coding.

The problem I found was that a lot of server environments didn't nicely
support using uri paths segments to acquire 'object request handlers' or
'resource instances'. Another problem was the expectations and attitudes of
the programmer community - putting everything into query terms is very
popular, because generating URIs is the standard way of doing things - but
hopefully this forum will help that issue.








-----------------------------------------------------------------------------------
Post ID:1108
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-27 23:40:53
Subject:Re: [rest-discuss] Re: Restifying Available to Promise
Message:

> Mark Baker wrote:
> >
> > I'm not sure I understand this "two name" problem.
> >
> > Any relationship between the two should be expressed as an assertion
> > someplace. e.g.
> >

I think my examples were not that great and caused some confusion.
The hyperlinking approaches seem to work, and my initial concern about
whether all parties would have the full URI or whether they would have only
a 'short name' isn't all that worrisome. If the publisher of a product
exposes the 'short name', then they could just as easily expose the full uri
(but if we can't get them to expose the full uri, what are we to do?).

The associations between resources still cause a well-known name to be
used - but it is truly a name like 'availability' and not a value like
'blueshoes'.

-- http://www.myinventory.foo/products/blueshoes/ --
<product>
<availability>http://www.myinventory.foo/products/blueshoes/availability/?wh
en=tomorrow</availability>
<!-- OR -->
<availability>http://www.myinventory.com/services/availablequantity?product=
http://www.myinventory.com/product/blueshoe&when=tomorrow</availability>
</product>

The hyperlinking approach lets the URIs be completely unrelated - they can
be 'path based' or 'service based' at the whim of the implementor. The
'coordinating interface' becomes the names used to extract the values from
the mass of xml (or rdf or whatever).

A question:
 - what kind of server implementation is required if the portion that emits
the 'product info' needs to know the full uri of the portion that deals with
'availability' (it doesn't of course have to be an absolute uri, but
whatever the uri looks like, all parts need to be aware of it)?
Is there a way to avoid this apparent tight coupling on addressing? Am I
missing something here?









-----------------------------------------------------------------------------------
Post ID:1109
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-04-27 23:51:23
Subject:Re: [rest-discuss] Autogenerating REST code: which format?
Message:

On Saturday, April 27, 2002, at 04:11  PM, S. Mike Dierken wrote:
>> instance -> resource (noun)
>> method -> method (verb)
>> parameters -> parameters / query
>> return value -> representation
>>
> With HTTP the 'parameters' (query strings)

and URI parameters!


>  aren't separate from the resource
> identifier. It makes for a nice code framework though.

Yes and no, IMHO. Mark went into this in his opacity investigations [1] 
a bit. 2396 says:

    The query component is a string of information to be interpreted by
    the resource.

To me, this indicates that the query has a dual role; it has some 
identifying properties in client systems, but the query component is 
also interpreted by the resource in server systems.


> The problem I found was that a lot of server environments didn't nicely
> support using uri paths segments to acquire 'object request handlers' or
> 'resource instances'.

True, although I think that by "a lot of server environments," you mean 
Java ;)
I haven't worked with ASP for a while; does it have the same problem? It 
certainly seems to encourage people to lump all of their code in one 
resource, resulting in abominations like

   
http://www.example.com/scripts/thingy.asp?page=/templates/marketing/fluff.
html

It would be interesting to do a survey of this (including Cold Fusion, 
PHP, etc.); I've done surveys [2] of content generation engines in the 
past, but my focus has been more on HTTP compliance rather than URI 
capabilities. This could probably be done by looking at documentation, 
rather than active testing.


> Another problem was the expectations and attitudes of
> the programmer community - putting everything into query terms is very
> popular, because generating URIs is the standard way of doing things - 
> but
> hopefully this forum will help that issue.

There's definitely been an interest in REST since the wars on www-tag et 
al started; I just wish they weren't quite so negative. However, if it 
does the trick...


Thanks!


1. http://www.markbaker.ca/2002/01/UriOpacityInvestigation/
2. http://www.mnot.net/papers/capabilities.html

--
Mark Nottingham
http://www.mnot.net/







-----------------------------------------------------------------------------------
Post ID:1110
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-28 01:07:30
Subject:Re: [rest-discuss] Autogenerating REST code: which format?
Message:

----- Original Message -----
From: "Mark Nottingham" <mnot@...>


>
> On Saturday, April 27, 2002, at 04:11  PM, S. Mike Dierken wrote:
> >> instance -> resource (noun)
> >> method -> method (verb)
> >> parameters -> parameters / query
> >> return value -> representation
> >>
> > With HTTP the 'parameters' (query strings)
>
> and URI parameters!
>
Yes, you are right - I'm not familiar with them, but I think I saw a posting
by RoyF or somebody that mentioned them. Pretty handy and I'd love to build
that into a server dispatching framework.

Sometimes my job gets in the way of the work I want to do...








-----------------------------------------------------------------------------------
Post ID:1111
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-04-28 01:19:39
Subject:XML vs RDF
Message:

On Sat, Apr 27, 2002 at 01:57:24PM -0700, Paul Prescod wrote:
> > <http://www.markbaker.ca/> :wears <http://www.markbaker.ca/current-clothes/>
> 
> Mark uses RDF. I would typically use plain old xml.
> 
> <person>
>   <clothes href="/current-clothes"/>
> ...
> </person>
> 
> Of course the virtue of RDF is that it is easily done out-of-line but
> IMO, out-of-line declarations are much harder to discover and maintain
> (were it otherwise, XML markup itself would be out-of-line). So I would
> say that out-of-line declarations are a fallback and inline I would
> discriminate against RDF because I wouldn't want to add syntactic
> complexity to my documents.

I think in-line vs. out-of-line is a red herring.  The RDF model can be
serialized into many syntaxes to make in-line integration easier.

What RDF provides is a generalized assertion model.  That means that an
RDF client can build up an understanding of a piece of representational
state in an incremental manner, rather than the all-or-nothing approach
of XML, where you either do or do not understand a schema.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1112
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-04-28 01:21:58
Subject:Re: [rest-discuss] Autogenerating REST code: which format?
Message:

From: "Mark Nottingham" <mnot@...>

> > The problem I found was that a lot of server environments didn't nicely
> > support using uri paths segments to acquire 'object request handlers' or
> > 'resource instances'.
>
> True, although I think that by "a lot of server environments," you mean
> Java ;)
> I haven't worked with ASP for a while; does it have the same problem? It
> certainly seems to encourage people to lump all of their code in one
> resource, resulting in abominations like
>
> http://www.example.com/scripts/thingy.asp?page=/templates/marketing/fluff.
> html

The problem isn't ASP, it's IIS. It doesn't have any convenient means of
doing URL rewriting the way that Apache does which is extremely unfortunate.

By the way, I've been working on generating code for C# (and the other .NET
languages) for RESTful-like web services. I started using Paul's WRDL as the
specification language but have since simplified it so that it's easier for
one person (me) to tackle. I might be able to release some working examples
pretty soon if anybody's interested.

Jason








-----------------------------------------------------------------------------------
Post ID:1113
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-04-28 03:45:57
Subject:RSDL
Message:

I've just uploaded my WRDL-inspired code generator for .NET [1]. I'm calling
it RSDL to avoid any confusion with WRDL. I'm releasing it in the interest
of experimentation and discussion not competition. Hopefully something cool
will come of it.

I've found that it's great for generating RPC-like proxies that only use
URIs and HTTP. This isn't exactly the REST Way (and I belive that Mark Baker
commented on this a while back) but I'm hoping that it proves more useful as
more features are added. I think that using the generated bindings for
representations will be especally eye-opening once that's achieved.

My next goal is to get it to generate proxies that can work with all three
of Paul's Google API operations. After that, there's generating server
proxies, support for other target languagues, multiple schema languages, and
probably more.

Fun stuff, all of it. :-)

Jason

[1]
http://radio.weblogs.com/0101391/2002/04/27.html#a14








-----------------------------------------------------------------------------------
Post ID:1114
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-28 03:58:09
Subject:Re: [rest-discuss] Autogenerating REST code: which format?
Message:

>
> The problem isn't ASP, it's IIS. It doesn't have any convenient means of
> doing URL rewriting the way that Apache does which is extremely
unfortunate.

I don't know much about IIS, but I don't think I was successful with ASP
page of the form:
 http://www.example.org/path/service.asp/sub-path/

It didn't seem to support 'extra path info'. Whatever.







-----------------------------------------------------------------------------------
Post ID:1115
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-04-28 04:03:47
Subject:Re: [rest-discuss] Autogenerating REST code: which format?
Message:

> I don't know much about IIS, but I don't think I was successful with ASP
> page of the form:
> http://www.example.org/path/service.asp/sub-path/
>
> It didn't seem to support 'extra path info'. Whatever.

I didn't have to start using IIS until version 5 so maybe it didn't before.
But it does now. The HttpRequest class has a PathInfo property. The problem
(to me) is the ".asp" in the middle of the path. IIS uses extensions (and
only extensions) to route requests to the appropriate ISAPI DLL. Is it just
me or doesn't it seem like Microsoft is afraid of regular expressions?

Jason








-----------------------------------------------------------------------------------
Post ID:1116
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-28 04:42:19
Subject:Re: [rest-discuss] Autogenerating REST code: which format?
Message:

> I didn't have to start using IIS until version 5 so maybe it didn't
before.
> But it does now. The HttpRequest class has a PathInfo property. The
problem
> (to me) is the ".asp" in the middle of the path. IIS uses extensions (and
> only extensions) to route requests to the appropriate ISAPI DLL. Is it
just
> me or doesn't it seem like Microsoft is afraid of regular expressions?
Yeah - Sun did the same thing with JSP. It used to work, then it didn't. I
might be able to get pathInfo() to work in a JSP if I re-map the URI for the
JSP into a servlet (or something) via the config file for that application -
but I hate digging through config file formats.








-----------------------------------------------------------------------------------
Post ID:1117
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-28 04:56:27
Subject:Re: [rest-discuss] RSDL
Message:

Does this generate client side code only? I only looked at it briefly.

I like it though - especially the part that maps client API methods into
HTTP methods - it bridges the two worlds where programmers want it their
custom way dammit but the architecture wants it a common way or else.

Ultimately I'd like to see a declarative mapping between API constructs and
HTTP messages - the full message with headers, etc available.

Something like the following (but I haven't figured out how to tie API parts
into request-message parts):

<!-- http request definition -->
<requestDef id='AddRequest'>
 <http:method>GET</http:method>
 <http:Accept>text/xml</http:Accept>
 </request>

<!-- standard method/paramter definition stuff -->
<class name='XmlAdder'>
<operation request='AddRequest'>
 <name>Add</name>
 <param></param>
</operation>
</class>

<!-- sample -->
 var adder=new XmlAdder(uri);
 adder.Add(5,7);


PS
Take a look at http://xml.apache.org/xang/ for some server side stuff if you
like Java and servlet environments. It has a dispatching framework in there
that uses something like the following (the dispatch() was implemented with
a base class that used reflection to invoke the actual java method):

public interface IHTTPObject
{
    // child objects
    public IHTTPObject getChild(Vector idPath,int startingOffset);
    public void releaseChild(IHTTPObject child);

    // method invocation
    public boolean dispatch(IHTTPContext context,Vector returnTypes,String
method,Hashtable parameters);
}







-----------------------------------------------------------------------------------
Post ID:1118
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-28 08:03:30
Subject:Re: XML vs RDF
Message:

Mark Baker wrote:
> 
>....
> 
> I think in-line vs. out-of-line is a red herring.  The RDF model can be
> serialized into many syntaxes to make in-line integration easier.

Yes, that's of course true. Here is why I think of it as in-line versus
out-of-line: I am an XML person and I think that syntax matters. One of
my complaints about SOAP is that it (and XLink, for that matter) is that
it introduces a foreign syntax into XML vocabularies and thus makes them
harder to teach and learn. That impacts their adoption characteristics.

Out-of-line, I can stand RDF's syntax because that is really what it is
optimized for: pointing into resources and making assertions about them.
But inline, I can hardly imagine ever doing this:

<rdf:RDF>
  <rdf:Description about="#">
    <s:Creator>Ora Lassila</s:Creator>
  </rdf:Description>
</rdf:RDF>

Rather than:

<Creator>Ora Lassila</Creator>

I think that this sort of disagreement was behind the RSS conflict and
branch.

Likely the right way to merge the worlds is to have a sort of RDF
stylesheet which maps from XML into the RDF model. I would associate
that with my document through a processing instruction. I believe the
FourThought guys were working on such a technique.

> What RDF provides is a generalized assertion model.  That means that an
> RDF client can build up an understanding of a piece of representational
> state in an incremental manner, rather than the all-or-nothing approach
> of XML, where you either do or do not understand a schema.

That's certainly valuable but in my personal opinion, most XML users
will not be willing to pay the price of designing their vocabularies
specifically for RDF compatibility.  For instance I much prefer the
syntax of the real WSDL to the one outlined here:

 * http://www-106.ibm.com/developerworks/library/ws-rdf/

For one thing, the idea of making one of the top-most elements "rdf:RDF"
rather goes against the design of almost every XML schema language I've
ever seen.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1119
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-28 08:10:25
Subject:Re: [rest-discuss] RSDL
Message:

Jason, if you're intending to do a Java implementation, you might
consider killing two birds with one stone.

RSDL seems like a very nice, clean, simple subset of WSDL functionality.
One way you could implement the Java binding is to implement WSDL/HTTP
support for Axis (which is something I'd really love to have done) and
then implement a simple RSDL->WSDL compiler.

One benefit of doing it this way is that you could build on all of the
nice type binding features in AXIS's WSDL engine.

Of course I think the REST crowd needs its own languages but I've come
to the realization that even with its limitations, WSDL's HTTP binding
is about as powerful (in some ways more powerful) then its SOAP
bindings. So we could win people incrementally to REST through it. I
think that once they've given up their SOAP safety blanket they will be
more open to new architectural ideas.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1120
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-28 11:26:39
Subject:Business protocols
Message:

"S. Mike Dierken" wrote:
> my initial concern about
> whether all parties would have the full URI or whether they would 
have only
> a 'short name' isn't all that worrisome. If the publisher of a 
product
> exposes the 'short name', then they could just as easily expose the 
full uri
> (but if we can't get them to expose the full uri, what are we to 
do?).
> 
> The associations between resources still cause a well-known name to 
be
> used - but it is truly a name like 'availability' and not a value 
like
> 'blueshoes'.

The most common way for companies that engage in B2B electronic 
commerce to communicate product information is by publishing a 
catalog.  It's common for customers to subscribe to the catalog and 
get periodic updates.  The catalog will have URIs for each product.

I expect something like 'Business Protocols" to become available soon.

By "Business Protocols", I mean the scripts for getting catalogs, 
availability, ordering, claims, delivery and payment notifications, 
warranty service, etc.

Many of those protocols will become available from libraries from 
standards groups and industry and trade associations.  So "Business 
Protocols" might be a reference or a list of references to the common 
protocols a company can handle.

So the first thing to do when you want to do business with a new 
trading partner is to get their business protocols.

There is a catalog of common business processes here:
http://www.ebxml.org/specs/bpPROC.pdf 

It contains categorized lists of business processes from EDI, 
RosettaNet, OAG, etc.  Not much detail, just lists.

Work is continuing on this catalog - adding more groups, including 
international trade processes.  Executable international trade 
protocols will open the gates for many people who cannot engage in 
trade now because of the difficulties of the processes.

Scripts for executable business processes are being developed in 
UN/CEFACT and ISO and several other organizations.  For the most 
part, the scripts assume something like the EDI-mailbox Web service 
pattern.  However, both UN/CEFACT and ISO are trying to be technology-
independent, and so their process models should be able to be 
implemented in REST, at least via some twists.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1121
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-28 18:06:52
Subject:Re: [rest-discuss] RSDL
Message:

----- Original Message ----- 
From: "Paul Prescod" <paul@...>

> I think that once they've given up their SOAP safety blanket they will be
> more open to new architectural ideas.
SOAP == "security blanket" ... I love it...







-----------------------------------------------------------------------------------
Post ID:1122
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-28 18:13:52
Subject:Re: [rest-discuss] Business protocols
Message:

----- Original Message -----
From: "bhaugen32" <bhaugen32@...>

>
> The most common way for companies that engage in B2B electronic
> commerce to communicate product information is by publishing a
> catalog.  It's common for customers to subscribe to the catalog and
> get periodic updates.  The catalog will have URIs for each product.

Something that I've run into is that (product) catalogs sometimes have
pricing embedded within the catalog - which causes the catalog to be unique
to individual receivers - vendors don't have or want uniform pricing across
customers. If their process cannot 'normalize' out this information into
separate pricing documents then you get a huge amount of mostly redundant
information across the system as a whole. And when it gets this big - 60GB
per week for 10K customers lets say - then vendors feel they need batch
operations, scheduled updates, etc. leading away from a more
real-time/low-latency/event-driven message flow.

>
> I expect something like 'Business Protocols" to become available soon.
>
I agree with you. I think they will evolve from the coalescing of pockets of
use, rather than from standardization organizations though.






-----------------------------------------------------------------------------------
Post ID:1123
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-04-28 20:11:29
Subject:Re: [rest-discuss] RSDL
Message:

From: "S. Mike Dierken" <mdierken@...>
> Does this generate client side code only? I only looked at it briefly.

Yes, it only generates client proxies at the moment. I have some
experimental code working that makes it easy to write a server. It uses
reflection to invoke the appropriate methods. I didn't include it in the
distribution because I don't really think it's that elegant yet.

> I like it though - especially the part that maps client API methods into
> HTTP methods - it bridges the two worlds where programmers want it their
> custom way dammit but the architecture wants it a common way or else.
>
> Ultimately I'd like to see a declarative mapping between API constructs
and
> HTTP messages - the full message with headers, etc available.

I was thinking about something like this for the simple reason that query or
header names in HTTP can be illegal in the language you're binding to. WRDL
has an apiName attribute but I thought that maybe it could be possible to
have some sort of configuration file that does the mapping on a per language
basis. I really don't want to tie RSDL to any particular methodology (line
OO) so I imagine that these configuration files would be on a per tool
basis.

Jason








-----------------------------------------------------------------------------------
Post ID:1124
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-04-29 07:22:38
Subject:XSLT2
Message:

Interestingly, XSLT2 allows you to specify a URI to write output 
documents to [1]. The WD goes to some pains to say that implementations 
can choose how to support (or not) different schemes, etc.

It would be *nice* if it highlighted (or even made a requirement for 
conditional compliance) support for HTTP through PUT, lest the only 
support be for file:


1. http://www.w3.org/TR/xslt20/#element-destination

--
Mark Nottingham
http://www.mnot.net/







-----------------------------------------------------------------------------------
Post ID:1125
Sender:Uche Ogbuji <uche.ogbuji@...>
Post Date/Time:2002-04-29 07:13:43
Subject:Re: XML vs RDF
Message:

On Sun, 2002-04-28 at 02:03, Paul Prescod wrote:
> Mark Baker wrote:
> > 
> >....
> > 
> > I think in-line vs. out-of-line is a red herring.  The RDF model can be
> > serialized into many syntaxes to make in-line integration easier.
> 
> Yes, that's of course true. Here is why I think of it as in-line versus
> out-of-line: I am an XML person and I think that syntax matters. One of
> my complaints about SOAP is that it (and XLink, for that matter) is that
> it introduces a foreign syntax into XML vocabularies and thus makes them
> harder to teach and learn. That impacts their adoption characteristics.
> 
> Out-of-line, I can stand RDF's syntax because that is really what it is
> optimized for: pointing into resources and making assertions about them.
> But inline, I can hardly imagine ever doing this:
> 
> <rdf:RDF>
>   <rdf:Description about="#">
>     <s:Creator>Ora Lassila</s:Creator>
>   </rdf:Description>
> </rdf:RDF>
> 
> Rather than:
> 
> <Creator>Ora Lassila</Creator>
> 
> I think that this sort of disagreement was behind the RSS conflict and
> branch.
> 
> Likely the right way to merge the worlds is to have a sort of RDF
> stylesheet which maps from XML into the RDF model. I would associate
> that with my document through a processing instruction. I believe the
> FourThought guys were working on such a technique.
> 
> > What RDF provides is a generalized assertion model.  That means that an
> > RDF client can build up an understanding of a piece of representational
> > state in an incremental manner, rather than the all-or-nothing approach
> > of XML, where you either do or do not understand a schema.
> 
> That's certainly valuable but in my personal opinion, most XML users
> will not be willing to pay the price of designing their vocabularies
> specifically for RDF compatibility.  For instance I much prefer the
> syntax of the real WSDL to the one outlined here:
> 
>  * http://www-106.ibm.com/developerworks/library/ws-rdf/

Quite dated, this is.  I wrote it back in 2000, before I came to the
same conclusion as you have: that it's more important to have mapping
features from XML to RDF than to squeeze everything into RDF syntax.


> For one thing, the idea of making one of the top-most elements "rdf:RDF"
> rather goes against the design of almost every XML schema language I've
> ever seen.

You might, then, want to check out the updated article:

http://www-106.ibm.com/developerworks/webservices/library/ws-wsdlrdf/

Unfortunately, there is a bug in this article I've reported to the
editor.  An XInclude I used did not get expanded.  You'll know what I
mean if you read the article.  If so, here's the link you want:

http://localhost:8080/uche.ogbuji.net/tech/rdf/ws/endorsement-services-020327.txt

Might I also suggest my similar discussion WRT SOAP:

http://www-106.ibm.com/developerworks/webservices/library/ws-soaprdf/


-- 
Uche Ogbuji                           Fourthought, Inc.
uche.ogbuji@...           http://fourthought.com
http://4Suite.org                     http://uche.ogbuji.net
Track chair, XML/Web Services One (San Jose, Boston):
http://www.xmlconference.com/
RDF Query using Versa -
http://www-106.ibm.com/developerworks/xml/library/x-think10/index.html
WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004
XML, The Model Driven Architecture, and RDF @ XML Europe -
http://www.xmleurope.com/2002/kttrack.asp#themodel







-----------------------------------------------------------------------------------
Post ID:1126
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-29 11:43:49
Subject:Re: Business protocols
Message:

"S. Mike Dierken" wrote:
> Something that I've run into is that (product) catalogs sometimes 
have
> pricing embedded within the catalog - which causes the catalog to 
be unique
> to individual receivers - vendors don't have or want uniform 
pricing across
> customers. If their process cannot 'normalize' out this information 
into
> separate pricing documents then you get a huge amount of mostly 
redundant
> information across the system as a whole. 

An excellent point.  Have you seen anybody do this normalization?  
How did it work out?

> > I expect something like 'Business Protocols" to become available 
soon.
> >
> I agree with you. I think they will evolve from the coalescing of 
pockets of
> use, rather than from standardization organizations though.

I expect both of us are right.  Here is some of my evidence for 
organizations working on common business protocols:
* RosettaNet - electronics
* CIDX, chemical, adopted a lot of RNet
* PIDX, petroleum, adopting CIDX
* agXML, agriculture, adopting CIDX
* ebXML - took lots of ideas from RNet
* RNet now adopting at least some of ebXML
* AIAG, automotive, has previous X12 EDI standards, now adopting ebXML
* HIPAA, health care, US government mandate
* Travel (org?), adopting some of ebXML and also their own standards
* UCC, retail, somewhat like travel
* Telecom (org?), precursor to some of RNet

One point being that there is a lot of overlap and cross-referencing 
between orgs.  And whole bodies of commercial law and business 
customs underly all of these protocols.  Many of these people do 
understand that "code rules" and so are attempting to codify legal 
business practices.

And then some big companies like McDonalds and Walmart constitute 
their own little universes...

Another point being that you could make up your own business 
protocols, but be aware you are planting in a field where a big gang 
plow is coming. It won't be as neat as the standards and industry 
orgs and big companies like, but in many cases, you will be required 
to follow some standardized protocol in order to do business.







-----------------------------------------------------------------------------------
Post ID:1127
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-04-29 16:27:19
Subject:Re: [rest-discuss] Re: XML vs RDF
Message:

On Sun, Apr 28, 2002 at 01:03:30AM -0700, Paul Prescod wrote:
> Yes, that's of course true. Here is why I think of it as in-line versus
> out-of-line: I am an XML person and I think that syntax matters.

I think syntax matters too.  That's why I'm not an XML person. 8-)

> One of
> my complaints about SOAP is that it (and XLink, for that matter) is that
> it introduces a foreign syntax into XML vocabularies and thus makes them
> harder to teach and learn. That impacts their adoption characteristics.
> 
> Out-of-line, I can stand RDF's syntax because that is really what it is
> optimized for: pointing into resources and making assertions about them.
> But inline, I can hardly imagine ever doing this:
> 
> <rdf:RDF>
>   <rdf:Description about="#">
>     <s:Creator>Ora Lassila</s:Creator>
>   </rdf:Description>
> </rdf:RDF>
> 
> Rather than:
> 
> <Creator>Ora Lassila</Creator>

Sure, but there's more information available in the former case.  If the
XML is going to be processed by a machine anyways, why is the latter
approach any better?  I suppose if it were hand authored, but is that
what we're talking about here?

Also, I think the XML syntax for the RDF model is a horrible, nasty,
unnecessary thing.  It should be killed.

> I think that this sort of disagreement was behind the RSS conflict and
> branch.
> 
> Likely the right way to merge the worlds is to have a sort of RDF
> stylesheet which maps from XML into the RDF model. I would associate
> that with my document through a processing instruction. I believe the
> FourThought guys were working on such a technique.

I've heard talk of adorning schemas with the information necessary to
construct RDF.  I like this in theory, though I fear for the practical
implications; primarily, additional network round-trips.

> > What RDF provides is a generalized assertion model.  That means that an
> > RDF client can build up an understanding of a piece of representational
> > state in an incremental manner, rather than the all-or-nothing approach
> > of XML, where you either do or do not understand a schema.
> 
> That's certainly valuable but in my personal opinion, most XML users
> will not be willing to pay the price of designing their vocabularies
> specifically for RDF compatibility.

For now, that's clearly true.  As more RDF features are integrated into
tools, the cost of doing this will come down.

> For one thing, the idea of making one of the top-most elements "rdf:RDF"
> rather goes against the design of almost every XML schema language I've
> ever seen.

True, but I consider XML schema and other languages at that level, to be
transitional technologies.  rdf:RDF (or something equivalent) will the
be the root element for a whole lot of content in a few years.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1128
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-29 16:42:21
Subject:Re: XML vs RDF
Message:

Uche Ogbuji wrote:
> 
>...
> You might, then, want to check out the updated article:
> 
> http://www-106.ibm.com/developerworks/webservices/library/ws-wsdlrdf/
> 
> Unfortunately, there is a bug in this article I've reported to the
> editor.  An XInclude I used did not get expanded.  You'll know what I
> mean if you read the article.  

Yeah, it seems as if you're making some kind of joke. Look: it's only
one line!

If so, here's the link you want:

> http://localhost:8080/uche.ogbuji.net/tech/rdf/ws/endorsement-services-020327.txt

Typo in that URI (localhost) but I figured it out. Still doesn't really
meet my requirements so I'll wait for more information on "document
definitions" or whatever else you are working on. For instance the root
namespace in this document is rdf:RDF which is not going to be
acceptable to XML people!

Maybe I'm unreasonable, but I'm looking for the total content of the RDF
stuff in my document to be:

<?rdf-metadata-mapping href=""?>

I would even be satisfied to put the RDF stuff in my XML or RELAX
schema.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1129
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-29 16:48:22
Subject:XML Spaces - another implementation of REST over networks?
Message:

There are a lot of interesting presentations at that XML Europe convention
(from a link from your mail)

This one looks interesting, as it might be an additional implementation of
the REST architectural style:

Thursday, 23 May
11.00
Technical View
XML Spaces - Beyond Web Services
Presented by: Patrick Thompson, Chief Architect, Rogue Wave Software, United
States
XML Spaces is a new communication paradigm that brings together tuple
spaces, XML, the Internet, security, and web services to create a simple yet
powerful substrate for rich document exchange. XML Spaces extends the web
services model with looser coupling, abstract addressing, asynchrony,
arbitrary XML support, many-to-many interactions and document level
security. XML Spaces supports ad-hoc collaboration seamlessly within an
organization or across the Internet. The presenter will introduce the
technology and describe how it can be applied to a wide variety of
applications.


----- Original Message -----
From: "Uche Ogbuji" <uche.ogbuji@...>

> XML, The Model Driven Architecture, and RDF @ XML Europe -
> http://www.xmleurope.com/2002/kttrack.asp#themodel
>







-----------------------------------------------------------------------------------
Post ID:1130
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-04-29 18:57:10
Subject:Re: [rest-discuss] XML Spaces - another implementation of REST over networks?
Message:

On Mon, Apr 29, 2002 at 09:48:22AM -0700, S. Mike Dierken wrote:
> This one looks interesting, as it might be an additional implementation of
> the REST architectural style:

Well, I think it's a huge stretch to claim that a tuple space
architecture is REST.  There are definitely some similarities between
the two styles, including the biggies (generic interface, operates on
things with identity), but there's a lot of important differences.
Stuff like definition of identity not very general, focus on APIs
instead of protocols (so no streams), etc..

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1131
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-29 20:03:46
Subject:Re: [rest-discuss] XSLT2
Message:

Mark Nottingham wrote:
> 
> Interestingly, XSLT2 allows you to specify a URI to write output
> documents to [1]. The WD goes to some pains to say that implementations
> can choose how to support (or not) different schemes, etc.
> 
> It would be *nice* if it highlighted (or even made a requirement for
> conditional compliance) support for HTTP through PUT, lest the only
> support be for file:

That's an excellent idea! Do you want to contact Michael Kay or should I
or what?

What should be done about POST? If we need to choose just one of the
two, POST is actually more compatible with deployed infrastructure
though PUT is more inline with "overwrite" semantics.

Pragmatically I would have to go with POST.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1132
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-04-29 20:19:27
Subject:Re: [rest-discuss] XSLT2
Message:

On Mon, Apr 29, 2002 at 01:03:46PM -0700, Paul Prescod wrote:
> What should be done about POST? If we need to choose just one of the
> two, POST is actually more compatible with deployed infrastructure
> though PUT is more inline with "overwrite" semantics.
> 
> Pragmatically I would have to go with POST.

The operation is semantically identical to PUT, so why use POST?
There's idempotence issues too, of course; a script author
expects overwrite, so they should get it.

MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1133
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-04-29 20:20:57
Subject:Fwd: [rest-discuss] XSLT2
Message:

This time, including the group.

Begin forwarded message:

From: Mark Nottingham <mnot@...>
Date: Mon Apr 29, 2002  01:20:04  PM US/Pacific
To: Paul Prescod <paul@...>
Subject: Re: [rest-discuss] XSLT2

I'll be happy to if we can come to some sort of consensus here.

Is PUT really that much of an issue? The only issue that I can see is 
that in some situations, it may be easier to drop in a CGI POST hander 
that allows you to direct the result to a particular location; PUT 
requires some sort of handler on the server side (e.g., a module or a 
script that stores and retrieves the state).

I'd much rather see PUT used, as I think it's a good way to broaden 
support for full PUT/DELETE, but I can certainly see that there would be 
initial pushback.  Does anyone know if it's possible, and how difficult 
it is, to support PUT on ISS (any version)?

I'd say support both, but that would require an attribute to select the 
method.


On Monday, April 29, 2002, at 01:03  PM, Paul Prescod wrote:

> Mark Nottingham wrote:
>>
>> Interestingly, XSLT2 allows you to specify a URI to write output
>> documents to [1]. The WD goes to some pains to say that implementations
>> can choose how to support (or not) different schemes, etc.
>>
>> It would be *nice* if it highlighted (or even made a requirement for
>> conditional compliance) support for HTTP through PUT, lest the only
>> support be for file:
>
> That's an excellent idea! Do you want to contact Michael Kay or should I
> or what?
>
> What should be done about POST? If we need to choose just one of the
> two, POST is actually more compatible with deployed infrastructure
> though PUT is more inline with "overwrite" semantics.
>
> Pragmatically I would have to go with POST.
>
>  Paul Prescod
>
--
Mark Nottingham
http://www.mnot.net/







-----------------------------------------------------------------------------------
Post ID:1134
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-29 20:24:03
Subject:Re: [rest-discuss] XSLT2
Message:

Mark Baker wrote:
> 
>...
> 
> The operation is semantically identical to PUT, so why use POST?
> There's idempotence issues too, of course; a script author
> expects overwrite, so they should get it.

I agree that PUT is the right thing semantically. The only reason I
consider POST is because if a person designs a web service without
specifically taking into a account either REST or XSLT that service is
likely to accept POST, not PUT. PUT isn't supported by either HTML or
WSDL, so the GET/POST have become a popular pair!

I suppose I would still end up going over to the PUT side because if
XSLT will just ignore the result of the POST then it will be
incompatible with may POST-based services anyhow.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1135
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-04-29 20:08:35
Subject:Re: [rest-discuss] XSLT2
Message:

Why not suggest a method attribute for the xsl:result-document element? Then
you could use either one.

Jason

----- Original Message -----
From: "Paul Prescod" <paul@...>
To: "Mark Nottingham" <mnot@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Monday, April 29, 2002 1:03 PM
Subject: Re: [rest-discuss] XSLT2


> Mark Nottingham wrote:
> >
> > Interestingly, XSLT2 allows you to specify a URI to write output
> > documents to [1]. The WD goes to some pains to say that implementations
> > can choose how to support (or not) different schemes, etc.
> >
> > It would be *nice* if it highlighted (or even made a requirement for
> > conditional compliance) support for HTTP through PUT, lest the only
> > support be for file:
>
> That's an excellent idea! Do you want to contact Michael Kay or should I
> or what?
>
> What should be done about POST? If we need to choose just one of the
> two, POST is actually more compatible with deployed infrastructure
> though PUT is more inline with "overwrite" semantics.
>
> Pragmatically I would have to go with POST.
>
> Paul Prescod
>
>       Yahoo! Groups Sponsor
>             ADVERTISEMENT
>
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>







-----------------------------------------------------------------------------------
Post ID:1136
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-04-29 20:40:03
Subject:Re: Fwd: [rest-discuss] XSLT2
Message:

On Mon, Apr 29, 2002 at 01:20:57PM -0700, Mark Nottingham wrote:
> I'd say support both, but that would require an attribute to select the 
> method.

Using POST is entirely different function.  You're no longer producing
a document, you're producing a message.  I'm not convinced that a POST
mechanism is desirable, but if somebody wants to suggest that, I'd
*STRONGLY* recommend defining a new element, not an attribute on
xsl:result-document.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1137
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-04-29 20:44:58
Subject:Re: [rest-discuss] XSLT2
Message:

Ah, but that's the interesting part - this is an argument for both PUT 
and POST support, with POST using a separate element (as Mark suggests); 
it allows you to represent the result of the POST in the XSLT for 
further processing; you might get XML back, which can be represented 
(bad word to use) as a result tree, you might get back a URI for a 
Content-Location, etc.

This would allow you to do some pretty sophisticated coordination with 
XSLT...


P.S. There should really be a REST IRC channel...



On Monday, April 29, 2002, at 01:24  PM, Paul Prescod wrote:

> Mark Baker wrote:
>>
>> ...
>>
>> The operation is semantically identical to PUT, so why use POST?
>> There's idempotence issues too, of course; a script author
>> expects overwrite, so they should get it.
>
> I agree that PUT is the right thing semantically. The only reason I
> consider POST is because if a person designs a web service without
> specifically taking into a account either REST or XSLT that service is
> likely to accept POST, not PUT. PUT isn't supported by either HTML or
> WSDL, so the GET/POST have become a popular pair!
>
> I suppose I would still end up going over to the PUT side because if
> XSLT will just ignore the result of the POST then it will be
> incompatible with may POST-based services anyhow.
>
>  Paul Prescod
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/
>
>
>
--
Mark Nottingham
http://www.mnot.net/







-----------------------------------------------------------------------------------
Post ID:1138
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-04-29 20:35:55
Subject:XSLT2.0 and HTTP-PUT
Message:

XSLT2 allows you to specify a URI to write output  documents to [1]. The 
current WD goes to some pains to say that implementations  can choose 
how to support (or not) different schemes, etc.

However, considering recent discussion on www-tag re: REST, the Web, 
interoperability, etc., it would be nice if it highlighted (or even made 
a requirement for conditional compliance) support for HTTP through PUT, 
lest the only
support be for "file" URIs.

Has this been discussed in the WG?

Regards,


1. http://www.w3.org/TR/xslt20/#element-destination

--
Mark Nottingham
http://www.mnot.net/







-----------------------------------------------------------------------------------
Post ID:1139
Sender:Mark Nottingham <mnot@...>
Post Date/Time:2002-04-29 20:36:51
Subject:Re: [rest-discuss] XSLT2
Message:

That makes sense. Let's see what they come back with.


On Monday, April 29, 2002, at 01:40  PM, Mark Baker wrote:

> On Mon, Apr 29, 2002 at 01:20:57PM -0700, Mark Nottingham wrote:
>> I'd say support both, but that would require an attribute to select the
>> method.
>
> Using POST is entirely different function.  You're no longer producing
> a document, you're producing a message.  I'm not convinced that a POST
> mechanism is desirable, but if somebody wants to suggest that, I'd
> *STRONGLY* recommend defining a new element, not an attribute on
> xsl:result-document.
>
> MB
> --
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@...
> http://www.markbaker.ca   http://www.planetfred.com
>
--
Mark Nottingham
http://www.mnot.net/







-----------------------------------------------------------------------------------
Post ID:1140
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-29 21:25:28
Subject:Re: [rest-discuss] XSLT2
Message:

Mark Nottingham wrote:
> 
> Ah, but that's the interesting part - this is an argument for both PUT
> and POST support, with POST using a separate element (as Mark suggests);

Now we're talking about going from saying: "please support HTTP" to
"please add these HTTP-specific features to the language". I don't think
it would fly. Maybe if we asked them to "please support SOAP over HTTP
POST in XSLT." ;)

I'm pretty sure IIS supports PUT. The method name is just a paramater on
the "HttpRequest" object, otherwise it doesn't care much. One small
issue is that the default security configuration probably allows
GET,POST, not GET,PUT,POST.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1141
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-30 03:03:55
Subject:Re: [rest-discuss] XML Spaces - another implementation of REST over networks?
Message:

Okay - you are probably right. I don't know what a tuple space is - I've
only read one paper from RogueWave's site - but several times people have
compared HTTP/REST with tuple spaces... so I thought it relevant. I didn't
mean to categorically claim tuplespaces === REST.




----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "S. Mike Dierken" <mdierken@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Monday, April 29, 2002 11:57 AM
Subject: Re: [rest-discuss] XML Spaces - another implementation of REST over
networks?


> On Mon, Apr 29, 2002 at 09:48:22AM -0700, S. Mike Dierken wrote:
> > This one looks interesting, as it might be an additional implementation
of
> > the REST architectural style:
>
> Well, I think it's a huge stretch to claim that a tuple space
> architecture is REST.  There are definitely some similarities between
> the two styles, including the biggies (generic interface, operates on
> things with identity), but there's a lot of important differences.
> Stuff like definition of identity not very general, focus on APIs
> instead of protocols (so no streams), etc..
>
> MB
> --
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@...
> http://www.markbaker.ca   http://www.planetfred.com
>






-----------------------------------------------------------------------------------
Post ID:1142
Sender:"jmay" <jmay@...>
Post Date/Time:2002-04-30 04:19:38
Subject:REST
Message:

Sjoerd Visscher suggests (at 
http://w3future.com/weblog/2002/04/30.html#a93) that "REST violates a 
lot of rules of both functional and object oriented programming", 
because it has "a small API" (presumably referring to GET, POST, PUT 
as the REST API).

I'm not convinced that REST's reliance on HTTP primitives  
necessarily restricts flexibility of function.  I'd really like to 
see an example of something useful that can be expressed in SOAP 
style much more clearly than in REST style.

-Jason







-----------------------------------------------------------------------------------
Post ID:1143
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-04-30 10:56:18
Subject:RE: [rest-discuss] XML Spaces - another implementation of REST over networks?
Message:

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


- ----- Original Message -----
From: "Mark Baker" <distobj@...>
>
> Well, I think it's a huge stretch to claim that a tuple space
> architecture is REST.  There are definitely some similarities
> between the two styles, including the biggies (generic interface,
> operates on things with identity), but there's a lot of important
> differences. Stuff like definition of identity not very general,
> focus on APIs instead of protocols (so no streams), etc..
 
Mark, what did you mean by no streams in tuplespaces?

Bill de hra

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPM54UeaWiFwg2CH4EQKn5ACg2NkH9mpqOK0uKMhs3GZh5wYwSTEAnivn
Aa1A5mgPL8TwT5twKRabBcUd
=3C6i
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:1144
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-04-30 11:20:13
Subject:Re: [rest-discuss] REST
Message:

On Tue, Apr 30, 2002 at 04:19:38AM -0000, jmay wrote:
> Sjoerd Visscher suggests (at 
> http://w3future.com/weblog/2002/04/30.html#a93) that "REST violates a 
> lot of rules of both functional and object oriented programming", 
> because it has "a small API" (presumably referring to GET, POST, PUT 
> as the REST API).

Yah, I saw that.  I have my own opinions on that claim, but really,
my response is "So what?".  The criteria with which one evaluates a
distributed architecture is *entirely* different than the criteria
with which a software program is evaluated.

> I'm not convinced that REST's reliance on HTTP primitives  

Isn't that the other way around? 8-)

> necessarily restricts flexibility of function.  I'd really like to 
> see an example of something useful that can be expressed in SOAP 
> style much more clearly than in REST style.

You and me both!

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1145
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-04-30 11:42:48
Subject:Re: [rest-discuss] XML Spaces - another implementation of REST over networks?
Message:

On Tue, Apr 30, 2002 at 11:56:18AM +0100, Bill de h�ra wrote:
> Mark, what did you mean by no streams in tuplespaces?

That a tuple is of fixed size.  So you can't use a space to identify a
large number resources whose representations can be streams.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1146
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-04-30 11:52:56
Subject:RE: [rest-discuss] XML Spaces - another implementation of REST over networks?
Message:

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> -----Original Message-----
> From: Mark Baker [mailto:distobj@...] 
>
> On Tue, Apr 30, 2002 at 11:56:18AM +0100, Bill de hra wrote:
> > Mark, what did you mean by no streams in tuplespaces?
> 
> That a tuple is of fixed size.  So you can't use a space to 
> identify a large number resources whose representations can 
> be streams.

Thanks Mark, I may get back you about this, I take your point for
now. (I'm surprised you could even read my post; convert to html
dutifully turned off)

Bill de hra

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPM6FluaWiFwg2CH4EQKocgCggmf/LGB53NFTWq7kQpT86Z04jgUAniOX
aYERlD+EkGKxEup4mK+izoUd
=8Z6x
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:1147
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-04-30 14:01:02
Subject:Re: [rest-discuss] REST
Message:

On Mon, 2002-04-29 at 23:19, jmay wrote:
> Sjoerd Visscher suggests (at 
> http://w3future.com/weblog/2002/04/30.html#a93) that "REST violates a 
> lot of rules of both functional and object oriented programming", 
> because it has "a small API" (presumably referring to GET, POST, PUT 
> as the REST API).

It certainly does violate a lot of "rules" of OOP:  the focus on
composition of generic interfaces is the antithesis of OOP's
type-specific interfaces and encapsulation.

OTOH, I'm not sure that it's incompatible with functional programming in
any real sense.  Like functional programming, the focus is on
composition.  Resources, like monads, hide state --- any given
interaction is stateless in some sense.  These are just a couple of
obvious parallels;  it's an interesting question, though, and I would
suggest that the similarity is much deeper than it might appear at first
glance.  (In fact, my own as-yet unfruitful efforts to formally
demonstrate certain things about the complexity of REST-like vs. OOP
systems relies on a certain functional model of REST;  one of these
days, maybe hopefully, that investigation will be ready for prime time.
:-)

BTW, let's be careful not to facilely and incorrectly assume that REST
being "incompatible" with OOP says anything negative about REST; 
indeed, I'm beginning to think that there are several research and
engineering trends converging towards a recognition that OOP doesn't
give us what we wanted in terms of re-use, maintainability, etc....

jb







-----------------------------------------------------------------------------------
Post ID:1148
Sender:"Kay, Michael" <Michael.Kay@...>
Post Date/Time:2002-04-30 14:04:12
Subject:RE: XSLT2.0 and HTTP-PUT
Message:

Thanks for the comment. I think it's hard for us to be prescriptive about
this. An XSLT processor designed solely for use on TV set-top-boxes might
have no market requirement (or technical possibility) to write output to an
HTTP PUT destination, nor indeed to anywhere other than the TV screen. We
want language interoperability, but we can't assume that all processors
execute in the same kind of environment.

I don't mind, however, putting in some kind of note giving examples of the
sorts of URI that permit writing.

Michael Kay

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@...]
> Sent: 29 April 2002 21:36
> To: xsl-editors@...
> Cc: rest-discuss@yahoogroups.com
> Subject: XSLT2.0 and HTTP-PUT
> 
> 
> XSLT2 allows you to specify a URI to write output  documents 
> to [1]. The 
> current WD goes to some pains to say that implementations  can choose 
> how to support (or not) different schemes, etc.
> 
> However, considering recent discussion on www-tag re: REST, the Web, 
> interoperability, etc., it would be nice if it highlighted 
> (or even made 
> a requirement for conditional compliance) support for HTTP 
> through PUT, 
> lest the only
> support be for "file" URIs.
> 
> Has this been discussed in the WG?
> 
> Regards,
> 
> 
> 1. http://www.w3.org/TR/xslt20/#element-destination
> 
> --
> Mark Nottingham
> http://www.mnot.net/
> 
> 






-----------------------------------------------------------------------------------
Post ID:1149
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-04-30 15:27:20
Subject:Re: REST
Message:

Jeff Bone wrote:
> 
> On Mon, 2002-04-29 at 23:19, jmay wrote:
> > Sjoerd Visscher suggests (at 
> > http://w3future.com/weblog/2002/04/30.html#a93) that "REST 
violates a 
> > lot of rules of both functional and object oriented programming", 
> > because it has "a small API" (presumably referring to GET, POST, 
PUT 
> > as the REST API).
> 
> It certainly does violate a lot of "rules" of OOP:  the focus on
> composition of generic interfaces is the antithesis of OOP's
> type-specific interfaces and encapsulation.

On the other hand, I think the consensus of OOP practitioners who 
have developed large distributed object systems (or even heavily 
layered systems) is toward something more RESTful than "classic OOP" 
with lots of little methods.

By that I mean whenever you cross boundaries (distributed, trust, 
even processes), larger granularity is better than small.

I.e. use facades at boundary crossings and pass back and forth large-
grained representations of a composite object behind the facade.

I.e. use URIs to identify resources and pass representations of their 
state around.

I am certain that the SOAP RPC programmers will learn this from sad 
experience over time.

Selections on related topics from WikiWiki:
http://c2.com/cgi/wiki?DomainObjectStateHolder
http://c2.com/cgi/wiki?BagOfJumpingBeans
http://c2.com/cgi/wiki?DataTransferObject
http://c2.com/cgi/wiki?HalfObjectPlusProtocol

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:1150
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-04-30 21:59:25
Subject:Re: [rest-discuss] REST
Message:

----- Original Message -----
From: "jmay" <jmay@...>

> Sjoerd Visscher suggests (at
> http://w3future.com/weblog/2002/04/30.html#a93) that "REST violates a
> lot of rules of both functional and object oriented programming",
> because it has "a small API" (presumably referring to GET, POST, PUT
> as the REST API).
I think this is in reference to:
"Translated to programming terms it is like having a huge set of global
variables (the state of the program) which are read and written directly."
This is not what REST says. There are 'lots of nouns, few verbs' but you
still go through interfaces to make any changes - you just style things to
reuse simple interfaces.
REST is more about state transfer across large scale applications than an
API approach that uses generic local object interfaces.
There are similarities between distributed state-exchaning applications and
'programming with interfaces' - but they shouldn't be equated.








-----------------------------------------------------------------------------------
Post ID:1151
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-30 22:51:11
Subject:Re: [rest-discuss] RE: XSLT2.0 and HTTP-PUT
Message:

"Kay, Michael" wrote:
> 
> Thanks for the comment. I think it's hard for us to be prescriptive about
> this. An XSLT processor designed solely for use on TV set-top-boxes might
> have no market requirement (or technical possibility) to write output to an
> HTTP PUT destination, nor indeed to anywhere other than the TV screen. We
> want language interoperability, but we can't assume that all processors
> execute in the same kind of environment.
> 
> I don't mind, however, putting in some kind of note giving examples of the
> sorts of URI that permit writing.

Speaking for myself, I would be very happy with a non-normative note
that would get across the point (in appropriate spec-ese) that HTTP is
in fact a bidirectional protocol and that it would make just as much
sense to PUT to an HTTP URI as to a file system path. If at all
possible, please use the word "PUT" (if even in a non-normative example)
so that we have a chance of interoperability among implementations.
(there will be a tempation to use the more popular "POST" even though it
does not have the same "overwrite file" semantic).

Something like:

"For example writing to a file://... URI would overwrite a file. Writing
to an http://... URI would invoke the HTTP PUT method."

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1152
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-30 23:36:56
Subject:GoogleAPI is Rest?
Message:

Sam says:
> I've been doing some reading on REST.  I'm not convinced that REST 
> dictates GET.  Here are three quotes from Roy Fielding, the 
> "inventor" of REST:
> 
> REST is an architectural style -- it does not dictate protocol syntax. 
> There's no basis for "everything must use GET" in Web architecture. 
> there is a trade-off between GET and POST that usually involves the 
> size of the parameter content.
> 
> I'm now convinced that one can architect a system in accordance 
> to the principles of REST and then implement that system using 
> RPC style, HTTP transport, POST binding, SOAP.  
http://radio.weblogs.com/0101679/2002/04/28.html#a414

I think that most REST fans would agree this far. You *could* architect
a system according to these principles. After all, SOAP is just a
syntax. But if the relevant specifications do not encourage or require
this, then you will have no interoperability with someone else who
happens also to have read Roy's thesis but, for instance, to have called
his "GET" method "fetch" and his "PUT" method "chuck." And furthermore,
the WAY you say "where to get from" and "where to put to" will be
non-standard: SOAP does not encourage nor require you to use URIs as
resource identifiers.

HTTP is a *standard* way of doing REST over the Internet. Now of course
we could reinvent REST-on-the-Internet in SOAP syntax two layers above
HTTP but it seems a little bit ridiculous to me. A better strategy is to
use SOAP as an extension to HTTP that adds the features HTTP lacks.

> ... In fact, I'll go 
> further and state that the GoogleSearch is an instance of this.

I disagree. Here are the four principle ideas of REST:

1. identification of resources; 

Google does not identify resources explicitly. I had to infer that every
method/parameter combination was a resource. Then I built a layer that
identified each of those URIs through the Web's addressing mode: URIs.

2. manipulation of resources through representations;

SOAP has no concept of either resources or representations and the
Google API certainly did not add them!

3. self-descriptive messages; 

Okay, I'll concede this: SOAP may be ugly but its not quite binary!
Still on a scale of 1 to 10, the HTTP version wins! But more important,
the HTTP version is self-descriptive to *any HTTP intermediary*
including a cache or proxy. The SOAP version is self-descriptive only to
intermediaries trained to expect the particular method names.

4. and, hypermedia as the engine of application state

In order to shorten the article, I left out a couple of paragraphs with
examples of ways that Google *could* have used hypertext as the engine
of application state.

"For instance, imagine if the search API returned a URI to the cached
page, just as it does in the HTML version of Google. I could declare in
WRDL (as opposed to WSDL) that the cachedPage element of searchResult
resources points to a document of type text/html. I could also define a
resource type for Google "directory catalogs", then I could declare
strong types (XML namespaces or schemas) for the links from search
results to the directory catalogs and back. WRDL is designed (okay,
being designed) to mirror the structure of the Web, rather than impose a
component-oriented view on top of it."

It would be great to have bidirectional links from the Google XML
repository to the Open Directory XML repository! It would take much more
effort to do the thing with SOAP and it would not scale as well to
several directory services (with potentially varying APIs) and several
search engines (with potentially varying APIs).

I've documented the technical weaknesses of the Google solution. In
particular, nothing is addressable and that makes it incompatible with
any tool that can only work with addressable information. The ones I
happened to mention will probably elicit a yawn from the SOAP crowd
(XSLT -- so 1999) but the more important point is that any other web
service that wants to interoperate with Google will have to explicitly
hard-code those three methods instead of "just knowing" that a URI is
sufficient to get information out.

I didn't mention REST in the article because I think that we make more
progress when we approach from a concrete technical point of view. Plus,
I suspect Roy is getting sick of the REST hype.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1153
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-04-30 23:43:07
Subject:Re: [rest-discuss] REST
Message:

jmay wrote:
> 
> Sjoerd Visscher suggests (at
> http://w3future.com/weblog/2002/04/30.html#a93) that "REST violates a
> lot of rules of both functional and object oriented programming",
> because it has "a small API" (presumably referring to GET, POST, PUT
> as the REST API).

I'll repeat what others have said: comparing OO and REST is comparing
apples and elephants. One is about building networked systems that cross
organizational boundaries and integrate well with other systems. The
other is about building individual programs so that they are robust and
extensible.

Also: I've never seen a deployed SOAP web service that was even remotely
"object oriented" so even if that adjective applied, we'd have to
compare REST to CORBA or DCOM, not SOAP.

And functional? I'm trying hard to imagine how you'd make a "functional"
web service without making it useless!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1154
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-01 00:05:14
Subject:Re: GoogleAPI is Rest?
Message:

If you found that weblog entry interesting, I'm sure that you will enjoy
this one:

   http://www.oreillynet.com/cs/weblog/view/wlg/1351

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1155
Sender:Aaron Swartz <me@...>
Post Date/Time:2002-05-01 01:04:18
Subject:Re: [rest-discuss] Re: GoogleAPI is Rest?
Message:

On 2002-04-30 07:05 PM, "Sam Ruby" <rubys@...> wrote:

> If you found that weblog entry interesting, I'm sure that you will enjoy
> this one:
> 
>  http://www.oreillynet.com/cs/weblog/view/wlg/1351

Sam, I am sincerely disappointed in this misleading characterization of
REST. If it stems from just not knowing about the issues, then I hope that
you'll correct the article.

While REST per se may not require to HTTP GET, the TAG has a draft finding
that does. Meanwhile, REST requires many other things for HTTP compatibility
which SOAP does not provide. As Roy Fielding has stated on the TAG list, the
key things SOAP needs to do is:

 - use proper HTTP response codes
 - use different URIs for each object
 - use proper cache-control headers

To say that  pure query interfaces with no side effects meet [REST]
criteria. Even if they use HTTP POST." is at best misleading and at worst
false.

I'm sure others on the list can expand further.
-- 
[ "Aaron Swartz" ; <mailto:me@...> ; <http://www.aaronsw.com/> ]







-----------------------------------------------------------------------------------
Post ID:1156
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-01 01:13:55
Subject:Re: [rest-discuss] Re: GoogleAPI is Rest?
Message:

On Tue, Apr 30, 2002 at 08:05:14PM -0400, Sam Ruby wrote:
> If you found that weblog entry interesting, I'm sure that you will enjoy
> this one:
> 
>    http://www.oreillynet.com/cs/weblog/view/wlg/1351

Sam, really, you need more than "a few days" to grok REST, especially
when you're likely used to seeing the world through RPC tained eyes.  It
took me about three years to really get a solid grasp of it, and I have
a lot of experience in distributed systems theory and practice.

You also took Roy's comments completely out of context.  Yes, you do
not need to use GET to be using REST.  But that means you can't
retrieve things (unless you want to do that ugly hack that Paul talked
about), which I'm sure you'd agree is useful.  If you're only using POST,
then all you can do is EDI; send a document for processing, never
knowing how it impacted the state of the system.

You might want to try incorporating some more of his words into your
next article;

"The problem with SOAP is that it tries to escape from the Web
interface.  It deliberately attempts to suck, mostly because it
is deliberately trying to supplant CGI-like applications rather
than Web-like applications."

"This bears repeating: The difference between an application-level
protocol and a transport-level protocol is that an application-level
includes application semantics, by standard agreement, within
the messages that the protocol transfers.  That is why HTTP is called
a Transfer protocol.  It is impossible to conform to an
application-level protocol without also conforming faithfully to
its message semantics."

"As a *separate* issue, Web Services cannot be considered an equal
part of the Web until they allow their own resources to become
interconnected with the rest of the Web.  That means using URI to
identify all important resources, even if those URI are only used
via non-SOAP mechanisms (such as a parallel HTTP GET interface) after
the SOAPified processing is complete."

Please, feel free to ask us any questions.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1157
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-05-01 01:17:20
Subject:plaintext test, ignore
Message:

ARRGGHHH!!!







-----------------------------------------------------------------------------------
Post ID:1158
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-01 01:59:11
Subject:Re: GoogleAPI is Rest?
Message:

[mailed and posted: http://www.oreillynet.com/cs/user/view/cs_msg/7147]

I'm not convinced that it is productive to do a point-by-point argument
against the weblog. If you want to discuss REST then I think a mailing
list is a more productive way to do it. We could make a whole new one if
you want an "even ground" or "decentralization" might be an interesting
place. So I won't go through point by point and just try to re-emphasize
the central point of my article.

Yes, I exaggerated the seriousness of Google's crime because I'm trying
to motivate action rather than just dryly analyze. But Google's "crime"
is that they deprived the Web of approximately a billion useful XML
URIs. We could have used those URIs in XInclude, XSLT, XPath, XPointer,
RDF. And of course we could ALSO have used them in Java, Perl, Python,
C#, Ruby, ...

URIs are declarative, like SQL. You type them in and declarative data
comes back. Just as you can type SQL in a little one-line window and get
back records, you can type a URI in a little one-line window and get
back representations of resources. Just as you can integrate tables
using joins, you integrate XML/URI-based web services using XInclude and
RDF.

Before the relational model (and query language) was widely circulated,
the whole concept would have seemed ridiculous to database programmers.
You could just use the "API" (surely not the terminology they used back
then, but...). You want to integrate two tables...you write some code
that iterates over one and the other and correlates them. As long as you
like coding glue, and don't care about scalability, this is a great
system! It took years for people to understand the subtle benefits of a
system that is consistent but also very restrictive.

That's where we are today, with Web Services and REST. Precisely because
the issues are subtle, we have to yell loud to be heard. 

In particular, the fundamental benefit of publishing through URIs is
interoperability:

 * http://lists.w3.org/Archives/Public/www-tag/2002Apr/0286.html
 * http://www.xml.com/pub/a/2002/02/06/rest.html

Until there is more than one useful web service on the Internet, it's
really hard to demonstrate interoperability advantages...

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1159
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-01 02:34:40
Subject:Re: GoogleAPI is Rest?
Message:

[mailed and posted: http://www.oreillynet.com/cs/weblog/view/cs_msg/7148]
>
> I'm not convinced that it is productive to do a point-by-point
> argument against the weblog. If you want to discuss REST
> then I think a mailing list is a more productive way to do it.

Perhaps we could have a F2F discussion at the ETCON? Want to schedule a
BOF? I hear that Nelson Minar is going to be there...

I'd love to find some common ground and jointly author some recommendations
on the subject...

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1160
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-05-01 04:58:26
Subject:Re: [rest-discuss] Re: GoogleAPI is Rest?
Message:

Huh? Their genius was in recoginizing that "content is king" and they've got
the content - and the poor schmucks trolling for something interesting to do
with SOAP would jump on a dressed up GET request and provide them a quick
marketing buzz. Can't wait for the AOL boyz to hand out the free SOAP API to
retrieve content from their pay-to-play network... imagine where CompuServe
and Prodigy would be today if they had something like SOAP to affect their
reach...
> Google's Genius?
> To pick a wire format for which there are dozens of toolkits poised to
directly translate the protocol into readily consumable bits.
How many toolkits can do HTTP GET? Correctly? Why would a stream of XML from
a response to a GET be less readily consumable?

> To directly test interop against a small but diverse set of platforms.
You don't need SOAP to do that.

> To provide early access to an undisclosed number of other interested
parties.
They had an HTTP API that provided XML via GET - but you had to pay to play.
If they open that one up, you'd get just as many people incorporating it
into products as the SOAP API.

> To provide a sample that runs on wide range of operating systems and
instruction set architectures.
Uh, so does HTTP?

> To document the wire protocol adequately, including all the optional type
annotations.

> And to provide sufficient metadata, in the form of WSDL, so that a large
number of developers can be instantly up and running.
Don't know how to do that in pure HTTP - that's a missing piece. Not enough
to through out the baby with the bathwater though.



----- Original Message -----
From: "Sam Ruby" <rubys@...>
To: "Paul Prescod" <paul@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Tuesday, April 30, 2002 5:05 PM
Subject: [rest-discuss] Re: GoogleAPI is Rest?


> If you found that weblog entry interesting, I'm sure that you will enjoy
> this one:
>
>    http://www.oreillynet.com/cs/weblog/view/wlg/1351
>
> - Sam Ruby
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:1161
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-05-01 13:34:09
Subject:Re: [rest-discuss] Re: GoogleAPI is Rest?
Message:


On Tue, 30 Apr 2002, Asynch Messaging wrote:
> > And to provide sufficient metadata, in the form of WSDL, so that a large
> > number of developers can be instantly up and running.
> Don't know how to do that in pure HTTP - that's a missing piece. Not enough
> to through out the baby with the bathwater though.

There are a bunch of missing pieces.  WSDL for HTTP resources needs to
happen.  Work on event models needs to get finished.  Maybe store and
forward (the email workalike we discussed here a few months ago) needs to
happen.

SOAP-RPC already offers solutions to all of the above.  They're not as
good as HTTP solutions could be but at least they're out there.  Until the
REST stack gets filled out to the same degree as the XML RPC stack, we are
in ivory tower land.

- Lucas








-----------------------------------------------------------------------------------
Post ID:1162
Sender:Ken MacLeod <ken@...>
Post Date/Time:2002-05-01 14:42:29
Subject:RESTful data
Message:

In <http://www.oreillynet.com/cs/weblog/view/wlg/1351>, Sam Ruby writes:
> Google's Genius?  To pick a wire format for which there are dozens
> of toolkits poised to directly translate the protocol into readily
> consumable bits.

Agreed.  I've seen way too many XML apps traipse through raw DOMs
picking out their data.  Getting the your data in readily consumable
bits is a great service.

Is the huge amount of SOAP infrastructure a means to simply get data
in readily consumable bits?  What if RESTful toolkits with marshalling
code were common.  Where would we be in discussing the architectural
styles between <that which SOAP generally exhibits but which has no
name*> and REST?

In simple implementations, like XML-RPC, marshalling is about half of
the implementation with procedure call semantics the other half.
Creating an HTTP request library that just marhsalls data should be
that much simpler than one that relays calls.

  -- Ken

* I don't think of this as a SOAP vs. REST debate per se, maybe we can
  come up with a better term for the SOAP style than "that which is
  not REST but is like messaging or RPC".






-----------------------------------------------------------------------------------
Post ID:1163
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-05-01 15:01:01
Subject:Re: [rest-discuss] REST
Message:

On Tue, 2002-04-30 at 18:43, Paul Prescod wrote:
> 
> And functional? I'm trying hard to imagine how you'd make a "functional"
> web service without making it useless!

That's a failure of imagination. ;-)  Seriously, the parallels are quite
significant.  In effect, URIs are generic functions that dispatch on
message, parameter, conneg and other headers to a fixed set of
functions, i.e. the supported HTTP method implementations.  The abstract
resource itself can be regarded as a monad that encapsulates the
side-effecting state changes on e.g. PUT and POST.  The various pieces
of input ("parameters", headers) define the domain of the specific
function and the set of possible representations associated with that
function is the codomain / range.

That may stretch the way you think of "functional", but it works quite
well.  With a bit more formality and rigor in these definitions it
becomes possible to begin talking about Web interactions using a
compositional algebra, and you can reason about Web architecture using
the tools of category theory.

jb










-----------------------------------------------------------------------------------
Post ID:1164
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-01 15:02:37
Subject:Re: [rest-discuss] Re: GoogleAPI is Rest?
Message:

On Wed, May 01, 2002 at 09:34:09AM -0400, Lucas Gonze wrote:
> There are a bunch of missing pieces.  WSDL for HTTP resources needs to
> happen.

Perhaps, but with nowhere near the urgency, and nowhere near the
complexity of WSDL.  WSDL exists, and is a necessary part of Web
Services, because you don't know anything about an interface.  With
REST, you start off with a lot of information.  It's not *all* the
information everybody would ever need, but it's more than enough for
most.

>  Work on event models needs to get finished.  Maybe store and
> forward (the email workalike we discussed here a few months ago) needs to
> happen.

Yes.

> SOAP-RPC already offers solutions to all of the above.  They're not as

SOAP doesn't have an event model, or a store and forward model.  It has
an intermediary model, just like HTTP, only better specified.

> good as HTTP solutions could be but at least they're out there.  Until the
> REST stack gets filled out to the same degree as the XML RPC stack, we are
> in ivory tower land.

Oh, please.  Without any further work, I can get a whole lot done with
REST right now, between uncoordinated parties .  The same is not true
for SOAP/Web-services.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1165
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-01 16:40:55
Subject:Re: [rest-discuss] REST
Message:

Jeff Bone wrote:
> 
> On Tue, 2002-04-30 at 18:43, Paul Prescod wrote:
> >
> > And functional? I'm trying hard to imagine how you'd make a "functional"
> > web service without making it useless!
> 
> That's a failure of imagination. ;-) 

What I meant was: a defining characteristic of functional programming is
a lack of side-effects and mutation. In other words, if f(x,y) returns z
today, it will always return z. This maps to the subset of "Web
Services" known as the "static Web".

If you start from a different definition of functional, your conclusions
will of course vary.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1166
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-01 16:45:02
Subject:Re: [rest-discuss] Re: GoogleAPI is Rest?
Message:

Lucas Gonze wrote:
> 
> On Tue, 30 Apr 2002, Asynch Messaging wrote:
> > > And to provide sufficient metadata, in the form of WSDL, so that a large
> > > number of developers can be instantly up and running.
> > Don't know how to do that in pure HTTP - that's a missing piece. Not enough
> > to through out the baby with the bathwater though.
> 
> There are a bunch of missing pieces.  WSDL for HTTP resources needs to
> happen.  Work on event models needs to get finished.  Maybe store and
> forward (the email workalike we discussed here a few months ago) needs to
> happen.

WSDL for HTTP is -- as far as I can tell -- exactly as functional as
WSDL for SOAP. That doesn't mean that WSDL is REST-ful, but it does mean
that your next sentence is misleading:

> SOAP-RPC already offers solutions to all of the above. 

How does SOAP-RPC handle "event models"????

> ... They're not as
> good as HTTP solutions could be but at least they're out there.  Until the
> REST stack gets filled out to the same degree as the XML RPC stack, we are
> in ivory tower land.

We are already more filled out. WSDL is broken for HTTP but just as
broken for SOAP. UDDI is entirely useless for both. Our rough ideas at
event models are better than what I've seen for SOAP. We have *some*
form of authentication. Most important: we have an addressing and
resource manipulation model. They don't even know that they lack one yet
(despite that I've been telling them for six months!).

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1167
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-01 17:20:27
Subject:Re: [rest-discuss] Re: XML vs RDF
Message:

Mark Baker wrote:
> 
> I think syntax matters too.  That's why I'm not an XML person. 8-)

Mark Baker wrote:
> 
> Sure, but there's more information available in the former case.  If the
> XML is going to be processed by a machine anyways, why is the latter
> approach any better?  

The "only machines will see it" argument is the typical of the approach
of people who don't care about syntax. ;)

> ... I suppose if it were hand authored, but is that
> what we're talking about here?

Well yes, some of it is completely hand-authored. But at some level it
is ALL hand-authored. After all, somebody has to write and debug the
programs that works with this stuff. Admittedly, RDF (no matter how
ugly) is not quite as bad as binary but nevertheless I see this: "don't
worry what it looks like" argument as a slippery slope to unreadability
and ultimately back to binary.

> Also, I think the XML syntax for the RDF model is a horrible, nasty,
> unnecessary thing.  It should be killed.

You mean that RDF should not be XML-expressible at all? Use
s-expressions? Or do you mean you dislike all of the weird
minimizations?

>...
> I've heard talk of adorning schemas with the information necessary to
> construct RDF.  I like this in theory, though I fear for the practical
> implications; primarily, additional network round-trips.

The relationship between documents and schemas will typically be many to
one so you can do a lot of caching of schemas. Sophisticated RDF use is
already dependent on schemas (RDF schemas) to get subclassing and
inferencing information, isn't it? So if you want high volume use of RDF
I think you'll have to figure out schema caching technologies. Is it
really feasible to use RDF without one of: a) a schema or b) a priori
knowledge of the vocabulary?

>...
> > That's certainly valuable but in my personal opinion, most XML users
> > will not be willing to pay the price of designing their vocabularies
> > specifically for RDF compatibility.
> 
> For now, that's clearly true.  As more RDF features are integrated into
> tools, the cost of doing this will come down.

I don't see it as a tools cost but as a readability cost. Sprinkling all
of that RDF junk through my document is, imo, as unacceptable as
sprinkling SOAP voodoo into my messages. I guess it boils down to: I
think you optimize the XML for readability and processability *as XML*
and then figure out how to get the benefits of protocols and metadata
engines etc. You think that RDF is primary and that XML is just a
container for it.

But if that's true then RDF should use an optimized-for-RDF syntax, not
XML at all.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1168
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-05-01 17:19:58
Subject:Re: [rest-discuss] Re: GoogleAPI is Rest?
Message:

> WSDL for HTTP is -- as far as I can tell -- exactly as functional as
> WSDL for SOAP. That doesn't mean that WSDL is REST-ful, but it does mean
> that your next sentence is misleading:
>
> > SOAP-RPC already offers solutions to all of the above.

Point taken.

> How does SOAP-RPC handle "event models"????

By allowing SOAP-RPC to be transported over event protocols such as JMS,
and by having a more fleshed out model for intermediaries.  Precanned
support for HTTP intermediaries is limited to real time proxying.
Otherwise you have to get out the power tools and write a gateway by hand,
which is too low level a job for most projects.

Rather than argue over the details of what is and isn't available, lets
focus on building.  People are getting the impression -- false IMO -- that
REST is a religious war.  That's what Sam Ruby was mainly reacting to, and
what Dave Winer has been ranting about on scripting news.  The kind of
obscurantia that we've been arguing over, e.g. URI opacity, needs to be
solved and polished well enough to allow app developers to focus on
application needs.  I don't believe anyone here thinks that's already
done.

Maybe evangelizing is a part of the work.  For example, make the point
that service description tools, specifically Visual .NET, apply equally to
REST development.  So let's do it.  but let's not fool ourselves into
thinking that once somone embraces the one true faith they'll find full
featured toolkits.

- Lucas












-----------------------------------------------------------------------------------
Post ID:1169
Sender:"sa3ruby" <rubys@...>
Post Date/Time:2002-05-01 18:22:18
Subject:Re: RESTful data
Message:

--- In rest-discuss@y..., Ken MacLeod <ken@b...> wrote:
> 
> Is the huge amount of SOAP infrastructure a means to simply get data
> in readily consumable bits?  

Pretty much.  Paul may consider optional parameters a simplification, 
but from a toolkit perspective it is a complexity.  It also doesn't 
help that there isn't a one-to-one and onto mapping between section 5 
defined types and implementation languages like Java.  Or that 
section 5 diverges from XML Schema.
 
There are a few other considerations, such as headers which allow for 
cross-cutting concerns to be addressed, and some investment in 
transport independence.

> In simple implementations, like XML-RPC, marshalling is about half 
of
> the implementation with procedure call semantics the other half.
> Creating an HTTP request library that just marhsalls data should be
> that much simpler than one that relays calls.

In Axis, the RPC provider is just one modest sized class.  It extends 
the Java provider, and I must confess that there is some other 
knowledge of RPC that bleeds through in some minor ways in other 
parts of the implementation (clearly not ideal, but I'm being 
brutally honest here).

The RPC advocates have clearly articulated how such a marshalling 
infrastructure can be used to implement their preferred style of 
interaction.  I can't help but wonder if it would be possible for 
this to be done with REST.







-----------------------------------------------------------------------------------
Post ID:1170
Sender:"sjoerd_visscher" <sjoerd@...>
Post Date/Time:2002-05-01 19:25:11
Subject:Re: REST
Message:

--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
> What I meant was: a defining characteristic of functional programming is
> a lack of side-effects and mutation. In other words, if f(x,y) returns z
> today, it will always return z. This maps to the subset of "Web
> Services" known as the "static Web".

Which is exactly the subset that should use HTTP GET.
It might be interesting to compare all REST features with the features
of 'unpure' functional languages.

Sjoerd Visscher







-----------------------------------------------------------------------------------
Post ID:1171
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-01 19:33:11
Subject:Re: [rest-discuss] Re: REST
Message:

sjoerd_visscher wrote:
> 
> --- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
> > What I meant was: a defining characteristic of functional programming is
> > a lack of side-effects and mutation. In other words, if f(x,y) returns z
> > today, it will always return z. This maps to the subset of "Web
> > Services" known as the "static Web".
> 
> Which is exactly the subset that should use HTTP GET.
> It might be interesting to compare all REST features with the features
> of 'unpure' functional languages.

But GET is also good for fetching information that changes over time:
like stock quotes.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1172
Sender:Sjoerd Visscher <sjoerd@...>
Post Date/Time:2002-05-01 19:41:41
Subject:Re: [rest-discuss] Re: REST
Message:

Paul Prescod wrote:
> sjoerd_visscher wrote:
>>--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
>>>What I meant was: a defining characteristic of functional programming is
>>>a lack of side-effects and mutation. In other words, if f(x,y) returns z
>>>today, it will always return z. This maps to the subset of "Web
>>>Services" known as the "static Web".
>>
>>Which is exactly the subset that should use HTTP GET.
>>It might be interesting to compare all REST features with the features
>>of 'unpure' functional languages.
> 
> But GET is also good for fetching information that changes over time:
> like stock quotes.

Yes, that's why languages like Haskell have some side-effect mechanisms. 
But they are designed very careful and maybe comparing those features 
with REST will add some interesting information to the discussion.

Sjoerd







-----------------------------------------------------------------------------------
Post ID:1173
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-05-01 20:01:14
Subject:Re: [rest-discuss] REST
Message:

On Wed, 2002-05-01 at 11:40, Paul Prescod wrote:
> 
> What I meant was: a defining characteristic of functional programming is
> a lack of side-effects and mutation. In other words, if f(x,y) returns z
> today, it will always return z. 

The functional programming community realized, oh, circa the
Miranda->Haskell transition that this interpretation of function
restricted functional programming in such a way as to make it
essentially useless except as a theoretical tool.  Then followed much
debate over how to functionally model entities whose codomain varied
with time and state:  approaches included explicitly modeling time and
history as domain context, etc...  the most effective approach has been
to encapsulate this variation into entities called "monads" and model
the result type as monadic-dependent.  Net result is the ability to
again reason mathematically about such entities via a compositional
style / algebra of programs ala Backus, FP & friends.  Haskell, monads,
check it out.

jb








-----------------------------------------------------------------------------------
Post ID:1174
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-05-01 20:03:15
Subject:Re: [rest-discuss] Re: REST
Message:

Paul already made the comment that comparing REST to programming language
paradigms is like comparing apples to elephants. The Web is not a
programming language. Why would you even want to make that comparison?

Jason

----- Original Message -----
From: Sjoerd Visscher
To: Paul Prescod
Cc: rest-discuss@yahoogroups.com
Sent: Wednesday, May 01, 2002 12:41 PM
Subject: Re: [rest-discuss] Re: REST


Paul Prescod wrote:
> sjoerd_visscher wrote:
>>--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
>>>What I meant was: a defining characteristic of functional programming is
>>>a lack of side-effects and mutation. In other words, if f(x,y) returns z
>>>today, it will always return z. This maps to the subset of "Web
>>>Services" known as the "static Web".
>>
>>Which is exactly the subset that should use HTTP GET.
>>It might be interesting to compare all REST features with the features
>>of 'unpure' functional languages.
>
> But GET is also good for fetching information that changes over time:
> like stock quotes.

Yes, that's why languages like Haskell have some side-effect mechanisms.
But they are designed very careful and maybe comparing those features
with REST will add some interesting information to the discussion.

Sjoerd


Yahoo! Groups Sponsor
ADVERTISEMENT




To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.







-----------------------------------------------------------------------------------
Post ID:1175
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-05-01 20:44:59
Subject:Re: [rest-discuss] Re: REST
Message:

On Wed, 2002-05-01 at 15:03, Jason Diamond wrote:
> 
> Paul already made the comment that comparing REST to programming 
> language paradigms is like comparing apples to elephants. The 
> Web is not a programming language. Why would you even want to make
> that comparison?

Yes, but just because Paul (or anyone else) makes such a comment doesn't
mean that it's true or useful.  (I.e.: it may be that this is an apples
and elephants comparison, but there may be many conversational contexts
in which it useful to compare, contrast, or consider similarities
between apples and elephants.)  I've found it particularly instructive
to compare REST to programming language paradigms, and here's why:

REST is an "architectural style" --- in some circles (e.g. component /
frameworks researchers) also called a "compositional style."  As it
turns out, all programming languages inherently embody one or another
(or maybe even many) architectural / compositional styles, so it's
useful to abstract those styles away from particular programming
language implementations and compare them.  Functional programming is
one such style;  OOP is another, dataflow is another, etc.  (NB:  it's
easy to argue that dataflow styles are a subset of functional styles).

All of these things are mechanisms for decomposing functionality into
discrete pieces and then building up programs by "plugging" these pieces
together and letting them talk to each other.  The abstract model of how
you do this is what defines a given style, and whether that is embodied
in a programming language or a distributed system design is, at some
level, irrelevant.  You can usefully talk about (some of) the
characteristics of one model or the other independent of its specific
instantiation.

Anyway, I happen to have found the process of such consideration
instructive in understanding REST.  Your (or Paul's, etc.) mileage may
vary, but before you jump the gun, consider the following sentence:

   "OOP is to CORBA as ??? is to the Web."

jb








-----------------------------------------------------------------------------------
Post ID:1176
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-05-01 20:53:04
Subject:Re: [rest-discuss] Re: REST
Message:

Jeff Bone wrote:

> Yes, but just because Paul (or anyone else) makes such a comment doesn't
> mean that it's true or useful.  (I.e.: it may be that this is an apples
> and elephants comparison, but there may be many conversational contexts
> in which it useful to compare, contrast, or consider similarities
> between apples and elephants.)  I've found it particularly instructive
> to compare REST to programming language paradigms, and here's why:

I didn't mean to imply that (when it comes to REST) what Paul says, goes.
That was just my way of saying that I thought that particular comment of his
was both true and useful. Saying that REST is (or is not) OO and that makes
it good (or bad) are the types of comments that I don't think could ever be
universally true or useful.

> All of these things are mechanisms for decomposing functionality into
> discrete pieces and then building up programs by "plugging" these pieces
> together and letting them talk to each other.  The abstract model of how
> you do this is what defines a given style, and whether that is embodied
> in a programming language or a distributed system design is, at some
> level, irrelevant.  You can usefully talk about (some of) the
> characteristics of one model or the other independent of its specific
> instantiation.

But what I think that you're missing is that REST can be abstracted away
behind an OO API, a procedural one, a functional one (using monads), and
probably even others. The REST architectural style is orthogonal to whatever
programming paradigm you prefer to develop in.

> Anyway, I happen to have found the process of such consideration
> instructive in understanding REST.  Your (or Paul's, etc.) mileage may
> vary, but before you jump the gun, consider the following sentence:
>
>    "OOP is to CORBA as ??? is to the Web."

OOP and CORBA are not related exlusively to all other programming paradigms
or architectural styles. It's just as possible to develop a monolithic
procedural API using CORBA as it is an object oriented one. The same goes
for REST.

Jason








-----------------------------------------------------------------------------------
Post ID:1177
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-05-01 21:15:53
Subject:Re: [rest-discuss] Re: REST
Message:

On Wed, 2002-05-01 at 15:53, Jason Diamond wrote:
> Jeff Bone wrote:
> 
> But what I think that you're missing is that REST can be abstracted away
> behind an OO API, a procedural one, a functional one (using monads), and
> probably even others. The REST architectural style is orthogonal to whatever
> programming paradigm you prefer to develop in.

I don't actually agree with this.  While it's true that any
computationally complete facility can be used to express any other
similar facility --- this is all about universality, etc. --- that
doesn't mean that they are all equivalent.  I can model functions as
objects;  I can model objects as functions; etc. etc. etc. 'til the cows
come home.  However, that's not a particularly useful observation: 
similarly, that's like saying that OOP is orthogonal to whatever
programming language you happen to be using.  While it's true that you
can do OOP even in e.g. assembly, it sure ain't easy. ;-)

My point is that REST the architectural style may *be* or *imply* a
particular programming paradigm;  consideration of that issue has been
particularly helpful to me in understanding and quantifying certain
things about REST.

> >    "OOP is to CORBA as ??? is to the Web."
> 
> OOP and CORBA are not related exlusively to all other programming paradigms
> or architectural styles. It's just as possible to develop a monolithic
> procedural API using CORBA as it is an object oriented one. The same goes
> for REST.

I think you're missing something important, but can't quite put my
finger on how to explain it to you.

jb








-----------------------------------------------------------------------------------
Post ID:1178
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-05-01 21:21:29
Subject:Re: [rest-discuss] Re: REST
Message:

Jeff Bone wrote:

> > But what I think that you're missing is that REST can be abstracted away
> > behind an OO API, a procedural one, a functional one (using monads), and
> > probably even others. The REST architectural style is orthogonal to
whatever
> > programming paradigm you prefer to develop in.
>
> I don't actually agree with this.  While it's true that any
> computationally complete facility can be used to express any other
> similar facility --- this is all about universality, etc. --- that
> doesn't mean that they are all equivalent.  I can model functions as
> objects;  I can model objects as functions; etc. etc. etc. 'til the cows
> come home.  However, that's not a particularly useful observation:
> similarly, that's like saying that OOP is orthogonal to whatever
> programming language you happen to be using.  While it's true that you
> can do OOP even in e.g. assembly, it sure ain't easy. ;-)

This is a very good point.

> My point is that REST the architectural style may *be* or *imply* a
> particular programming paradigm;  consideration of that issue has been
> particularly helpful to me in understanding and quantifying certain
> things about REST.

OK, this is certainly reasonable. But I like to think of using REST as being
something similiar to the using the relational database model. Does
accessing a relational database imply any one particular programming
paradigm to you? From experience, I would certainly say that it doesn't
imply OO but that doesn't prevent me from using it usefully from OO
languages. REST is unique when compared to programming languages (simply
because it isn't a programming language but rather an architectural style as
you pointed out) and needs to be evaluated independently from them. Maybe it
will be easier to use a RESTful architecture from certain types of languages
but that doesn't necessarily mean that REST should be considered as being of
that language's paradigm.

> > >    "OOP is to CORBA as ??? is to the Web."
> >
> > OOP and CORBA are not related exlusively to all other programming
paradigms
> > or architectural styles. It's just as possible to develop a monolithic
> > procedural API using CORBA as it is an object oriented one. The same
goes
> > for REST.
>
> I think you're missing something important, but can't quite put my
> finger on how to explain it to you.

If I am missing something, then please don't stop trying to beat it into me
until I finally get it. :-)

Jason








-----------------------------------------------------------------------------------
Post ID:1179
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-05-01 21:22:32
Subject:RE: [rest-discuss] Re: REST
Message:


> -----Original Message-----
> From: Jason Diamond [mailto:jason@injektilo.org] 
> Sent: 01 May 2002 21:03
> Todiscuss@yahoogroups.com
> Subject: Re: [rest-discuss] Re: REST
> 
> 
> Paul already made the comment that comparing REST to 
> programming language paradigms is like comparing apples to 
> elephants. The Web is not a programming language. Why would 
> you even want to make that comparison?
 
Right, the Web is not a programming language; also the Web != REST.
REST, specifics aside, is a computing paradigm (disclosure: I accept the
notion of "REST Architectural Style", but not "REST Architecture"). May
there not be value in comparing the REST paradigm with programming
paradigms?

Bill de hra







-----------------------------------------------------------------------------------
Post ID:1180
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-05-01 21:22:32
Subject:RE: [rest-discuss] Re: GoogleAPI is Rest?
Message:


> -----Original Message-----
> From: Lucas Gonze [mailto:lucas@...] 
> Sent: 01 May 2002 18:20
> To: Paul Prescod
>
> > How does SOAP-RPC handle "event models"????
> 
> By allowing SOAP-RPC to be transported over event protocols 
> such as JMS, and by having a more fleshed out model for 
> intermediaries. 

Are you saying the processing style depends on the underlying protocol
SOAP is carried over/through? I thought SOAP was supposed to be a
protocol.

Bill de hra







-----------------------------------------------------------------------------------
Post ID:1181
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-05-01 21:29:37
Subject:RE: [rest-discuss] Re: REST
Message:


> -----Original Message-----
> From: Jeff Bone [mailto:jbone@...] 
> 
>    "OOP is to CORBA as ??? is to the Web."

Hypertext.

Bill de hOra







-----------------------------------------------------------------------------------
Post ID:1182
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-01 21:43:43
Subject:Re: [rest-discuss] Re: GoogleAPI is Rest?
Message:

I'm not Lucas. 8-)

On Wed, May 01, 2002 at 10:22:32PM +0100, Bill de h�ra wrote:
> Are you saying the processing style depends on the underlying protocol
> SOAP is carried over/through? I thought SOAP was supposed to be a
> protocol.

Those two things aren't inconsistent.  WebDAV is both a protocol and
an HTTP extension.  SOAP can be used in the same way.  Indeed, this is
the only practical way in which SOAP can be used in a REST friendly
manner (the other way being to recast REST semantics on top of SOAP -
a horrible, horrible idea).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1183
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-05-01 21:41:54
Subject:RE: [rest-discuss] Re: REST
Message:

> May
> there not be value in comparing the REST paradigm with programming
> paradigms?
>
> Bill de hra

Rethinking problems in terms of resource modelling, I always think of the
way that SQL forces you to collapse iterative algorithms into single
statements.

- Lucas








-----------------------------------------------------------------------------------
Post ID:1184
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-05-01 21:52:37
Subject:RE: [rest-discuss] Re: GoogleAPI is Rest?
Message:


> -----Original Message-----
> From: Mark Baker [mailto:distobj@...] 
>
> I'm not Lucas. 8-)

?

 
> On Wed, May 01, 2002 at 10:22:32PM +0100, Bill de hra wrote:
> > Are you saying the processing style depends on the 
> underlying protocol 
> > SOAP is carried over/through? I thought SOAP was supposed to be a 
> > protocol.
> 
> Those two things aren't inconsistent.  WebDAV is both a 
> protocol and an HTTP extension.  SOAP can be used in the same 
> way.  Indeed, this is the only practical way in which SOAP 
> can be used in a REST friendly manner (the other way being to 
> recast REST semantics on top of SOAP - a horrible, horrible idea).
 
Maybe they're not exclusive, I'm not sure. A (network) protocol is
interesting insofar as it's a useful abstraction (of the network).
Having to think about SOAP and JMS, or SOAP and HTTP or SOAP and BEEP,
means I can't just think my application and SOAP, I may as well think
about App and JMS or App and HTTP or App and BEEP, and eliminate
superfluous noise. This is like C programming; machine power is traded
for programmer dissonance. Bad trade. I expect that programmers will
just think about the SOAP abstraction, bedamned the supporting protocol.

Bill de hOra







-----------------------------------------------------------------------------------
Post ID:1185
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-01 22:29:32
Subject:Re: [rest-discuss] Re: GoogleAPI is Rest?
Message:

Bill de h�ra wrote:
> 
>...
> 
> Are you saying the processing style depends on the underlying protocol
> SOAP is carried over/through? 

Absolutely!

> .... I thought SOAP was supposed to be a
> protocol.

Key word: "was".

Seriously, SOAP may meet some technical definition for "protocol" but
I'd say it is really some kind of meta-protocol or protocol framework or
"XML vocabulary with processing expectations" or something.

That's "SOAP in general" as opposed to "SOAP-RPC over HTTP" which is
really a very concrete RPC protocol.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1186
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-05-01 22:34:04
Subject:etcon BOF?
Message:

Is there anything to accomplish via a BOF at ETCON?  IE, a convincing
agenda?









-----------------------------------------------------------------------------------
Post ID:1187
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-01 22:49:37
Subject:Re: [rest-discuss] Re: GoogleAPI is Rest?
Message:

Mark Baker wrote:
> 
> I'm not Lucas. 8-)
> 
> On Wed, May 01, 2002 at 10:22:32PM +0100, Bill de h�ra wrote:
> > Are you saying the processing style depends on the underlying protocol
> > SOAP is carried over/through? I thought SOAP was supposed to be a
> > protocol.
> 
> Those two things aren't inconsistent.  WebDAV is both a protocol and
> an HTTP extension.  

But WebDAV is only designed to run over HTTP or perhaps over protocols
with very HTTP-like characteristics. If you use a WebDAV library you
know what to expect in terms of synchronousness, message patterns, etc.
SOAP does not predefine message patterns independent of the transport.
One transport could be synchronous and the next asynchronous. One
unidirectional and the next bidirectional. One transport could have an
addressing model and another lack one. etc.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1188
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-01 23:42:27
Subject:XML Headers
Message:

One of the most striking advantages of SOAP over HTTP is the XML Headers
with clear intermediary targeting and requirements on understanding.

Some thoughts are here:

 * http://www.prescod.net/xml/envelopes

Now, I'd like to know what stands between HTTP and full XML headers with
mustUnderstand and intermediary targeting etc. Now looking at the
following productions from the HTTP specification, it seems to me that
lightly encoded XML is in fact legal in an HTTP header:

       message-header = field-name ":" [ field-value ]
       field-name     = token
       field-value    = *( field-content | LWS )
       field-content  = <the OCTETs making up the field-value
                        and consisting of either *TEXT or combinations
                        of token, separators, and quoted-string>
       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
       qdtext         = <any TEXT except <">>

So XML in a header could not use the " character. That seems a minor
loss to me, because XML treats ' and " interchangably in markup and " in
content can always be replaced with ".

Am I missing something major?

mustUnderstand would have to be handled using M-GET as described here:

 * ftp://ftp.isi.edu/in-notes/rfc2774.txt

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1189
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-02 00:38:03
Subject:Re: [rest-discuss] etcon BOF?
Message:

I submitted a description for an ETCON BOF called "Alternative Web
Services Architectures". I don't think that in one or two hours we can
make huge progress towards understanding each other but it may help to
hash out a few issues.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1190
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-02 00:50:57
Subject:Re: [rest-discuss] Re: GoogleAPI is Rest?
Message:

> Rather than argue over the details of what is and isn't available, lets
> focus on building.

> Maybe evangelizing is a part of the work.  For example, make the point
> that service description tools, specifically Visual .NET, apply equally to
> REST development.  So let's do it.  but let's not fool ourselves into
> thinking that once somone embraces the one true faith they'll find full
> featured toolkits.

Well put. What are the missing pieces?
 - discovery (wsdl-style declarative formats, intellisense-tool friendly
stuff, etc.)
 - clients (do we need to write new 'resource modelling friendly' clients in
all the languages or can we re-user protocol API libraries?)

I don't think we need asynch stuff immediately, since there isn't an
existing body of resource that support it to hook up to.

What else?






-----------------------------------------------------------------------------------
Post ID:1191
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-02 01:12:22
Subject:Re: [rest-discuss] Re: GoogleAPI is Rest?
Message:

On Wed, May 01, 2002 at 10:52:37PM +0100, Bill de h�ra wrote:
> Maybe they're not exclusive, I'm not sure. A (network) protocol is
> interesting insofar as it's a useful abstraction (of the network).
> Having to think about SOAP and JMS, or SOAP and HTTP or SOAP and BEEP,
> means I can't just think my application and SOAP,

But that's the rub.  The Web *is* your application.  Or more precisely,
to use the Web, you have to form your application in the shape of the
Web; hypertext.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1192
Sender:"sa3ruby" <rubys@...>
Post Date/Time:2002-05-02 01:09:09
Subject:Re: XML Headers
Message:

You may or may not find the following useful: 
http://www.hpl.hp.com/personal/John_Barton/HTTP-A/DIME/Comparison%
20of%20MIME%20and%20DIME.htm







-----------------------------------------------------------------------------------
Post ID:1193
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-02 11:39:44
Subject:[Fwd: Re: [xml-dev] SOAP and the Web]
Message:

I wanted to emphasize this "no query" point for anyone on rest-discuss
new to REST.

-------- Original Message --------
Subject: Re: [xml-dev] SOAP and the Web
Date: Thu, 02 May 2002 04:27:10 -0700
From: Paul Prescod <paul@...>
To: Francis Norton <francis@...>
CC: xml-dev <xml-dev@...>
References: <2C61CCE8A870D211A523080009B94E430752B3C9@HQ5>
<3CD01C16.80606@...> <3CD06157.11DC0617@...>
<3CD113B5.9060505@...>

Francis Norton wrote:
> 
>...
> I know I have a bit of a blind-spot here. What is the canonical example
> of a "resource" v. a "representation"? Say I wanted to look up trains
> from London to North Berwick - is the URL of the query a representation
> of the timetable resource?

The timetable is a resource. A URL is never a representation: the
representation is the stuff that gets sent across the wire: the XML or
XHTML or whatever. It is what you GET and PUT.

Here's the radical bit: ideally there would be *no* query in this
system. Let's say the XML was organized like this:

<routes>
   <route from="http://train.com/cities/London" 
	to="http://trains.com/cities/NorthBerwick" 
	href="http://trains.com/routes/LondonToNorthBerwick"/>
   
</routes>

Then you have the document:
http://trains.com/routes/LondonToNorthBerwick

It has:

<times>
  <time>ISODATE1</time>
  <time>ISODATE2</time>
  <time>ISODATE3</time>
  <time>ISODATE4</time>
  <time>ISODATE5</time>
</times>

Now you get into this service through the "routes" document above,
follow the hyperlink to the "ondonToNorthBerwick" document and find the
information you need. You've never done a query and you've never had to
send complex XML.

When you do it this way:

 1. the client's access to the data is not mediated by any API or
messaging interface. This is very much in the XML spirit of "give me the
data and I (the client) will figure out what to do with it.

 2. you cannot generate a "bad query" by trying to get from London,
Ontario to North Berwick, Scotland (nor North Berwick Maine to London,
England!). If there is no link for that route then you can't get there.

 3. the client can discover routes, rather than merely generate them and
test whether they exist or not. For instance it could say: "hmmm. I
notice a route from London to Glasgow and Glasgow to North Berwick.
Maybe this is also interesting to my user."

 4. the standardization of the "routes" format and the "times" format
can actually be fairly disconnected. For instance we might use the same
"times" format for airlines and trains but the "routes" format might be
different. Or else we could use XML extensibility features to share both
but have different details on both.

 5. the server can easily serve these as either dynamic OR static
documents. The performance advantages to the latter should be obvious. 

>... That seems simple enough, but what is the
> representation that I send - one representation of the train route from
> London to North Berwick, or a combination of representations for the
> locations of London and North Berwick?

It's like asking how you model objects in an OO systems. I guess I would
tend towards breaking things apart rather than combining them but that's
just a very rough rule of thumb. But note that the question is really
how you break out the *resources*. Representations just represent
resources on the wire.

> I like the way that W3C specs come with "this version" and "latest
> version" links at the top, and I find it frustrasting that I can't refer
> to resources in Visual SourceSafe in the same way, so I think I'm making
> progress...

Yep, using hyperlinks like that is very resty. Visual SourceSafe
probably has an "API" that allows you to access older versions through
code. That's a very "SOAP-y" way to look at it.

>....
> >XForms *does* have GET support.
> >
> Can XForms understand GET or POST Web Services described in WSDL? I
> imagine WSDL is a bit short on form layout details, but does XForms have
> helpful deaults?

XForms does not know anything about WSDL. After all the former is a W3C
specification and the latter has only just begun its standardization
process. And anyhow, they are kind of parallel specifications. WSDL is
used to map the interface to a web site into an interface suitable for
programmers. XForms is used to map it into an interface suitable for
humans. There wouldn't be that much in common between them other than
the XML Schema.

 Paul Prescod

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>






-----------------------------------------------------------------------------------
Post ID:1194
Sender:"sa3ruby" <rubys@...>
Post Date/Time:2002-05-02 13:00:44
Subject:Re: etcon BOF?
Message:

--- In rest-discuss@y..., Lucas Gonze <lucas@g...> wrote:
> Is there anything to accomplish via a BOF at ETCON?  IE, 
> a convincing agenda?

I posted a few suggestions at
http://www.oreillynet.com/cs/weblog/view/wlg/1360







-----------------------------------------------------------------------------------
Post ID:1195
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-05-02 13:59:31
Subject:Re: [rest-discuss] etcon BOF?
Message:

> I submitted a description for an ETCON BOF called "Alternative Web
> Services Architectures". I don't think that in one or two hours we can
> make huge progress towards understanding each other but it may help to
> hash out a few issues.
>
>  Paul Prescod

Care to run a BOF on any of the below?  Not sure which one "Alternative
Web Services Architectures" is...

* "Standardization of Web Services"
* "Implementing REST" (a tutorial)
* "Choosing the Right Web Services Design for your
Business."

Question: what issues need to be covered in a tutorial?
Strawmen suggestions:
* gross overgeneralizations taken from The Thesis
* something about URIs
  Is there anything to say about this?
* semantic meaning of methods; PUT/POST/GET/DELETE
* resource modeling
  define resource and representation
  content negotiation
* using status codes aside from 200
* where XML fits in
  SOAP as payload format rather than RPC packager

- Lucas








-----------------------------------------------------------------------------------
Post ID:1196
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-02 15:05:37
Subject:Re: [rest-discuss] etcon BOF?
Message:

Lucas Gonze wrote:
>
> * using status codes aside from 200

FYI (not to imply that you are suggesting otherwise, but I have seen others
comment on this)

http://www.w3.org/TR/SOAP/#_Toc478383529

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1197
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-02 16:48:06
Subject:More thoughts about queries
Message:

I want to point out a couple of subtleties about queries.

I think that queries are a fallback position from hypertext. As I said
earlier, hypertext has advantages and the primary one is that it is more
discoverable and navigable than a query (or API or messaging interface
or...).

I do think that queries are an important optimization. Sometimes finding
out equivalent information through hypertext would take significant
effort. For instance in the Google case, they have so many word indexed
that for bandwidth reasons their hypertext "tree" would probably have to
be something like this:

p
 pr
   pre
    pres
     prescod
      prescod+p
       prescod+pa
        prescod+paul

They could of course us balancing algorithms to minimize the size of it
but still it would take several back and forth messages to get to the
point where we have the information available from:

http://www.google.com/search?q=prescod+paul

This hypertext view may be too slow for much real-world use. But on the
other hand, the hypertext view gives the client access to all kinds of
interesting information. For instance by spidering "prescod" I can find
out all words associated with my name. I could pretty easily find
GoogleWhacks that use my name. ;) I could scan for first names to find
other Prescods. The information available in the hypertext version is a
strict superset of the information available in the query version, but
navigating it may be too inefficient. So I think that in many
circumstances, both views are warranted.

Google might also want to have the query view be a free service and the
navigable view be something that people pay to use for data mining.

Other opinions?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1198
Sender:Seth Johnson <seth.johnson@...>
Post Date/Time:2002-05-02 22:26:59
Subject:URGENT ALERT: Broadband = "Information Service" Nonsense -- Comments Needed
Message:

Sorry, but this is really late notice.  Tomorrow is the last
day for comments on the FCC's proposal to call the Internet
an "information service" for the entrenched broadband
interests.  Ostensibly, this decision is being made in
preference over classifying broadband internet as a
"communications medium," which would place it under
regulations like those phone companies are subject to.  It
is therefore being characterized as a decision for
deregulation versus regulation.

Anybody who can, PLEASE send in a note saying this is not a
question of whether regulation or deregulation is better
policy (this is just a smokescreen) -- it's a question of
the nature of the online medium:  Is it a "content" delivery
system, or a communications medium characterized by its
fundamental two-way protocols, one which brings profound new
capabilities to all citizens?

*Please* send even just a short note to the FCC at
ecfs@....

If you know any other constituencies that would want to put
a word in on this, please let them know.

From Dave Farber's Interesting People list,
farber@....

Seth Johnson


-------- Original Message --------
Subject: IP: : Comment on NPRM 02-33
Date: Thu, 2 May 2002 15:32:22 -0500
From: "David Farber" <dfarber@...>


-----Original Message-----
From: "David S. Isenberg" <isen@...>
Date: Thu, 02 May 2002 16:13:48 
To: dave@...
Subject: Comment on NPRM 02-33


Dave,

This is the comment opposing FCC Notice of Proposed
Rulemaking (NPRM) 02-33 that I told you I'd write.  NPRM
02-33 threatens to turn back the network architecture  clock
to pre-Internet days.  Please distribute it via IP as soon
as you can -- the  deadline for comments is tomorrow, and
I'd like as many IPers as possible to comment.

IPers -- You can read the original NPRM at
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-02-42A1.doc

FCC comments should follow the form below.  Email them to
the FCC's Electronic Comment Filing System: ecfs@....


ECFS - E-mail Filing
<PROCEEDING>	02-33
<DATE>		5/2/02
<NAME>		David S. Isenberg
<ADDRESS1>	112 Orchard Street
<ADDRESS2>
<CITY>		Cos Cob
<STATE>	CT
<ZIP>		06807
<LAW-FIRM>	none
<ATTORNEY>	none
<DOCUMENT-TYPE>CO
<PHONE-NUMBER>	203-661-4798
<DESCRIPTION>  Email Comment
<CONTACT-EMAIL>isen@...
<TEXT> 

I am writing to oppose the reasoning behind NPRM 02-33,
"Appropriate Framework for Broadband Access to the Internet
over Wireline Facilities", because I am afraid that treating
broadband Internet access as an information service (as
proposed by NPRM 02-33) would deprive United States citizens
of the single most important feature of the Internet that
has made it such a runaway success over the last decade.

Let me introduce myself.  I have a Ph.D. in Biology from the
California Institute of Technology, where I studied human
speech.  I spent 12 years, 1985-1998, at AT&T Bell Labs,
where I served as Distinguished Member of Technical Staff. 
Today, I make my living as an independent commentator on
telecommunications.  While I serve on numerous advisory
boards and have numerous clients, I am beholden to no
commercial interests.  I am writing as a concerned citizen
of the United States, and I am writing with hope that recent
great advances in communications technology -- and, more
importantly, in network architecture -- will become
available to all.

In my understanding, "access" involves connecting my
computer (and other digital communications devices) to the
Internet.  "Information" is quite different -- information
is in the ones and zeros that enter my computer to be
processed by it.  Information can flow into my devices over
a variety of "access" -- over a wire, over a cable, over an
optical fiber, or through the air (either as radio-frequency
energy, or as light-wave energy).  That is, the same
sequence of ones and zeros can enter my computer by any of
these access methods.  So to equate "access" with
"information", as does NPRM 02-33, is simply incorrect.

It was not always so.  The telephone network was developed
to deliver one kind of information -- the human voice.  It
was engineered for voice, and it gave access to voice. 
Everything else that it carried (e.g., touch tones, modem
signals, signalling information to set up telephone calls)
was either an exception, or an adjunct to voice telephony. 
The wire that came into the house could not be distinguished
from the service it provided.  It was the same for
television and radio -- each had its own dedicated
infrastructure (be it a wire or a frequency band) to carry a
specific type of information.

The great advance of the Internet was that its fundamental
architecture separated "access" from "information".  Any one
of the various forms of access to the Internet puts one in
touch with an infinite array of information.  Furthermore,
providers of this information (information service
providers) do not own special infrastructure -- all they
need is a server and any of the several methods of Internet
access.  As a result, the Internet is wide-open to
innovation, and we have applications and services like
email, Web browsing (in all its manifestations), ecommerce,
Internet telephony, streaming audio and video, chat and
instant messaging.  

Not a single one of these information (and communications)
services was brought to market by a telephone company or a
television company or a cable operator or a broadcast radio
network.  No, access is a fundamentally different business
from "information service".  To equate "broadband access"
and "information service" -- as NPRM 02-33 proposes -- would
be a horrendous step backwards.

Without separation, "broadband access" as an "information
service" is likely to resemble the failed Interactive TV
experiments of the early 1990s.  TV-on-speed is not "the
Internet" -- and vice versa.

David I
-------


************      WE HAVE MOVED!      ***************
New Snail-Mail Address, effective March 1, 2002:
isen.com
112 Orchard Street
Cos Cob CT 06807
New phone: 203-661-4798
*--------------------isen.com----------------------* 
David S. Isenberg         isen@... 
isen.com, inc.            888-isen-com (inside US) 
http://isen.com/          203-661-4798 (direct line) 
*--------------------isen.com----------------------* 
      -- The brains behind The Stupid Network -- 
*--------------------isen.com----------------------*

For archives see:
http://www.interesting-people.org/archives/interesting-people/







-----------------------------------------------------------------------------------
Post ID:1199
Sender:Massimo Paolucci <paolucci+@...>
Post Date/Time:2002-05-02 23:25:50
Subject:Re: [agents] URGENT ALERT: Broadband = "Information Service" Nonsense -- Comments Needed
Message:






-----------------------------------------------------------------------------------
Post ID:1200
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-03 00:32:21
Subject:Re: [rest-discuss] Re: etcon BOF?
Message:

[mailed and posted: http://www.oreillynet.com/cs/weblog/view/cs_msg/7174]

I think talking about whether REST applies to long lived conversations would
be a great topic.
There has been discussion about this on the REST forums, but it would be
good to go over it again.
As for HTTP, there is a response code of '202 Accepted' which is used to
indicate that the request is being processed asynchronously - which leads to
the 'five days for a response' situation. What hasn't happened is for a
large number of people to implement a standard approach for sending that
final response message to the sender - but there are lots of ways to do that
(take a look at the REST discussion groups).

Mike



----- Original Message -----
From: "sa3ruby" <rubys@...>
To: <rest-discuss@yahoogroups.com>
Sent: Thursday, May 02, 2002 6:00 AM
Subject: [rest-discuss] Re: etcon BOF?


> --- In rest-discuss@y..., Lucas Gonze <lucas@g...> wrote:
> > Is there anything to accomplish via a BOF at ETCON?  IE,
> > a convincing agenda?
>
> I posted a few suggestions at
> http://www.oreillynet.com/cs/weblog/view/wlg/1360
>
>







-----------------------------------------------------------------------------------
Post ID:1201
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-03 02:02:04
Subject:Re: [rest-discuss] Re: XML vs RDF
Message:

I'll try to keep this REST-focused.

On Wed, May 01, 2002 at 10:20:27AM -0700, Paul Prescod wrote:
> > Also, I think the XML syntax for the RDF model is a horrible, nasty,
> > unnecessary thing.  It should be killed.
> 
> You mean that RDF should not be XML-expressible at all? Use
> s-expressions? Or do you mean you dislike all of the weird
> minimizations?

I dislike that the triple structure of the RDF model is being
shoehorned into a tree based syntax.  It's unnatural, and it
shows.

> > I've heard talk of adorning schemas with the information necessary to
> > construct RDF.  I like this in theory, though I fear for the practical
> > implications; primarily, additional network round-trips.
> 
> The relationship between documents and schemas will typically be many to
> one so you can do a lot of caching of schemas. Sophisticated RDF use is
> already dependent on schemas (RDF schemas) to get subclassing and
> inferencing information, isn't it?

Yes, but RDF Schema is so general that it will likely be a built-in
for all processors.  The same can't be said of vCard-in-XML, or
Docbook, etc..

That's the issue, I believe.  Schemas can indeed be cached, but that
you'd need to get them in the first place is what hurts.

> > For now, that's clearly true.  As more RDF features are integrated into
> > tools, the cost of doing this will come down.
> 
> I don't see it as a tools cost but as a readability cost. Sprinkling all
> of that RDF junk through my document is, imo, as unacceptable as
> sprinkling SOAP voodoo into my messages. I guess it boils down to: I
> think you optimize the XML for readability and processability *as XML*
> and then figure out how to get the benefits of protocols and metadata
> engines etc. You think that RDF is primary and that XML is just a
> container for it.
> 
> But if that's true then RDF should use an optimized-for-RDF syntax, not
> XML at all.

Mostly, yes.  Sometimes you need the additional value that XML adds;
Unicode, xml:lang, xml:space, xml:base, etc..

From a purely REST POV, I want to use content negotiation to retrieve
RDF (N3, but XML if that's required) representations of resources.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1202
Sender:Seth Johnson <seth.johnson@...>
Post Date/Time:2002-05-03 10:51:09
Subject:WSDL binding for DIME
Message:

(Forwarded from DIME Discussion list,
DIME@...)

-------- Original Message --------
Date: Thu, 2 May 2002 22:45:12 -0700
From: Simon Fell <soap@...>


I'm surprised this didn't get announced here, but here's the
doc.

http://gotdotnet.com/team/xml_wsspecs/dime/WSDL-Extension-for-DIME.htm

BTW, you may want to fix the links in the ToC.

Cheers
Simon
www.pocketsoap.com







-----------------------------------------------------------------------------------
Post ID:1203
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-03 20:11:51
Subject:Re: [rest-discuss] Re: XML vs RDF
Message:

Mark Baker wrote:
> 
>...
> 
> Yes, but RDF Schema is so general that it will likely be a built-in
> for all processors.  The same can't be said of vCard-in-XML, or
> Docbook, etc..
> 
> That's the issue, I believe.  Schemas can indeed be cached, but that
> you'd need to get them in the first place is what hurts.

Aren't you comparing apples and oranges? RDF Schema is a schema
language, like RELAX NG or XML Schema. AFAIK, individual RDF
vocabularies have individual schemas expressing their type relationships
and inferencing rules, just as individual XML vocabularies have
individual schemas.

As I've heard you describe your idealized RDF bootstrapping process it
involves recognizing that you don't understand an assertion and then
looking up the definition and if you don't understand that you look up
the definition of that and if you don't, etc. etc. So whereas the XML
schema process is typically "flat" (barring a lot of inheritance or a
very modularized schema), the evaluation of an RDF expression could
require very deep recursion.

>...
>From a purely REST POV, I want to use content negotiation to retrieve
> RDF (N3, but XML if that's required) representations of resources.

Maybe in the long term. In the medium term I think it is more practical
to do the "generic XML"->RDF transformation on the client side so I am
on the lookout for technologies that will allow that.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1204
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-03 21:33:31
Subject:"Extreme Web Services"
Message:

Here is my rough counter-part to this document:

http://www.extremeprogramming.org/rules.html

I notice that Microsoft co-opted the term "extreme web services" in a
talk in February ... oh well.

1. Loose coupling of implementations: Clients should not need to know
anything about the object models of services and vice versa. It is
therefore almost never appropriate to generate an interface definition
for an extreme service from existing implementation code. The interface
should be chosen to maximize interoperability and extensibility, not to
simplify implementation.

2. No Implicit Resources: If the server has some information that it is
willing to make available to the client then that information should be
exposed as part of a URI-named resource. The client should not need to
submit XML-encoded "parameters" or a "query" to get the information.
The means for getting the URI is discussed in other points.

3. No Implicit State: If the client and server depend on a shared piece
of information in order to communicate effectively then that piece of
information should be given an address (usually by the server) and
exposed as a web resource. Clients should be considered entirely 
stateless. The only thing they remember from one message to another are
things defined by the protocol, like authentication tickets -- not 
things defined by the application, like purchase order numbers.

4. No abuse of protocols or formats: Knowingly violating either the
letter or the spirit of specifications degrades the value of those
specifications ot you and others. Most often if you read the
specifications you will learn that the creators anticipated your problem
and made a provision for it. If not, the chances are strong that your
problem is out of scope for the protocol or format and maybe you should
choose another one or invent your own.

5. Use standards where possible: HTTP is the standard Web protocol for
the manipulation of information. XML is the standard Web representation
for information. RDF is the standard representation for metadata. By
default, you should use these. Use something else only when you have
researched these closely and have a clear sense of a limitation of one
of these. Using something non-standard will be expensive for those
building client applications that will use your service. You should
explicitly justify that cost.

7. Use URIs (typically URLs) to name things: URIs are better names than
numbers, UUIDs or other non-standard naming conventions. The first
virtue of URIs is that they are derived from a managed namespace so name
clashes can be avoided merely by choosing only to use names that we each
own. For instance if two companies merge their purchase orders will be
uniquely named because the two companies would have formerly had unique
domain names. Whereas this is not necessarily true of integer-named
purchase orders. Second, URIs provide an easy way to associate metadata
(or "plain data") with the named entity. Even if you do not need that
today you may need it later.

8. Use hyperlinks (URIs embedded in XML or HTTP headers) to guide the
client through the service: Do not require it to build up state on the
client side. The state should be encapsulated into resources that the
client creates. As long as it keeps track of one URI, it should be
possible for it to re-discover all of the relevant state merely by
following hyperlinks. A query is only better than hyperlinks as an
optimization and when the client is likely to have a priori knowledge
that must be plugged into the service (e.g. a dress size).

9. Given the choice between a generic interface and a specific one, use
the generic one if your goal is to maximize interoperability: It may
take more effort to re-organize your information into the generic
interface but that effort will usually pay off for your clients. For
example, XML is a generic data representation and is sometimes not quite
as efficient as application-specific notations. Nevertheless it is
usually the right choice because the client can implement one XML parser
instead of hundreds of parsers for application-specific notations. The
same sort of argument can be made for HTTP.

10. Disclaimer meta-rule: the real world is complicated and there are
many broken
software products and business environments out there. Break rules when
you need to do so -- but understand the costs of breaking them and
document your reasons.






-----------------------------------------------------------------------------------
Post ID:1205
Sender:Dan Brickley <danbri@...>
Post Date/Time:2002-05-04 19:19:20
Subject:Re: [rest-discuss] "Extreme Web Services"
Message:

[snip]

minor nitpick: the UUID vs URI characterisation is a bit bogus, since
there is (or could be -- forget the status) an easy way of writing UUID
identifiers in URI syntax. You might say that URIs are good, but some
kinds of URI are more good than others... ;-)

Dan


-- 
mailto:danbri@...
http://www.w3.org/People/DanBri/







-----------------------------------------------------------------------------------
Post ID:1206
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-05-04 19:50:35
Subject:UUIDs in URIs (was Re: [rest-discuss] "Extreme Web Services")
Message:

On Sat, May 04, 2002 at 03:19:20PM -0400, Dan Brickley wrote:
> 
> minor nitpick: the UUID vs URI characterisation is a bit bogus, since
> there is (or could be -- forget the status) an easy way of writing UUID
> identifiers in URI syntax.

IIRC it is

  urn:uuid:rqio502u82qy8ervthkgnxiyw349$&*%()&*%$&*$^((%^&(*asdjoaw

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:1207
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-04 20:12:05
Subject:Re: UUIDs in URIs (was Re: [rest-discuss] "Extreme Web Services")
Message:

Dan Brickley wrote:
>
> minor nitpick: the UUID vs URI characterisation is a bit bogus, since
> there is (or could be -- forget the status) an easy way of writing UUID
> identifiers in URI syntax.

http://www.globecom.net/ietf/draft/draft-kindel-uuid-uri-00.html

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1208
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-06 19:43:19
Subject:Re: [rest-discuss] "Extreme Web Services"
Message:

Yes, excellent point! I really mean "resolvable URIs" which at one time
were termed "URLs". I gues you could establish a hierarchy of goodness:
names -> universal names -> universally resolvable names.

Dan Brickley wrote:
> 
> [snip]
> 
> minor nitpick: the UUID vs URI characterisation is a bit bogus, since
> there is (or could be -- forget the status) an easy way of writing UUID
> identifiers in URI syntax. You might say that URIs are good, but some
> kinds of URI are more good than others... ;-)
> 
> Dan
> 
> --
> mailto:danbri@...
> http://www.w3.org/People/DanBri/






-----------------------------------------------------------------------------------
Post ID:1209
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-06 20:41:09
Subject:Re: [rest-discuss] "Extreme Web Services"
Message:

On Mon, May 06, 2002 at 12:43:19PM -0700, Paul Prescod wrote:
> Yes, excellent point! I really mean "resolvable URIs" which at one time
> were termed "URLs". I gues you could establish a hierarchy of goodness:
> names -> universal names -> universally resolvable names.

Wait a minute!  DDDS will make URNs resolvable.  Should we call them
URLs now too. 8-)

<ducks/>

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1210
Sender:tony_hammond@...
Post Date/Time:2002-05-07 10:35:21
Subject:Re: [rest-discuss] "Extreme Web Services"
Message:

We call them URIs. :)

Tony




                                                                                                                   
                    Mark Baker                                                                                     
                    <distobj@acm.o       To:     Paul Prescod <paul@...>                                   
                    rg>                  cc:     Dan Brickley <danbri@...>, "rest-discuss@yahoogroups.com"      
                                          <rest-discuss@yahoogroups.com>                                           
                    06/05/2002           Subject:     Re: [rest-discuss] "Extreme Web Services"                    
                    21:41                                                                                          
                                                                                                                   
                                                                                                                   




On Mon, May 06, 2002 at 12:43:19PM -0700, Paul Prescod wrote:
> Yes, excellent point! I really mean "resolvable URIs" which at one time
> were termed "URLs". I gues you could establish a hierarchy of goodness:
> names -> universal names -> universally resolvable names.

Wait a minute!  DDDS will make URNs resolvable.  Should we call them
URLs now too. 8-)

<ducks/>

MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/











-----------------------------------------------------------------------------------
Post ID:1211
Sender:Holden Glova <dsafari@...>
Post Date/Time:2002-05-07 10:42:05
Subject:Trouble putting it to REST
Message:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

I'm having a hard time trying to make this functionality RESTful, for some 
reason I can't stop visualizing the solution as an RPC style one. Here is an 
outline of what I am trying to do. I have a list of package names (approx 
100), and I would like to allow users to search through these packages by 
providing a regular expression. Of course the package names that match the 
regex will be returned back to the client. So let me try and walk through how 
my mind is thinking about the REST way of doing this.

I am looking for a resource name that the client is interested in, so I think 
possibley something like this.

GET http://somehost.org/package/names

The above would be fine (wouldn't it?) if I just wanted to get all the 
packages back that where in the entire database, however I want to filter 
them so I'm thinking that I need to add some sort of parameter(s) to it. This 
is where my thinking breaks down because now I think it starts to look RPC 
style. Here is what I come up with

GET http://somehost.org/package/names?like=regex

The reason I think that looks RPC'ish is because to me it looks like I am 
asking for some sort of operation as opposed to a resource.

Any thoughts/suggestions/opinions are all welcome. Many thanks in advance.

- -- 
Signed,
Holden Glova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE81699+mF116Lw2cQRAmrqAJ94aE9+LSaEE1BNuiEJlCRG4XQEoQCdF8bf
OkbQ571fD3kb2Jx29z7cZek=
=u3Bc
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:1212
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-07 16:04:25
Subject:Re: [rest-discuss] Trouble putting it to REST
Message:

Holden Glova wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello all,
> 
> I'm having a hard time trying to make this functionality RESTful, for some
> reason I can't stop visualizing the solution as an RPC style one. Here is an
> outline of what I am trying to do. I have a list of package names (approx
> 100), and I would like to allow users to search through these packages by
> providing a regular expression. Of course the package names that match the
> regex will be returned back to the client. So let me try and walk through how
> my mind is thinking about the REST way of doing this.

As I've said a few times recently, in my personal opinion there is
nothing wrong with a query as an optimization. I think that your
solution is absolutely fine as long as:

 1. the list of 100 package names *is* exposed somewhere as a
URI-addressable list for a client that would rather do iterative
discovery rather than query-based discovery. You've already said that
you'll do this.

 2. each package has its own URI for hyperlinking both in the list
described in 1. and in the query results that you are already working
on. For client-simplicity, you should probably use the same XML
vocabulary for the query results as for the "full list".

 3. if packages can be mutated or deleted, you use the appropriate HTTP
method and not queries.

So overall my opinion is that you are on the right track!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1213
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-07 16:48:56
Subject:Re: [rest-discuss] Trouble putting it to REST
Message:

----- Original Message -----
From: "Holden Glova" <dsafari@...>
>
> I am looking for a resource name that the client is interested in, so I
think
> possibley something like this.
>
> GET http://somehost.org/package/names
>
>
> GET http://somehost.org/package/names?like=regex
>
> The reason I think that looks RPC'ish is because to me it looks like I am
> asking for some sort of operation as opposed to a resource.
>

These both are fine for what you are doing. A problem I always have
remembering that the two URI are two completely separate resources (from the
point of view of clients 'outside the interface') even though they look
similar.
The full list could just as easily have been
 GET http://somehost.org/package/names?all
or
 GET http://somehost.org/package/allnames
or whatever.

Something to remember is that even though http://somehost.org/package/names
is part of both URI, that doesn't make it 'the one resource'.
The second URI (with the query terms) is not 'the one resource' plus
parameters - it is a separate resource. You may have a singular data source
within your implementation (like a database) but outside your interface you
expose things as separate resources.
Kind of like creating a view in a database - which makes a query look like a
table.

So a more illustrative example (not that you should change your URIs) to
show that they are separate resources might be
 GET http://somehost.org/package/allnames
 GET http://somehost.org/package/names?like=regex









-----------------------------------------------------------------------------------
Post ID:1214
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-07 17:23:40
Subject:Re: [rest-discuss] Trouble putting it to REST
Message:

On Tue, May 07, 2002 at 10:42:05PM +1200, Holden Glova wrote:
> GET http://somehost.org/package/names

Without knowing any more than what you've described, I would personally
use;

http://somehost.org/packages/

and

http://somehost.org/packages/?namelike=regex

permitting individual packages to be identified by;

http://somehost.org/packages/2342343/

I don't see the need to bring "name" out as a separate sub-resource.
I see it more as an attribute of the package, not a resource.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1215
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-07 20:27:16
Subject:Re: [xml-dev] Is XML-REST more scalable than SOAP?
Message:

"Roger L. Costello" wrote:
> 
> I am just ramping up on REST.  Please forgive me if my
> questions/comments are naive.

Roger, detailed discussion should be redirected to the rest-discuss list
because people on xml-dev are tired of the repitition that arises from
teaching REST to new people as they become interested in it.

>...
> Now consider the case where web sites serve up XML not HTML (I shall
> refer to this as XML-REST).  Suppose that the XML is programmatically
> processed.  The HTTP methods (GET, POST, PUT, etc) provide a nice set of
> **access methods** for getting and putting the XML data.  Thus,
> **accessibility** is scalable as it is on the order of linear.  However,
> **processing** the XML data still needs customized code (just like
> machine processing of HTML requires custom code).  I therefore conclude
> that XML-REST is no more scalable than SOAP.

Yes, this is an important insight. But the linear factor is also
important. I believe that it is much easier to standardize XML
vocabularies within and between industries than it is to share APIs or
messaging interfaces or whatever you want to call them. HTML is merely
an extreme example of this. The widespread success of RSS is a second
example. (might be interesting to try to understand why RSS is so much
more popular on the "public Internet" than is XMLNews...) Obviously
"chemical ML" is going to be much less widespread than HTML but I have
much more hope that Bayer and 3M would share "chemical ML" than that
they would agree on a wire-protocol for describing chemicals. There are
a variety of reasons but one reason is that agreeing on a wire-protocol
is much closer to agreeing on a *business model* than is agreeing on an
XML vocabulary.

>...
> 
> How can we make XML-REST scalable?  One solution would be to require
> every web site to serve up the same type of XML documents, i.e., have a
> universal Schema that all XML documents conform to.  Obviously this is
> not a very attractive solution.  The other solution is to have web sites
> serve up documents whose meaning can be dynamically "discovered".  I
> believe that RDF is the only XML technology that enables dynamic
> understanding of content.  Thus, the cornerstone for a scalable,
> machine-processable web services architecture is:
> 
> 1. The HTTP access methods - GET, POST, PUT, etc
> 2. A dynamically understandable vocabulary, such as RDF.

Yes, this is the approach Mark Baker takes. As I am not (yet?) an RDF
"believer" I see it more as a spectrum: as we understand problem domains
more and more, we migrate more and more stuff from "the code" into
declarative formats that describe the data. RDF fans think that RDF is
the declarative "uber-format". We'll see. Maybe.

If they are wrong, I still expect dozens of declarative languages like
XML Query, XSLT etc. to mature into powerful tools for bootstrapping
understanding of a vocabulary. (consider for example an XSLT associated
with one industry standard purchase order vocabulary that translates it
into another PO vocabulary on demand -- easy to model in an
industry-neutral way with URIs and XML).

One reason I argue against the "standard web services" model because it
moves the very first bit of the problem from the domain of declarations
into the domain of code. I.e. to even get the data you need to write
code. That's a serious impediment to further exploration down the
declarative path. If XML Query turns out to be extremely wonderful and
powerful, this fork in the road should come into even greater focus.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1216
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-05-08 12:49:43
Subject:Re: [xml-dev] Is XML-REST more scalable than SOAP?
Message:

Thanks Paul.  I will subscribe to the REST list group.  BTW, in your Second
Generation Web Services article you mentioned that you would write another
article:

"In an upcoming article, I will
- describe in more detail how any web service can be transformed into a
URI-centric one;
- show an example of a successful, public, widely used web service that uses
this model today;
- discuss the role of SOAP in these sorts of web services;
- discuss reliability, coordination, transactions, asynchronicity, firewalls
etc. "

Have you completed this article?  I really liked the first article, and have
been eagerly awaiting the second one.   /Roger


Paul Prescod wrote:

> "Roger L. Costello" wrote:
> >
> > I am just ramping up on REST.  Please forgive me if my
> > questions/comments are naive.
>
> Roger, detailed discussion should be redirected to the rest-discuss list
> because people on xml-dev are tired of the repitition that arises from
> teaching REST to new people as they become interested in it.
>
> >...
> > Now consider the case where web sites serve up XML not HTML (I shall
> > refer to this as XML-REST).  Suppose that the XML is programmatically
> > processed.  The HTTP methods (GET, POST, PUT, etc) provide a nice set of
> > **access methods** for getting and putting the XML data.  Thus,
> > **accessibility** is scalable as it is on the order of linear.  However,
> > **processing** the XML data still needs customized code (just like
> > machine processing of HTML requires custom code).  I therefore conclude
> > that XML-REST is no more scalable than SOAP.
>
> Yes, this is an important insight. But the linear factor is also
> important. I believe that it is much easier to standardize XML
> vocabularies within and between industries than it is to share APIs or
> messaging interfaces or whatever you want to call them. HTML is merely
> an extreme example of this. The widespread success of RSS is a second
> example. (might be interesting to try to understand why RSS is so much
> more popular on the "public Internet" than is XMLNews...) Obviously
> "chemical ML" is going to be much less widespread than HTML but I have
> much more hope that Bayer and 3M would share "chemical ML" than that
> they would agree on a wire-protocol for describing chemicals. There are
> a variety of reasons but one reason is that agreeing on a wire-protocol
> is much closer to agreeing on a *business model* than is agreeing on an
> XML vocabulary.
>
> >...
> >
> > How can we make XML-REST scalable?  One solution would be to require
> > every web site to serve up the same type of XML documents, i.e., have a
> > universal Schema that all XML documents conform to.  Obviously this is
> > not a very attractive solution.  The other solution is to have web sites
> > serve up documents whose meaning can be dynamically "discovered".  I
> > believe that RDF is the only XML technology that enables dynamic
> > understanding of content.  Thus, the cornerstone for a scalable,
> > machine-processable web services architecture is:
> >
> > 1. The HTTP access methods - GET, POST, PUT, etc
> > 2. A dynamically understandable vocabulary, such as RDF.
>
> Yes, this is the approach Mark Baker takes. As I am not (yet?) an RDF
> "believer" I see it more as a spectrum: as we understand problem domains
> more and more, we migrate more and more stuff from "the code" into
> declarative formats that describe the data. RDF fans think that RDF is
> the declarative "uber-format". We'll see. Maybe.
>
> If they are wrong, I still expect dozens of declarative languages like
> XML Query, XSLT etc. to mature into powerful tools for bootstrapping
> understanding of a vocabulary. (consider for example an XSLT associated
> with one industry standard purchase order vocabulary that translates it
> into another PO vocabulary on demand -- easy to model in an
> industry-neutral way with URIs and XML).
>
> One reason I argue against the "standard web services" model because it
> moves the very first bit of the problem from the domain of declarations
> into the domain of code. I.e. to even get the data you need to write
> code. That's a serious impediment to further exploration down the
> declarative path. If XML Query turns out to be extremely wonderful and
> powerful, this fork in the road should come into even greater focus.
>
>  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:1217
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-08 15:00:16
Subject:Resource State
Message:

Mark Baker wrote in
http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0127.html

>> Could you possibly clarify this by giving an example of a stateful
>> interaction which you think should not be allowed?

> Sure.

> In FTP, the command "RETR foo.zip" (retrieve the file foo.zip) 
> means different things depending upon what your current directory 
> is.  The current directory is set with previous FTP commands.  
> So the interpretation of a message depends on previous messages.  
> That's stateful.

Would you have any objection to a resource representing a state?
Or having a state as a property?

Lots of interactions are inherently stateful.
As in conversations or sessions.  
Business exchanges are usually that way.
The interpretation of a message will depend on previous messages.

But I think the state of a business exchange is actually the state of 
a particular business entity, e.g. an Order.  So it can be 
represented as the state of an Order resource.

For example, maybe you can't change an Order that is in 
the "fulfilled" state.
Or for another example, if you want to change an airline ticket that 
is in the "booked" state, it will cost you $75.

This also refers back to previous messages in this forum about 
resource state maybe being the key to a cleaner "session state" model.
http://groups.yahoo.com/group/rest-discuss/message/1037








-----------------------------------------------------------------------------------
Post ID:1218
Sender:Seth Johnson <seth.johnson@...>
Post Date/Time:2002-05-02 22:26:59
Subject:[agents] URGENT ALERT: Broadband = "Information Service" Nonsense -- Comments Needed
Message:

Sorry, but this is really late notice.  Tomorrow is the last
day for comments on the FCC's proposal to call the Internet
an "information service" for the entrenched broadband
interests.  Ostensibly, this decision is being made in
preference over classifying broadband internet as a
"communications medium," which would place it under
regulations like those phone companies are subject to.  It
is therefore being characterized as a decision for
deregulation versus regulation.

Anybody who can, PLEASE send in a note saying this is not a
question of whether regulation or deregulation is better
policy (this is just a smokescreen) -- it's a question of
the nature of the online medium:  Is it a "content" delivery
system, or a communications medium characterized by its
fundamental two-way protocols, one which brings profound new
capabilities to all citizens?

*Please* send even just a short note to the FCC at
ecfs@....

If you know any other constituencies that would want to put
a word in on this, please let them know.

From Dave Farber's Interesting People list,
farber@....

Seth Johnson


-------- Original Message --------
Subject: IP: : Comment on NPRM 02-33
Date: Thu, 2 May 2002 15:32:22 -0500
From: "David Farber" <dfarber@...>


-----Original Message-----
From: "David S. Isenberg" <isen@...>
Date: Thu, 02 May 2002 16:13:48 
To: dave@...
Subject: Comment on NPRM 02-33


Dave,

This is the comment opposing FCC Notice of Proposed
Rulemaking (NPRM) 02-33 that I told you I'd write.  NPRM
02-33 threatens to turn back the network architecture  clock
to pre-Internet days.  Please distribute it via IP as soon
as you can -- the  deadline for comments is tomorrow, and
I'd like as many IPers as possible to comment.

IPers -- You can read the original NPRM at
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-02-42A1.doc

FCC comments should follow the form below.  Email them to
the FCC's Electronic Comment Filing System: ecfs@....


ECFS - E-mail Filing
<PROCEEDING>	02-33
<DATE>		5/2/02
<NAME>		David S. Isenberg
<ADDRESS1>	112 Orchard Street
<ADDRESS2>
<CITY>		Cos Cob
<STATE>	CT
<ZIP>		06807
<LAW-FIRM>	none
<ATTORNEY>	none
<DOCUMENT-TYPE>CO
<PHONE-NUMBER>	203-661-4798
<DESCRIPTION>  Email Comment
<CONTACT-EMAIL>isen@...
<TEXT> 

I am writing to oppose the reasoning behind NPRM 02-33,
"Appropriate Framework for Broadband Access to the Internet
over Wireline Facilities", because I am afraid that treating
broadband Internet access as an information service (as
proposed by NPRM 02-33) would deprive United States citizens
of the single most important feature of the Internet that
has made it such a runaway success over the last decade.

Let me introduce myself.  I have a Ph.D. in Biology from the
California Institute of Technology, where I studied human
speech.  I spent 12 years, 1985-1998, at AT&T Bell Labs,
where I served as Distinguished Member of Technical Staff. 
Today, I make my living as an independent commentator on
telecommunications.  While I serve on numerous advisory
boards and have numerous clients, I am beholden to no
commercial interests.  I am writing as a concerned citizen
of the United States, and I am writing with hope that recent
great advances in communications technology -- and, more
importantly, in network architecture -- will become
available to all.

In my understanding, "access" involves connecting my
computer (and other digital communications devices) to the
Internet.  "Information" is quite different -- information
is in the ones and zeros that enter my computer to be
processed by it.  Information can flow into my devices over
a variety of "access" -- over a wire, over a cable, over an
optical fiber, or through the air (either as radio-frequency
energy, or as light-wave energy).  That is, the same
sequence of ones and zeros can enter my computer by any of
these access methods.  So to equate "access" with
"information", as does NPRM 02-33, is simply incorrect.

It was not always so.  The telephone network was developed
to deliver one kind of information -- the human voice.  It
was engineered for voice, and it gave access to voice. 
Everything else that it carried (e.g., touch tones, modem
signals, signalling information to set up telephone calls)
was either an exception, or an adjunct to voice telephony. 
The wire that came into the house could not be distinguished
from the service it provided.  It was the same for
television and radio -- each had its own dedicated
infrastructure (be it a wire or a frequency band) to carry a
specific type of information.

The great advance of the Internet was that its fundamental
architecture separated "access" from "information".  Any one
of the various forms of access to the Internet puts one in
touch with an infinite array of information.  Furthermore,
providers of this information (information service
providers) do not own special infrastructure -- all they
need is a server and any of the several methods of Internet
access.  As a result, the Internet is wide-open to
innovation, and we have applications and services like
email, Web browsing (in all its manifestations), ecommerce,
Internet telephony, streaming audio and video, chat and
instant messaging.  

Not a single one of these information (and communications)
services was brought to market by a telephone company or a
television company or a cable operator or a broadcast radio
network.  No, access is a fundamentally different business
from "information service".  To equate "broadband access"
and "information service" -- as NPRM 02-33 proposes -- would
be a horrendous step backwards.

Without separation, "broadband access" as an "information
service" is likely to resemble the failed Interactive TV
experiments of the early 1990s.  TV-on-speed is not "the
Internet" -- and vice versa.

David I
-------


************      WE HAVE MOVED!      ***************
New Snail-Mail Address, effective March 1, 2002:
isen.com
112 Orchard Street
Cos Cob CT 06807
New phone: 203-661-4798
*--------------------isen.com----------------------* 
David S. Isenberg         isen@... 
isen.com, inc.            888-isen-com (inside US) 
http://isen.com/          203-661-4798 (direct line) 
*--------------------isen.com----------------------* 
      -- The brains behind The Stupid Network -- 
*--------------------isen.com----------------------*

For archives see:
http://www.interesting-people.org/archives/interesting-people/

 --
See <http://www.cs.umbc.edu/agentslist> for list info & archives.






-----------------------------------------------------------------------------------
Post ID:1219
Sender:Seth Johnson <seth.johnson@...>
Post Date/Time:2002-05-08 15:10:54
Subject:Re: URGENT ALERT: Broadband = "Information Service" Nonsense -- CommentsNeeded
Message:

My profuse apologies for this -- it appears that someone is
spoofing my original email, which had been prompted by the
press of circumstances.

Incidentally, by the close of the comments period, the FCC
had received about 630 public comments, vastly opposed to
declaring broadband Internet an "information service."

Seth Johnson

-- 

[CC] Counter-copyright:
http://cyber.law.harvard.edu/cc/cc.html







-----------------------------------------------------------------------------------
Post ID:1220
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-08 15:48:29
Subject:Re: [rest-discuss] Resource State
Message:

bhaugen32 wrote:
> 
>...
> 
> Would you have any objection to a resource representing a state?

That's what resources are for. ;)

3. No Implicit State: If the client and server depend on a shared piece
of information in order to communicate effectively then that piece of
information should be given an address (usually by the server) and
exposed as a web resource. Clients should be considered entirely 
stateless. The only thing they remember from one message to another are
things defined by the protocol, like authentication tickets -- not 
things defined by the application, like purchase order numbers.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1221
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-08 16:26:29
Subject:Re: [rest-discuss] Resource State
Message:

Paul Prescod wrote:
>
> That's what resources are for. ;)
>
> 3. No Implicit State: If the client and server depend on a shared piece
> of information in order to communicate effectively then that piece of
> information should be given an address (usually by the server) and
> exposed as a web resource. Clients should be considered entirely
> stateless. The only thing they remember from one message to another are
> things defined by the protocol, like authentication tickets -- not
> things defined by the application, like purchase order numbers.

This is rest-discuss right?

My read of Roy's thesis (in particular 5.1.3) is that it encourages
stateless servers, with clients providing all the necessary state on every
request.

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1222
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-08 17:05:25
Subject:Re: [rest-discuss] Resource State
Message:

Sam Ruby wrote:
> 
>...
> 
> This is rest-discuss right?
> 
> My read of Roy's thesis (in particular 5.1.3) is that it encourages
> stateless servers, with clients providing all the necessary state on every
> request.

That's true at the protocol level. An HTTP server is not required to
"remember" previous HTTP messages. It is not necessarily true at the
application level. The Web would be useless if it were not possible to
store state on web servers. How would you implement a discussion group
in a completely stateless environment? Three out of the four main HTTP
methods manipulate state so clearly this was always intended!

Consider the three stated reasons for the requirement:

"This constraint induces the properties of visibility, reliability, and
scalability. Visibility is improved because a monitoring system does not
have to look beyond a single request datum in order to determine the
full nature of the request. Reliability is improved because it eases the
task of recovering from partial failures [133]."

These two features are preserved by the rule I stated about "No Implicit
State". 

"Scalability is improved because not having to store state between
requests allows the server component to quickly free resources, and
further simplifies implementation because the server doesn't have to
manage resource usage across requests."

This feature is also preserved *to the extent possible*. Obviously if
the client is allowed to manipulate server state then you introduce the
possibility of scalability problems. But there is no distributed system
that can get around the fact that storing lots of data takes lots of
disk space. The important thing is that the state is managed at the
application, not protocol layer. HTTP just transmits the request to PUT
but nothing in the HTTP specification says that an HTTP server must
remember that it just handled a PUT. Only the application remembers
this, if it chooses to do so.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1223
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-08 17:48:54
Subject:Re: Resource State
Message:

Paul Prescod wrote:
> Clients should be considered entirely 
> stateless. The only thing they remember from one message to another 
are
> things defined by the protocol, like authentication tickets -- not 
> things defined by the application, like purchase order numbers.

However, if a PO number were encased in a URI, it would be ok, right?
http://vendor.com/customerA/PurchaseOrders/1001/

I recognize that I am asking glaringly obvious questions.
But as you saw from Sam Ruby's response, the answers are not always 
quite as obvious.

Next step:  Paul, I seem to remember you suggesting the idea of 
resources to represent states of sessions.  I think the example you 
used was a travel site where your itinerary and ticket were resources 
with URIs so you could return to them and take subsequent actions.

How far do you think this idea could be pushed?
What are the drawbacks?
Could it eliminate cookies and other session-management kludges?
I'm also thinking of "conversation ID" and other tags in message-
oriented SOAP that are addressed to hidden resources.










-----------------------------------------------------------------------------------
Post ID:1224
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-08 18:49:48
Subject:Re: [rest-discuss] Resource State
Message:

Paul Prescod wrote:
>
> Three out of the four main HTTP
> methods manipulate state so clearly this was always intended!

Luckily, three out of the four main HTTP methods don't account for 75% of
the usage of the internet, or else we will would likely have seen a
meltdown quite a ways back.   ;-)

> Consider the three stated reasons for the requirement:
>
> "This constraint induces the properties of visibility, reliability, and
> scalability. Visibility is improved because a monitoring system does not
> have to look beyond a single request datum in order to determine the
> full nature of the request. Reliability is improved because it eases the
> task of recovering from partial failures [133]."
>
> These two features are preserved by the rule I stated about "No Implicit
> State".
>
> "Scalability is improved because not having to store state between
> requests allows the server component to quickly free resources, and
> further simplifies implementation because the server doesn't have to
> manage resource usage across requests."

I believe those three constraints can be satisfied by requiring that each
request from client to server must contain all of the information necessary
to understand the request, and cannot take advantage of any stored context
on the server.

In short, I agree with the "No Implicit State", but I still don't see how
these assersions support the conclusion that "Clients should be considered
entirely stateless."

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1225
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-08 22:50:07
Subject:Re: [rest-discuss] Resource State
Message:

Sam Ruby wrote:
> 
>...
> 
> I believe those three constraints can be satisfied by requiring that each
> request from client to server must contain all of the information necessary
> to understand the request, and cannot take advantage of any stored context
> on the server.

I think you're right that they cannot take advantage of *implicitly*
stored context on the server.

But if the service is a discussion list it would be ridiculous if it
were impossible to POST a reply to an existing message. It would be
equally ridiculous for the client to try to send the *entire
conversation* before it could add a single message. If the server has
exposed some state as a resource then the client can rely on it.

> In short, I agree with the "No Implicit State", but I still don't see how
> these assersions support the conclusion that "Clients should be considered
> entirely stateless."

My point is that the server should make no assumptions about how much
state the client is maintaining and vice versa. That is an extra
implementation dependency that degrades interoperability.

It should all be in the message or in resources referenced by the
message. Cookies are a violation of this principle (which is probably
why they aren't a W3C specification).

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1226
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-09 00:23:11
Subject:Re: [rest-discuss] Re: Resource State
Message:

bhaugen32 wrote:
> 
> Paul Prescod wrote:
> > Clients should be considered entirely
> > stateless. The only thing they remember from one message to another
> are
> > things defined by the protocol, like authentication tickets -- not
> > things defined by the application, like purchase order numbers.
> 
> However, if a PO number were encased in a URI, it would be ok, right?
> http://vendor.com/customerA/PurchaseOrders/1001/

Well the client wouldn't think of it as a PO number but rather as an
opaque bit of a URI...if it is helpful implementation technique for the
server then sure, embed a PO numbers.

>...
> Next step:  Paul, I seem to remember you suggesting the idea of
> resources to represent states of sessions.  I think the example you
> used was a travel site where your itinerary and ticket were resources
> with URIs so you could return to them and take subsequent actions.

As you know (but others may not) I said that you probably don't really
need a concept of "session" at all.

> How far do you think this idea could be pushed?

Hard to say. I think that the whole web services world needs to figure
out what is going to happen with transactions (or should clients just
unroll actions?). If real transactions end up being necessary for web
services then I guess a transaction is a kind of session...

> What are the drawbacks?

If you can't use a session ID to refer to a large body of shared context
then you may end up sending more information in each message to
establish context. Also resource cleanup typically will not happen
automatically when a "session ends" as it might in a stateful protocol.
No matter what model you use, resource cleanup is a nasty issue.

> Could it eliminate cookies and other session-management kludges?

IMO, cookies arise because web clients are not web servers and are not
guaranteed to have any "writable" resource space. Cookies are not very
good if you don't trust the servers you talk to (as you should not).
Obviously there are privacy problems but also it seems clear that they
could be used for a nasty denial of service -- except that they are
restricted from being very large or numerous. So the standard way to
prevent the DOS is to apply arbitrary limitations that restrict their
utility. So I don't see the cookie solution as really scaling up to the
web services world.

What should happen, from a privacy and security point of view, (if not
from a usability point of view) is that "client-side" state should be
stored in files with URIs. Access should be granted or not explicitly.
The contents should be transparent. I am amazed how many sites force
cookies on me and when I turn them off the site's performance does not
degrade at all. The cookie seems not to provide any advantage to me, the
user, only to the marketers trying to track my progress through the
site.

In some ways Hailstorm was on the right track. You don't want to store
state on a particular client device -- especially implicitly! I do not
believe that browsers even give me an option of "exporting my cookies"
so obviously no important state can be stored in them.

> I'm also thinking of "conversation ID" and other tags in message-
> oriented SOAP that are addressed to hidden resources.

I personally don't see the value in the reifying the "conversation".
It's just a short-cut that allows one message to rely on some state
implicitly sent through a previous message. Just like cookies, it ties
the whole conversation to a single device which may prevent
modularization. Perhaps I'm missing some hidden advantage...

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1227
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-09 11:34:01
Subject:Re: Resource State
Message:

Paul Prescod wrote:
> > http://vendor.com/customerA/PurchaseOrders/1001/
> 
> Well the client wouldn't think of it as a PO number but rather as an
> opaque bit of a URI...if it is helpful implementation technique for 
the
> server then sure, embed a PO numbers.

I don't think of it as a PO number, but that the resource is a 
Purchase Order...which is what I suppose you meant, too.
(Continuing to be glaringly obvious so as to get explicit agreements.)

> As you know (but others may not) I said that you probably don't 
really
> need a concept of "session" at all.

I had never really thought about it before until something clicked 
when I read one of your previous messages.  I'm still trying to 
follow the implications, thus the next question...

> > How far do you think this idea could be pushed?
> 
> Hard to say. I think that the whole web services world needs to 
figure
> out what is going to happen with transactions (or should clients 
just
> unroll actions?). If real transactions end up being necessary for 
web
> services then I guess a transaction is a kind of session...

For business purposes, some kind of transactions are necessary.
They are not database transactions, but for business state alignment.
They wrap common business protocols:  good example, offer-acceptance 
is the business protocol for contract (order) formation.
Both trading partners must agree on whether the offer was accepted or 
not.  
Acceptance should be explicit:  i.e. non-repudiable messages from 
each party that irrevocably connect acceptance to offer.  
The acceptance message may take some time, but not forever.
Time constraints must apply.

So I'm thinking, could this kind of business-state-alignment 
transaction be made into a resource itself - maybe a sub-resource of 
the Order?

> > What are the drawbacks?
> 
> If you can't use a session ID to refer to a large body of shared 
context
> then you may end up sending more information in each message to
> establish context. 

If the transaction is a resource, you will send messages to the 
transaction.  (Does that make sense?)

> Also resource cleanup typically will not happen
> automatically when a "session ends" as it might in a stateful 
protocol.

If a business transaction is made into a Web resource, what needs to 
be cleaned up?  The transaction resources should be persistent, in 
some cases for years.  If the transaction times out before a 
response, it fails (i.e. its state is "failed").

(I must be missing something here.  Making this stuff all into Web 
resources seems so much simpler to me that somebody must have already 
tried and rejected it before they adopted cookies et al.  Mustn't 
they?)







-----------------------------------------------------------------------------------
Post ID:1228
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-09 17:34:53
Subject:Re: [rest-discuss] Re: Resource State
Message:

----- Original Message -----
From: "bhaugen32" <bhaugen32@...>

>
> (I must be missing something here.  Making this stuff all into Web
> resources seems so much simpler to me that somebody must have already
> tried and rejected it before they adopted cookies et al.  Mustn't
> they?)
>
Nope. Most system are browser based & it's 'low lying fruit' for programmers
in a hurry. Thinking beyond a demo system doesn't always happen.
Cookies are useful for browser based apps - but when you write your own
client, you have more freedom to innovate (as it were...).








-----------------------------------------------------------------------------------
Post ID:1229
Sender:"macdug_dc" <macdug_dc@...>
Post Date/Time:2002-05-09 17:59:47
Subject:Conceptual Objects Spec
Message:

Folks.

I thought folks here may find the draft Conceptual Objects spec 
interesting as it has RESTful qualities.

http://groups.yahoo.com/group/conceptobjects/

(For now, you'll need to join the group to view the draft spec.)

Robb Beal







-----------------------------------------------------------------------------------
Post ID:1230
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-09 18:03:50
Subject:Re: Resource State
Message:

"S. Mike Dierken" wrote:
> > (I must be missing something here.  Making this stuff all into Web
> > resources seems so much simpler to me that somebody must have 
already
> > tried and rejected it before they adopted cookies et al.  Mustn't
> > they?)
> >
> Nope. Most system are browser based & it's 'low lying fruit' for 
programmers
> in a hurry. Thinking beyond a demo system doesn't always happen.

How many of the Web application server environments use the concept 
of a session in one disguise or another?
(Whether based on cookies or not.)
Which ones don't?

I just took a look at Seaside, a Web app server for Squeak.
The designers seem to be trying to rethink a lot of stuff.
Including a continuation-passing idea.  But still - they 
plan to have sessions.
http://beta4.com/seaside










-----------------------------------------------------------------------------------
Post ID:1231
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-05-09 18:28:13
Subject:RE: [rest-discuss] Conceptual Objects Spec
Message:

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

No offence meant, but could you at least put an abstract up
somewhere, before requiring people to subscribe to a list?

Bill de hra

> -----Original Message-----
> From: macdug_dc [mailto:macdug_dc@...] 
> Sent: 09 May 2002 19:00
> To: rest-discuss@yahoogroups.com
> Subject: [rest-discuss] Conceptual Objects Spec
> 
> 
> Folks.
> 
> I thought folks here may find the draft Conceptual Objects spec 
> interesting as it has RESTful qualities.
> 
> http://groups.yahoo.com/group/conceptobjects/
> 
> (For now, you'll need to join the group to view the draft spec.)
> 
> Robb Beal
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~--> Tied to your PC? Cut Loose and Stay 
> connected with Yahoo! Mobile 
> http://us.click.yahoo.com/QBCcSD/o1CEAA/sXBHAA/W6uqlB> /TM
> 
> 
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to: 
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPNq/u+aWiFwg2CH4EQId9ACdEWO82Ob5tOu8/NOZ4mRl1tGtBxMAoNQL
Y4gkHPMkjl9kDXtfuiIlNOm6
=HTVj
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:1232
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-09 18:38:23
Subject:Re: [rest-discuss] Re: Resource State
Message:

----- Original Message -----
From: "bhaugen32" <bhaugen32@...>

>
> How many of the Web application server environments use the concept
> of a session in one disguise or another?
> (Whether based on cookies or not.)
Most do. "Give the People What They Want". It messes up scalability (adding
nodes to a cluster) and starts to require 'sticky routing' (getting a
request to go to the same physical place as previous requests, in order to
have a high 'cache hit ratio') and other tricky designs. Many app servers
also have 'session replication' which copies transient session data across
the cluster - kind of like writing it to a central database, but not really.

I don't know the driving need for server session data, other than it being
one approach for performance optimization. There may be a real need there -
especially for UI based apps - but I'm not very familiar with it.

> Which ones don't?








-----------------------------------------------------------------------------------
Post ID:1233
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-09 18:50:38
Subject:Re: [rest-discuss] Conceptual Objects Spec
Message:

> No offence meant, but could you at least put an abstract up
> somewhere, before requiring people to subscribe to a list?

Yah, really.

FWIW, I joined and looked at it.  It's basically the HTML LINK element
in XML.  I'll be "unjoining" soon. 8-)

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1234
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-09 18:55:55
Subject:Re: [rest-discuss] Re: Resource State
Message:

Sessions and statelessness aren't mutually exclusive, so long as the
session in which the message exists is part of the message.  That makes
the *interaction* stateless, which is the important thing.

MB






-----------------------------------------------------------------------------------
Post ID:1235
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-09 19:03:34
Subject:Re: Resource State
Message:

Mark Baker wrote:
> Sessions and statelessness aren't mutually exclusive, so long as the
> session in which the message exists is part of the message.  That 
makes
> the *interaction* stateless, which is the important thing.

Thanks.  I understand your position vs statelessness.

But do you think sessions are *necessary*?
Or can they (always or usually) be replaced by Web resources?
And is that transformation (always or usually) better?

We discussed this once before, in the context of EDI-mailbox-style 
SOAP, where messages have "conversation" and "transaction" tags.
In that discussion, (I think) we agreed that these tags could be 
replaced by making the subjects of the conversation into Web 
resources with URIs.  

And that there were advantages to the transformation: from one 
centralized mailbox with a dispatcher, to individual addresses for 
each conversational subject.

I'm trying to explore whether REST yields a better/simpler 
architecture for the problems that sessions and conversation tags 
were supposed to solve.







-----------------------------------------------------------------------------------
Post ID:1236
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-09 19:22:07
Subject:Re: [rest-discuss] Re: Resource State
Message:

Mark Baker wrote:
>
> Sessions and statelessness aren't mutually exclusive, so long as the
> session in which the message exists is part of the message.  That makes
> the *interaction* stateless, which is the important thing.

Well put.

One thing I haven't seen mentioned in this thread - there are two popular
ways to have session support.  One is cookies, the other is URL munging.
In the latter, all interactions can be done via HTTP GET, and there is
little or no assumptions made about the capabilities of the client.  Some
would - based on this description alone - declare such a solution RESTful.
The reality is that such an approach uses URL to identify not just
resources, but also comingles in the concept of context.

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1237
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-09 19:38:03
Subject:Re: [rest-discuss] Re: Resource State
Message:

On Thu, May 09, 2002 at 07:03:34PM -0000, bhaugen32 wrote:
> But do you think sessions are *necessary*?

For some things, yes.

> Or can they (always or usually) be replaced by Web resources?
> And is that transformation (always or usually) better?

I don't see why you can't do both.

e.g.

POST http://foo.org/foo
Content-Type: application/foo+xml
Transaction: http://foo.org/txn/24234234324
[body]

You'd only interact with the transaction resource if you wanted to
checkpoint (GET) or rollback (PUT).  Otherwise it's just an opaque
transaction identifier.

> We discussed this once before, in the context of EDI-mailbox-style 
> SOAP, where messages have "conversation" and "transaction" tags.
> In that discussion, (I think) we agreed that these tags could be 
> replaced by making the subjects of the conversation into Web 
> resources with URIs.  
> 
> And that there were advantages to the transformation: from one 
> centralized mailbox with a dispatcher, to individual addresses for 
> each conversational subject.

I don't remember that conversation exactly.  But I recall mentioning
possible "CHECKPOINT" and "ROLLBACK" methods, though I decided that GET
and PUT could be used instead.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1238
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-09 20:35:28
Subject:Re: Resource State
Message:

Mark Baker wrote:
> > But do you think sessions are *necessary*?
> 
> For some things, yes.

For example?  (I'm not arguing, just thinking about it.)

> > We discussed this once before, in the context of EDI-mailbox-
style 
> > SOAP, where messages have "conversation" and "transaction" tags.
> > In that discussion, (I think) we agreed that these tags could be 
> > replaced by making the subjects of the conversation into Web 
> > resources with URIs.  
> > 
> > And that there were advantages to the transformation: from one 
> > centralized mailbox with a dispatcher, to individual addresses 
for 
> > each conversational subject.
> 
> I don't remember that conversation exactly.  But I recall mentioning
> possible "CHECKPOINT" and "ROLLBACK" methods, though I decided that 
GET
> and PUT could be used instead.

http://groups.yahoo.com/group/rest-discuss/message/1094
http://groups.yahoo.com/group/rest-discuss/message/1095

BH:
>> So if I make the Order into a Web resource, created by 
>> the initial POST, then all subsequent POSTs or GETs are 
>> addressed either to that Order resource or one of its 
>> sub-resources (LineItems, Deliveries, Invoices, Payments, etc.)
>> I consider Transactions to be business entities, 
>> so they could be sub-resources.
>> So I no longer have one gateway URI with a dispatcher behind it, 
>> I am directly addressing the relevant business resource.
>> Does this make sense to anybody else?

MB:
> Yep, that's exactly my thinking too.
> Plus, because you're identifying the mailbox at a more 
> granular level than just a catch-all mailbox, GET, PUT, 
> and DELETE makes sense.

By the way, when I use the word "transaction" here, I mean "business 
state alignment" not database.  So there is no rollback.  The 
resources just fail to advance to the next state.








-----------------------------------------------------------------------------------
Post ID:1240
Sender:LDN-HPI-LNMHUB/HBC/LDN/HARCOURT@...
Post Date/Time:2002-05-09 22:16:30
Subject:Report to Recipient(s)
Message:

Incident Information:-

Originator:    jsalzman <jsalzman@....>
Recipients:    rest-discuss@yahoogroups.com
Subject:  [rest-discuss] Hello,questionnaire

Message from jsalzman <jsalzman@....> was quarantined because it
contained a banned type of file attachment which could carry a potential
virus.







-----------------------------------------------------------------------------------
Post ID:1241
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-10 05:15:20
Subject:Why Paul is wrong about resource discovery via hypertext
Message:

Okay, the subject is a somewhat misleading, but I like to tease Paul once in
a while.

I've been thinking about what the ultimate HTTP web would be like and what
kind of tools would be nice for developers to have to work with it -
especially in relation to the cool tools that SOAP developers find
valueable.

The cool tool for me is the intellisense/popup thingee in editors. With pure
hypertext, this can be done fairly easily - in fact MS Windows does this for
file system browsers - you type something in the address bar of File
Explorer or a common file dialog and it pops up choices. (of course Unix
command line file completion has been doing this for several years.) It
doesn't take a rocket scientist to hack a web browser to do this for HTTP -
fetch the page and show the list of anchors with href's that match (which
will fail miserably on the 'real web' because everybody uses javascript...
whatever).

The drawback to hypertext discovery is that it is instance based. The
resources identifiers have to already exist in order to discover them. You
can't talk about things outside their lifetime - before they exist or after
they are removed.

To program the 'idealized web' from the kind of development environements
that many people like it seems that a blending of instance based and
'pattern based' discovery (the generative naming JeffB talked about) would
be ideal for the programmer.

The popup thingee would be really useful when its too hard or you're too
lazy to build a decent discovery system. I'm not too conversant with WSDL,
so maybe it can do a large part of this - or maybe a mix of pure URI
discovery and WSDL may be useful.

What do you think Paul?







-----------------------------------------------------------------------------------
Post ID:1242
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-10 18:48:35
Subject:Re: [rest-discuss] Why Paul is wrong about resource discovery via hypertext
Message:

"S. Mike Dierken" wrote:
> 
> Okay, the subject is a somewhat misleading, but I like to tease Paul once in
> a while.

"Why is everybody always picking on me?"

>...
> 
> The drawback to hypertext discovery is that it is instance based.

This is where I disagree. The hypertext instance is an instance of a
document type defined by a schema. It is demonstrably possible to drive
popups from schemas -- Visual Studio.NET does this already. The primary
reason that WRDL has stalled is because I haven't figured out a way to
preserve the extensive processing that these environments already
provide and add the tiny extra bit you need to view URI-bearing elements
as hyperlinks rather than end-nodes. But even without the extra juice of
WRDL one can do hyperlink-following processing using WSDL.

class PurchaseOrder extends WebServiceProxy{
   // this class was generated from the WSDL
   ...
   AnyURI rec;
}

class CustomerRecord extends WebServiceProxy{
   // this class was generated from the WSDL
   ...
}


po = new PurchaseOrder("http://....some...url")
customer = new CustomerRecord(po.rec);

Now you'll get all of the popups on the customer object.

The only inconvenient thing here is that I've had to *tell the system*
that the AnyURI is really a CustomerRecord as opposed to having it
figure out from the schema. Arguably this degrades type safety (but then
the type safety was always an illusion because you can't control the
type of data returned by the other system).

I'm not 100% sure if this addresses the gist of your concern because I
don't see how pattern-based identifiers would help. The question is
whether you have the information you need available at design time or
not. With pattern-based systems you presumably have some regular
expression language or something. With XML you have schemas.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1243
Sender:rest-discuss@yahoogroups.com
Post Date/Time:2002-05-10 19:11:38
Subject:New file uploaded to rest-discuss
Message:

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the rest-discuss 
group.

  File        : / Click Here! 
  Uploaded by : randyphillipsar <randyphillipsar@...> 
  Description : No matter what your credit is like ,there is a card here for you! 

You can access this file at the URL

http://groups.yahoo.com/group/rest-discuss/files/%20Click%20Here%21 

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

randyphillipsar <randyphillipsar@...>
 










-----------------------------------------------------------------------------------
Post ID:1244
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-11 01:37:25
Subject:Re: [rest-discuss] Re: Resource State
Message:

On Thu, May 09, 2002 at 08:35:28PM -0000, bhaugen32 wrote:
> Mark Baker wrote:
> > > But do you think sessions are *necessary*?
> > 
> > For some things, yes.
> 
> For example?  (I'm not arguing, just thinking about it.)

Anything transactional.

> By the way, when I use the word "transaction" here, I mean "business 
> state alignment" not database.  So there is no rollback.  The 
> resources just fail to advance to the next state.

Rollback could still be attempted.  It doesn't mean it has to
successful, but just knowing that it isn't may be useful
information to signal that that some compensatory type action
needs to be taken.  But if it does work, then that's even better!

MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@...
http://www.markbaker.ca   http://www.planetfred.com






-----------------------------------------------------------------------------------
Post ID:1245
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-11 13:42:25
Subject:Re: Resource State
Message:

Mark Baker wrote:
> > > > But do you think sessions are *necessary*?
> > > 
> > > For some things, yes.
> > 
> > For example?  (I'm not arguing, just thinking about it.)
> 
> Anything transactional.

Question for you:  what do you mean by "transactional"?
I tried to explain what I mean below.  
I don't think anything like the database concept of a transaction is 
appropriate across trust boundaries.  (I thought from earlier 
comments that you agreed.)

Clarification of my earlier question: I don't deny that sessions may 
be the best way to go sometimes.  The question was if they are 
actually necessary, that is, if you can't get the same results from 
making the interaction into a resource some way.  Possibly dumb way: 
make the transaction itself into a resource. (Or maybe not so dumb...)

> > By the way, when I use the word "transaction" here, I 
mean "business 
> > state alignment" not database.  So there is no rollback.  The 
> > resources just fail to advance to the next state.
> 
> Rollback could still be attempted.  It doesn't mean it has to
> successful, but just knowing that it isn't may be useful
> information to signal that that some compensatory type action
> needs to be taken.  But if it does work, then that's even better!

But what would you roll back? (Or maybe, what situations do you have 
in mind where rollback would be an appropriate concept?)

Example:  in an offer-acceptance transaction, let's say the offer 
starts out in a "pending" state. 
If the transaction ends normally, the offer advances to 
the "accepted" state or the "rejected" state depending on the 
response.

If the transaction does not end normally (times out, etc.) the offer 
is still "pending".  No rollback, it just doesn't change to 
either "accepted" or "rejected" - although the practical equivalent 
of "rejected" might be inferred.

In RosettaNet (and ebXML copying RNet) there is a "Notification of 
Failure" that is sent via a different channel in cases where the end 
of the transaction might not be clear to both parties.  It's a 
compensatory action.  Might be considered rollback if one party had 
thought the transaction succeeded.

I know RNet and ebXML are EDI-mailbox-style, but they also pretty 
closely adhere to commercial law and customs, so there are some real 
business requirements behind their ways of doing things.  So I'm 
trying to see if I can get the same adherance to commercial law and 
customs from a purely REST configuration, and in this case, with no 
sessions or conversation or transaction dispatch tags.

There are reasons for wanting to do this that I could try to explain 
if they are not obvious.  I'm still not sure how far it is necessary 
or wise to push the idea, thus these questions on this forum where 
people seem to know how to think about it.







-----------------------------------------------------------------------------------
Post ID:1246
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-13 23:33:30
Subject:Re: [rest-discuss] Why Paul is wrong about resource discovery via hypertext
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> > The drawback to hypertext discovery is that it is instance based.
>
> This is where I disagree. The hypertext instance is an instance of a
> document type defined by a schema.
By 'instance based' I meant 'instance of a resource'. You can't get the URI
to a resource before the resource exists. Actually, you can, if the server
decides the URI. In the case of PUT, the client decides the URI - but that
might be problematic in general. The client could use POST to request that a
new resource be created and the server can report what that server-generated
URI is - I suppose that would solve that problem.


>
> I'm not 100% sure if this addresses the gist of your concern because I
> don't see how pattern-based identifiers would help. The question is
> whether you have the information you need available at design time or
> not. With pattern-based systems you presumably have some regular
> expression language or something. With XML you have schemas.
The pattern could be XML or something. Doesn't have to a 'grep' like
language.








-----------------------------------------------------------------------------------
Post ID:1247
Sender:"xemplify" <xemplify@...>
Post Date/Time:2002-05-14 20:11:44
Subject:Implementing REST and resource modeling
Message:

Hi everyone,

I am new to the list so please excuse me if I am repeating questions.

Background - At work we need to implement a way of reading and 
writing data to our existing Java trading application. We are in 
close collaboration with the external parties who will be using this 
functionality. Others are proposing that we use SOAP. I feel the REST 
approach will offer more flexibility in the future, allowing the data 
to be accessed, linked and manipulated in ways not yet though of, 
whereas SOAP would constrain the use of data to the API exposed.

My questions are:

1) Are there any open-source tools that can help with implementing a 
Java RESTful interface? Does anyone have any Java implementation 
experience to share?

2) The SOAP proponents at work are proposing the use of Apache Axis 
as a SOAP server implementation. Does anyone have experience with 
Axis?

3) The SOAP proponents think the extensible SOAP header adds 
flexibility, a place to put transaction metadata or security related 
information. Does REST have an answer to these requirements?

4) We need a way for an external application to store or modify a 
trade in our application. I would be interested in any feedback on 
the following resource modeling ideas:

4a) To store a new trade, either a two step communication:
 -> HTTP GET request
      to //host/trades/newtradeuri
      or //host/trades?newtradeuri

 <- HTTP response would contain server-generated URI:
         //host/trades/123
      or //host/trades?id=123

 -> HTTP PUT request containing trade XML
      to //host/trades/123

 <- HTTP response indicating success


Or perhaps do it in one step:
 -> HTTP POST request containing trade XML
      to //host/trades/newtrade
      or //host/trades

 <- HTTP response would contain server-generated URI:
         //host/trades/123


4b) To modify an existing trade:
 -> HTTP PUT request containing trade XML
      to //host/trades/122

 <- HTTP response indicating success


4c) To read an existing trade:
 -> HTTP GET request
      to //host/trades/122

 <- HTTP response containing trade XML


4d) Within a trade XML instance some information would be represented 
as a link to the resource containing the complete information. For 
example:

  <trade>
    <counterparty href="https//host/counterparties/12"/>
    <broker href="https//host/brokers/34"/>
    ...
  </trade>


5) Given the requirements outlined in (4), which would you recommend: 
the REST approach above, or the use of SOAP with an API containing 
methods such as, storeTrade(tradeXml), modifyTrade(tradeXml), getTrade
().


Look forward to any feedback.

Regards,
Robert McKinnon








-----------------------------------------------------------------------------------
Post ID:1248
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-14 20:42:31
Subject:Re: [rest-discuss] Implementing REST and resource modeling
Message:

On Tue, May 14, 2002 at 08:11:44PM -0000, xemplify wrote:
> 1) Are there any open-source tools that can help with implementing a 
> Java RESTful interface? Does anyone have any Java implementation 
> experience to share?

In my experience, the Servlet APIs, now part of Jakarta, provide an
excellent framework for RESTful app development.

> 2) The SOAP proponents at work are proposing the use of Apache Axis 
> as a SOAP server implementation. Does anyone have experience with 
> Axis?

I've looked at the APIs, but haven't used it.  From what I can see,
it's pretty much the same as any other SOAP API out there; difficult
to use in a REST based environment where you're using other HTTP
methods and features at the same time.

> 3) The SOAP proponents think the extensible SOAP header adds 
> flexibility, a place to put transaction metadata or security related 
> information. Does REST have an answer to these requirements?

Headers.  HTTP headers, in the case of HTTP.

> 4) We need a way for an external application to store or modify a 
> trade in our application. I would be interested in any feedback on 
> the following resource modeling ideas:
[snip]
> Or perhaps do it in one step:
>  -> HTTP POST request containing trade XML
[snip]
>       or //host/trades
> 
>  <- HTTP response would contain server-generated URI:
>          //host/trades/123

I like that one.

> 4b) To modify an existing trade:
>  -> HTTP PUT request containing trade XML
>       to //host/trades/122
> 
>  <- HTTP response indicating success

Right.

> 4c) To read an existing trade:
>  -> HTTP GET request
>       to //host/trades/122
> 
>  <- HTTP response containing trade XML

Right again.

> 4d) Within a trade XML instance some information would be represented 
> as a link to the resource containing the complete information. For 
> example:
> 
>   <trade>
>     <counterparty href="https//host/counterparties/12"/>
>     <broker href="https//host/brokers/34"/>
>     ...
>   </trade>

Exactly.  You don't have to use "href" though; you can use your own
linking system, or XLink, or RDF.

> 5) Given the requirements outlined in (4), which would you recommend: 
> the REST approach above, or the use of SOAP with an API containing 
> methods such as, storeTrade(tradeXml), modifyTrade(tradeXml), getTrade
> ().

You have to ask? 8-)

MB
-- 
Mark Baker, CTO             Idokorro Mobile Inc.
Ottawa, Ontario, CANADA.         distobj@...
http://www.markbaker.ca  http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1249
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-05-15 01:23:35
Subject:Re: [rest-discuss] Implementing REST and resource modeling
Message:

> > 4b) To modify an existing trade:
> >  -> HTTP PUT request containing trade XML
> >       to //host/trades/122
> >
> >  <- HTTP response indicating success
>
> Right.

Would POST be more appropriate here since you're modifying an existing
resource? Doesn't PUT imply that you're giving the whole representation of a
resource to the server?

Jason









-----------------------------------------------------------------------------------
Post ID:1250
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-15 02:15:24
Subject:Re: [rest-discuss] Implementing REST and resource modeling
Message:

On Tue, May 14, 2002 at 06:23:35PM -0700, Jason Diamond wrote:
> > > 4b) To modify an existing trade:
> > >  -> HTTP PUT request containing trade XML
> > >       to //host/trades/122
> > >
> > >  <- HTTP response indicating success
> >
> > Right.
> 
> Would POST be more appropriate here since you're modifying an existing
> resource?

That depends *how* it's being modified.  If the client knows the
desired state of the trade, then PUT is the correct method.

> Doesn't PUT imply that you're giving the whole representation of a
> resource to the server?

Depends what you mean by "whole".  But in this case, it sounded to me
like the client had a complete representation, presumably because it
previously did a GET on it.

MB
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1251
Sender:"xemplify" <xemplify@...>
Post Date/Time:2002-05-15 14:24:30
Subject:Re: Implementing REST and resource modeling
Message:

--- In rest-discuss@y..., Mark Baker <distobj@a...> wrote:
> > > > 4b) To modify an existing trade:
> > > >  -> HTTP PUT request containing trade XML
> > > >       to //host/trades/122
> > > >
> > > >  <- HTTP response indicating success
> > >
> > > Right.
> > 
> > Would POST be more appropriate here since you're modifying an
> > existing resource?
> 
> That depends *how* it's being modified.  If the client knows the
> desired state of the trade, then PUT is the correct method.

The client is receiving confirmations of trades from an exchange, and 
needs to programmatically enter them in our system.

The trade may need modification because of a mistake; effectively the 
client wants to store a complete new version of the trade, hence the 
use of PUT (though old versions are retained, so perhaps POST more 
relevant?).

This brings up an interesting point: probably clients would like to 
be able to access old versions of a trade. What would be a good way 
of doing this? Ideas:

1) To get the latest version:
-> HTTP GET //host/trades/122
returns latest version of the trade XML e.g.
<trade id="122" version="5">
...
Maybe links to the older versions could also be provided in the 
latest version?

2) To get an older version
-> HTTP GET //host/trades/122?version=2
   or
-> HTTP GET //host/trades/122/2
returns the trade XML for the second version.
Versions are a history of the resource's state. Which is preferred, 
using a query based off the existing URI or a new URI?


Thanks,
Robert McKinnon








-----------------------------------------------------------------------------------
Post ID:1252
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-15 16:00:39
Subject:Re: [rest-discuss] Why Paul is wrong about resource discovery via hypertext
Message:

"S. Mike Dierken" wrote:
> 
> ----- Original Message -----
> From: "Paul Prescod" <paul@...>
> 
> > > The drawback to hypertext discovery is that it is instance based.
> >
> > This is where I disagree. The hypertext instance is an instance of a
> > document type defined by a schema.
> By 'instance based' I meant 'instance of a resource'. You can't get the URI
> to a resource before the resource exists. 

It's like saying you can't get a pointer to an object before it exists.
So what? You know the object's class and you know the document's schema.
Or you would, if you use a service description language that allows you
to strongly type URI references...or you could use RDF Schema.

> ... Actually, you can, if the server
> decides the URI. In the case of PUT, the client decides the URI - but that
> might be problematic in general. 

Except in a content management environment, the client should PUT to a
URI provided by the server. In "web services", the server owns the
namespace.

> ... The client could use POST to request that a
> new resource be created and the server can report what that server-generated
> URI is - I suppose that would solve that problem.

Yes, that's how I think it should work. Otherwise how would the client
choose the URI??

> >
> > I'm not 100% sure if this addresses the gist of your concern because I
> > don't see how pattern-based identifiers would help. The question is
> > whether you have the information you need available at design time or
> > not. With pattern-based systems you presumably have some regular
> > expression language or something. With XML you have schemas.
> The pattern could be XML or something. Doesn't have to a 'grep' like
> language.

Nevertheless, it is a curently non-existent language versus a small
extension to XML Schema for strongly typed URIs.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1253
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-15 16:01:03
Subject:Re: [rest-discuss] Implementing REST and resource modeling
Message:

xemplify wrote:
> 
>...
> 
> 1) Are there any open-source tools that can help with implementing a
> Java RESTful interface? Does anyone have any Java implementation
> experience to share?

Make the point that EVERY web application development tool (Servlets,
Zope, WebLogic) has a strong RESTful component.

> 2) The SOAP proponents at work are proposing the use of Apache Axis
> as a SOAP server implementation. Does anyone have experience with
> Axis?

Not really. I know Google used it. They reported success but at the same
time said they had to hack it to support all of their potential client
libraries.

> 3) The SOAP proponents think the extensible SOAP header adds
> flexibility, a place to put transaction metadata or security related
> information. Does REST have an answer to these requirements?

As Mark said: HTTP headers. But also XML itself is extensible whether
you use SOAP or not.

> 4) We need a way for an external application to store or modify a
> trade in our application. I would be interested in any feedback on
> the following resource modeling ideas:
> 
> 4a) To store a new trade, either a two step communication:
>  -> HTTP GET request
>       to //host/trades/newtradeuri
>       or //host/trades?newtradeuri

Bad, because non-idempotent GET.

>..
> Or perhaps do it in one step:
>  -> HTTP POST request containing trade XML
>       to //host/trades/newtrade
>       or //host/trades
> 
>  <- HTTP response would contain server-generated URI:
>          //host/trades/123

Great!

>....
> 5) Given the requirements outlined in (4), which would you recommend:
> the REST approach above, or the use of SOAP with an API containing
> methods such as, storeTrade(tradeXml), modifyTrade(tradeXml), getTrade
> ().

Sounds like a perfect REST application to me! If you need consulting to
help convince them I'll halve my normal rate. ;)

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1254
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-05-15 16:10:13
Subject:Re: [rest-discuss] Why Paul is wrong about resource discovery via hypertext
Message:

On 5/15/02 11:00 AM, "Paul Prescod" <paul@...> wrote:

> 
>> By 'instance based' I meant 'instance of a resource'. You can't get the URI
>> to a resource before the resource exists.

Mike, you might as well give up on this one, it's precisely the same issue
as the generative naming stuff we were "discussing" earlier and Paul seems
ideologically incapable of giving on this point. ;-)

> 
> It's like saying you can't get a pointer to an object before it exists.

Yes, but you *can* **name** things that don't exist, or don't exist yet.
And if you know how to build such names, your domain of possible discourse
in your application is much larger.

Jb







-----------------------------------------------------------------------------------
Post ID:1255
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-15 17:13:58
Subject:Re: [rest-discuss] Re: Implementing REST and resource modeling
Message:

----- Original Message -----
From: "xemplify" <xemplify@...>

> The trade may need modification because of a mistake; effectively the
> client wants to store a complete new version of the trade, hence the
> use of PUT (though old versions are retained, so perhaps POST more
> relevant?).
This gets into 'collections' of resources. Both PUT and POST can create new
resources - but you have to be careful with using PUT to do this. With POST,
you are sending the new resource, with PUT, the old resource is moved out to
the new resource. POST typically responds with the location of the new
resource, PUT doesn't have to because it only visibly replaces the old
resource (and the client already knows that URI). The problem with rolling
off versions when a PUT happens is idempotency - what happens if you PUT
twice? do you get two backup versions? You can use E-Tag stuff to tell if
this incoming data is the same as the current resource, but that requires
more coordination between client and server.
So... neither method fits very well. I'd suggest you use PUT and consider
the duplicate message case carefully.


> 2) To get an older version
> -> HTTP GET //host/trades/122?version=2
>    or
> -> HTTP GET //host/trades/122/2
> returns the trade XML for the second version.
> Versions are a history of the resource's state. Which is preferred,
> using a query based off the existing URI or a new URI?

<yoda>There is no query. There is only URI.</yoda>

Both are full URI - the portion before the '?' character is the 'path'. The
question mark is used when you have to generate URIs on the client & you
have a declarative form to do that - like <form> for html. Creating the URI
works in a pinch, but the more complete solution is to have the server
report the versions available (in xml or something) and then the specific
URI format becomes unimportant. Rather than knowing the syntax with slashes
and question marks, you need to know the names (or paths) of elements within
XML (or whatever infoset/grove you use).

A more practical answer to your question is "depends on your server
technology".  I have found path-based URI to be treated as second-class
citizens in many server environments (clients that generate URI based on
user input also typically don't do path based stuff very well), so I'd
suggest query terms (even though I personally like paths better). If you
have a flexible server-side environment (like servlets) then path based is
fine. A few years ago I wrote a java servlet-based framework that was very
path based and dispatched methods into java objects identified by the path -
the query terms became parameters. It's at http://xml.apache.org/xang/ if
you are interested in digging into old code (it works fine, its just not
used by anybody - look into the packages around
org.apache.xang.net.http.object.HTTPObjectServer )








-----------------------------------------------------------------------------------
Post ID:1256
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-15 17:28:03
Subject:Re: [rest-discuss] Implementing REST and resource modeling
Message:

Paul Prescod wrote:
>
>> 2) The SOAP proponents at work are proposing the use of Apache Axis
>> as a SOAP server implementation. Does anyone have experience with
>> Axis?
>
> Not really. I know Google used it. They reported success but at the same
> time said they had to hack it to support all of their potential client
> libraries.

Google used Apache SOAP 2.2.  They applied a patch from what will be
included in Apache SOAP 2.3 to support the diversity of values people use
to represent boolean.  They also disabled remote administration.

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1257
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-15 17:50:02
Subject:Re: [rest-discuss] Why Paul is wrong about resource discovery via hypertext
Message:

A resource can be identified before it exists.  For example, at the
recent AC meeting, the IRC logs of the minutes were given HTTP URIs
before the meeting took place.  This is a very useful side effect of
permitting 404s.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1258
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-15 18:05:39
Subject:Re: [rest-discuss] Re: Implementing REST and resource modeling
Message:

On Wed, May 15, 2002 at 02:24:30PM -0000, xemplify wrote:
> > That depends *how* it's being modified.  If the client knows the
> > desired state of the trade, then PUT is the correct method.
> 
> The client is receiving confirmations of trades from an exchange, and 
> needs to programmatically enter them in our system.
> 
> The trade may need modification because of a mistake; effectively the 
> client wants to store a complete new version of the trade, hence the 
> use of PUT (though old versions are retained, so perhaps POST more 
> relevant?).

Versioning can be done with PUT.  See the recent WebDAV versioning
work;

http://www.ietf.org/rfc/rfc3253.txt

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1259
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-15 18:48:36
Subject:Re: [rest-discuss] Why Paul is wrong about resource discovery viahypertext
Message:

Jeff Bone wrote:
> 
> On 5/15/02 11:00 AM, "Paul Prescod" <paul@...> wrote:
> 
> >
> >> By 'instance based' I meant 'instance of a resource'. You can't get the URI
> >> to a resource before the resource exists.
> 
> Mike, you might as well give up on this one, it's precisely the same issue
> as the generative naming stuff we were "discussing" earlier and Paul seems
> ideologically incapable of giving on this point. ;-)

It isn't the same issue at all. Mike says that you CANNOT statically
type a URI-described resource before the URI. Do you agree that this is
impossible?

> >
> > It's like saying you can't get a pointer to an object before it exists.
> 
> Yes, but you *can* **name** things that don't exist, or don't exist yet.

You aren't listening. Of course you can't get a pointer to an object
before it exists. But you CAN statically declare the object before you
have a pointer to it. And it is the static declaration that drives
"popups" in editor tools. The same goes for URI references and XML.

> And if you know how to build such names, your domain of possible discourse
> in your application is much larger.

I'll believe that when I see an application that demonstrates it.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1260
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-16 02:35:43
Subject:Re: [rest-discuss] Why Paul is wrong about resource discovery viahypertext
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

>
> It isn't the same issue at all. Mike says that you CANNOT statically
> type a URI-described resource before the URI. Do you agree that this is
> impossible?
That's not what I was saying. I don't have a problem with discovering the
data definition of a resource before any instances exist. I'm only concerned
with discovering what the URI for the future resource is.

To clarify, I was saying that you can't get a list of resources from a
server and expect that list to contain the URI for the resource you are
about to create. I want to PUT a comment to a discussion group - what URI
should I use? How do I use hyperlinking to discover the URI of the resource
that I want to create? Doing discovery on the resource representing the
discussion group will not provide the URI desired. Doing some other process
is needed - GET on a 'gimme the next uri please' resource followed by PUT,
using POST and having the server respond with the URI, etc.

It seems that PUT should only be used for update and not create - you still
have to have the server determine the URI and use a multi-step operation or
a different method. A client & server that have priviliged knowledge can
coordinate on the URI structure - and I'm fine with that - but I don't think
the broadest scope, most general solution would take that approach.

> You aren't listening. Of course you can't get a pointer to an object
> before it exists. But you CAN statically declare the object before you
> have a pointer to it.
Is this static declaration describing the structure of the state of a
resource? I know that getting the definition of the structure of a resource
is easy - but once I fill in the blanks, where do I PUT the data?








-----------------------------------------------------------------------------------
Post ID:1261
Sender:Ken MacLeod <ken@...>
Post Date/Time:2002-05-17 13:52:16
Subject:REST/SOAP ETCon session details?
Message:

Can someone who was at the ETCon session on REST and SOAP give a
summary?  Wes Felter said it was "entertaining" but there was very
little logged in IRC.

  -- Ken






-----------------------------------------------------------------------------------
Post ID:1262
Sender:"simonfell99" <sf@...>
Post Date/Time:2002-05-17 17:00:21
Subject:HTTP caching questions ?
Message:

Hi,

I'm in the process of prototyping a REST version of an existing RPC 
based system, a large chunk of this system revolves around 
efficiently managing updates to content at the client system. I'm 
looking at using the HTTP/1.1 caching support (Etag, If-Modified-
Since, If-None-Match and If-Range). I have some questions about how 
this works when deployed on a cluster of servers with a load 
balancer, is this a good place to ask, or can someone recommend a 
good list to discuss HTTP caching.

Tx
Simon







-----------------------------------------------------------------------------------
Post ID:1263
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-05-17 17:25:59
Subject:Re: [rest-discuss] REST/SOAP ETCon session details?
Message:

On 17 May 2002, Ken MacLeod wrote:

> Can someone who was at the ETCon session on REST and SOAP give a
> summary?  Wes Felter said it was "entertaining" but there was very
> little logged in IRC.
>
>   -- Ken

Not very productive.  In general the horse-race story about REST vs. SOAP
is overshadowing meaty stuff.  EG, there seemed to be a grudge match setup
about Paul's Google article on xml.com.








-----------------------------------------------------------------------------------
Post ID:1264
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-05-17 18:03:48
Subject:Re: [rest-discuss] REST/SOAP ETCon session details?
Message:

...the most useful point from the con WRT REST is emerging consensus that
web services has nothing to do with the web.  It's fine for what it is,
which is more or less EDI.










-----------------------------------------------------------------------------------
Post ID:1265
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-18 00:25:46
Subject:Re: [rest-discuss] HTTP caching questions ?
Message:

Have you tried www-talk@... ?

----- Original Message ----- 
From: "simonfell99" <sf@...>
To: <rest-discuss@yahoogroups.com>
Sent: Friday, May 17, 2002 10:00 AM
Subject: [rest-discuss] HTTP caching questions ?


> Hi,
> 
> I'm in the process of prototyping a REST version of an existing RPC
> based system, a large chunk of this system revolves around
> efficiently managing updates to content at the client system. I'm
> looking at using the HTTP/1.1 caching support (Etag, If-Modified-
> Since, If-None-Match and If-Range). I have some questions about how
> this works when deployed on a cluster of servers with a load
> balancer, is this a good place to ask, or can someone recommend a
> good list to discuss HTTP caching.
> 
> Tx
> Simon
> 
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> 
> 
> 






-----------------------------------------------------------------------------------
Post ID:1266
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-18 00:29:33
Subject:Re: [rest-discuss] REST/SOAP ETCon session details?
Message:

Lucas Gonze wrote:
>
> Not very productive.  In general the horse-race story about REST vs. SOAP
> is overshadowing meaty stuff.  EG, there seemed to be a grudge match
setup
> about Paul's Google article on xml.com.

IMHO, the discussion about meatier stuff is hampered by the types of
rhetoric we saw at the panel - remember when I took notes and then cited a
stream of terms like "democratrization", "no virtues", "binary would have
been just as good", etc?  It would be much more productive (again, IMHO) if
we could talk in terms of specifics suggestions.

I also believe that most of the asserted virtues of either an all-GET (or
even a more-GET) approach seem to be stated in ways that go over the head
of most of the intended audience - even when we had a VERY technical
audience like we enjoyed at the ETCON.

The one point that I'm most proud of is when I contrasted SOAP vs REST vs
GET approaches in what I thought was a more digestible form.  I was
pleasantly surprised that I got no pushback from those sitting to my right,
in fact after the panel you seemed to indicate that I had not
misrepresented REST.

If others who had attended feel that this part was comprehendable beyond
the scope of the people sitting on the panel, I will try to write it up.

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1267
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-18 20:50:51
Subject:Re: [rest-discuss] HTTP caching questions ?
Message:

I think it would be great if you asked the questions here. I am not
"deep" in HTTP cacheing but I know that Mark Nottingham is and I suspect
Mark Baker knows quite a bit also. This list seems to be the last refuge
of people who don't think of HTTP as a dinosaur ;). 

simonfell99 wrote:
> 
> Hi,
> 
> I'm in the process of prototyping a REST version of an existing RPC
> based system, a large chunk of this system revolves around
> efficiently managing updates to content at the client system. I'm
> looking at using the HTTP/1.1 caching support (Etag, If-Modified-
> Since, If-None-Match and If-Range). I have some questions about how
> this works when deployed on a cluster of servers with a load
> balancer, is this a good place to ask, or can someone recommend a
> good list to discuss HTTP caching.
> 
> Tx
> Simon
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/






-----------------------------------------------------------------------------------
Post ID:1268
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-18 20:53:15
Subject:Re: [rest-discuss] Why Paul is wrong about resource discovery viahypertext
Message:

"S. Mike Dierken" wrote:
> 
>...
> That's not what I was saying. I don't have a problem with discovering the
> data definition of a resource before any instances exist. 

I got confused because you were asking about popups in an IDE and the
relevance of WSDL. To be blunt, I think your question has evolved over
the course of the messages. ;)

> ... To clarify, I was saying that you can't get a list of resources from a
> server and expect that list to contain the URI for the resource you are
> about to create. I want to PUT a comment to a discussion group - what URI
> should I use? 

You want to POST a message to a discussion group? Use POST! It can
return a URI. Is there a hitch I don't see?

> It seems that PUT should only be used for update and not create - you still
> have to have the server determine the URI and use a multi-step operation or
> a different method. 

In general I would agree with that, but there is a subtlety. In some
situations (particularly content management) the client owns the
namespace and the server just puts things where the client asks.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1269
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-18 21:17:41
Subject:Re: [rest-discuss] REST/SOAP ETCon session details?
Message:

> Can someone who was at the ETCon session on REST and SOAP give a
> summary?  Wes Felter said it was "entertaining" but there was very
> little logged in IRC.

From a "getting stuff done" point of view, the thing was doomed from the
start. I had always had a sense that that was the case but I figured
that it was better than nothing. Many of the other talks presumed a SOAP
future so I thought it important that there be a session that at least
questioned that theory.

But consider that the same day of the session, Rohit Khare gave a talk
on an alternate model for web services (not REST (despite the fact that
he claims it is a superset of REST), not RPC and not traditional
messaging). He had 45 mins. He hardly had time in that period to explain
the idea and he didn't have a single slide showing an angle bracket or
network transmission. He didn't even describe, really, how SOAP supports
his model. (i.e. from a technical point of view it was mostly hand
waving)

Now contrast that with five guys trying to educate an audience and
debate a model *at the same time* in 45 mins, with no slides, while
constantly interrupting each other, with differing agenda. All you could
hope for is to get across the idea that there is a debate and that the
audience should look on the web for more information. That much was
accomplished.

Insofar as the burden of proof was on the REST guys (as we were
suggesting something different from the mainstream) I would expect that
a neutral observer would say that the REST case was NOT made. In the
last five minutes I hinted at the foundations of the REST case but only
an extremely charitable audience member would catch the whiff of that
and follow up through more research on the Web.

====

I also found it frustrating that Rohit quoted a definition of REST that
was not complete. I did not have opportunity to correct him but he used
his definition as a basis for the statement that he was the only one who
knew what REST is. In particular, his more generic definition allowed
him to say that SOAP (and particularly, SOAP Routing, his hobby horse)
was an extension of REST.

Whereas when I compare his talk (and the SOAP spec) against the
definition I use, I see almost no points of intersection:

"REST is defined by four interface constraints: identification of
resources; manipulation of resources through representations;
self-descriptive messages; and, hypermedia as the engine of application
state."

Neither SOAP nor SOAP Routing have first-class concepts of resources,
resource identifiers, representations of resources, or hypermedia. And I
would argue that the following typical SOAP message is not
self-descriptive but rather self-contradictory:

POST /foo/bar

<SOAP-crap>
  <getStockQuote>IBM</getStockQuote>
</SOAP-crap>

Is it posting information or getting information?

The points the other four speakers made were relatively predictable if
you've followed our arguments across the various fora.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1270
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-18 21:52:09
Subject:Re: [rest-discuss] REST/SOAP ETCon session details?
Message:

Paul Prescod wrote:
>
> I also found it frustrating that ... [snip]
>
> <SOAP-crap>
> <getStockQuote>IBM</getStockQuote>
> </SOAP-crap>

What I find frustrating is the consistent, continued, and entirely
unnecessary use of such derogatory terms.  Quite frankly, it makes a
rational discourse on the subject impossible.

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1271
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-18 22:05:55
Subject:Re: [rest-discuss] REST/SOAP ETCon session details? [long]
Message:

[sorry, this is a little long because it summarizes a variety of
conversations we've had recently]

Sam Ruby wrote:
> 
>...
> 
> IMHO, the discussion about meatier stuff is hampered by the types of
> rhetoric we saw at the panel - remember when I took notes and then cited a
> stream of terms like "democratrization", "no virtues", "binary would have
> been just as good", etc?  It would be much more productive (again, IMHO) if
> we could talk in terms of specifics suggestions.

I can itemize my complaints:

 * Shouldn't run at "level 8" but rather level 6 (on top of TCP, below
app protocols)
 * Shouldn't use port 80 (in fact shouldn't have a predefined port at
all)
 * Shouldn't use an envelope format that is hostile to binary data
 * Encoding should be separated out into a differently named spec and
rethought from scratch.
 * RPC should probably be just removed.
 * Should have as a design requirement that it is a solid basis for
application protocols like a next generation HTTP or SMTP (i.e. the HTTP
binding for SOAP should be HTTP *over SOAP* not SOAP over HTTP)
 * Should use IP addresses rather than URIs for addressing (resource
addressing is an application layer issue)

I may have forgotten some but you get the gist. Generally, when you have
so many complaints about a technology the easier way to say it is: "It's
all wrong." That offends people but it also saves their time.

>...
> I also believe that most of the asserted virtues of either an all-GET (or

I don't think anybody on this list would promote an all-GET approach
unless the service was read-only.

> even a more-GET) approach seem to be stated in ways that go over the head
> of most of the intended audience - even when we had a VERY technical
> audience like we enjoyed at the ETCON.

I agree that that is the case. If you do not have a background of
thinking about information systems as addressable information spaces
(many XML people do, most others don't) then it requires a mental change
like the shift from procedural programming to event-driven programming.
Some (probably not Sam) feel that this demonstrates that the
information-space model is doomed. My sense is that people make mental
leaps when they need to, to solve a problem. Over the next few years it
will become clear whether this mental leap is really necessary or just
convenient for some problems. Object orientation took about twenty-five
years to overcome industry inertia and filter out to a point where
ordinary people understand it.

> The one point that I'm most proud of is when I contrasted SOAP vs REST vs
> GET approaches in what I thought was a more digestible form.  I was
> pleasantly surprised that I got no pushback from those sitting to my right,
> in fact after the panel you seemed to indicate that I had not
> misrepresented REST.

Well Dave Winer spoke after you so I didn't really have a chance to jump
in. Different people have different definitions, just as they do about
OO. Jeff Bone focuses on consistency of interfaces. I focus on
addressability. IIRC, you focused on using the HTTP methods properly. I
don't think any of the definitions are right or wrong, they just address
different but related aspects. 

I focus on addressability because of my information-space background and
because I feel that it is a particularly obvious weak point of the
standard web services stack. Even COM and CORBA have much more
interoperable addressing models than SOAP.

You said that there was a third camp that said to "use GET for
everything." That's a misunderstanding of REST but I don't know that it
is any more pervasive than other misunderstandings, like "use POST for
everything" (after all, as long as you use HTTP without SOAP you are
doing REST, right?). Some people also think that REST means
"asynchronous messaging". i.e. people think that whatever they like that
is not SOAP must be REST. ;)

BTW, you mentioned the Amazon associates API. From what I could see on
Simon's page it *was* relatively REST-y. I am not an Amazon associate so
I can't see the details of their API. Simon's summary is here:

 * http://www.xmlhack.com/read.php?item=1615

I feel bad that I had to disclaim responsibility for it because I didn't
mean to leave the Amazon people looking silly (I know they were in the
audience). If there are parts of the API that use GET to mean PUT, POST
or DELETE then I would agree that those parts aren't REST-y. The parts I
can see look like a good start towards full REST-yness.

> If others who had attended feel that this part was comprehendable beyond
> the scope of the people sitting on the panel, I will try to write it up.

My sense is that just as with OO, there are a variety of correct ways to
summarize the REST model. Your approach would probably be a valuable
addition.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1272
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-05-18 22:03:15
Subject:REST Tutorial
Message:

I have posted my first release of a tutorial on REST[1].  I would
appreciate it if you would notify me if you notice any mistakes, or have
suggestions on things to add, or suggestions on how to improve it. 
Thanks!  /Roger

[1] http://www.xfront.com/REST.ppt







-----------------------------------------------------------------------------------
Post ID:1273
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-18 22:17:41
Subject:Re: [rest-discuss] REST/SOAP ETCon session details? [long]
Message:

Paul Prescod wrote:
>
> I can itemize my complaints:

I could try to do a point by point rebuttal, but for now, the following
will suffice:

> * Shouldn't use port 80 (in fact shouldn't have a predefined port at
> all)

It doesn't.

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1274
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-19 05:14:44
Subject:Re: [rest-discuss] REST Tutorial
Message:

Looks like an excellent summary! I'll just go through some nits. 

Here are some points to consider.

 Slide 5:

"http://www.parts-depot.com/parts-list?flavor=xml"

A hard-core HTTP-head would suggest you use content negotiation instead. 

 * http://www.prescod.net/http/content_negotiation.html

Slide 8:

I don't think I'd make PartQuantity into a resource type. I'd make
*Part* into a resource type. Quantity would be just an element in there.
This could collapse your part list into a simple list of URIs and
prevent the slightly weird linking from the PartQuantity back into the
Part.

Slide 9:

SOAP is not an application protocol so it doesn't prescribe much of a
data model (roughly the same data model as UDP -- there are things you
can send messages to) This makes it hard to assess the "SOAP Way" of
doing any particular thing. Really it is SOAP toolkits and WSDL that
most clearly say what you can and cannot do easily with SOAP. In
particular, the SOAP specification does not say that an entire service
must be served off of a particular URI (even if it is strongly implied).
I doubt that the most popular SOAP toolkits are well set-up to allow
dynamically created SOAP endpoints so practically speaking the "SOAP
way" is accurate but you should know the difference between what SOAP
requires and what it "strongly suggests".

Slide 11:

You say: "Note the absence of
links.  Why is this?
Links use HTTP GET,
but SOAP only supports
HTTP POST."

I don't think that's quite the way to put it.

Given an HTTP URI, it is possible to treat it as either an HTTP resource
or a SOAP endpoint. If you decide to treat it as an HTTP resource then
that part of your service is REST-ful. If you decide to treat it as a
SOAP endpoint then you have a problem: what method do you use to resolve
it to some actual information? You can't look in the WSDL because WSDL's
describes one and only one endpoint, not the relationship between
endpoints. Even if you had the WSDL available, how would you know which
of the methods to use? Unless there were some "GET-ter" annotation in
WSDL, you don't know. 

 Slide 16:

"As a result of REST having a common interface any client can use any
service without prior coordination."

There is a little bit of subtlety here. Any HTTP client can talk to any
HTTP server. This is mostly true also of SOAP, except for the fact that
SOAP runs on a bunch of transports so you also have to get the transport
right.

But in either case the more important question is whether you can do
anything useful without prior coordination. Here's a document I've
written about that:

 * http://www.prescod.net/rest/standardization.html

 Slide 19:

"SOAP is simply an XML version of CORBA/DCOM/RMI"

That's the case for SOAP RPC but for SOAP in general, I predict SOAP
advocates would say:

    1. The "big problem" with CORBA was that Microsoft didn't support
it. The "big problem" with DCOM was that it doesn't work on Unix. The
problem with Java RMI is that it doesn't work with non-Java programming
languages. Everyone agrees on SOAP so the network effects can kick in.
(not the level of network effects we get from HTTP, but better than the
network effects from proprietary RPC protocols)

   2. SOAP inherits the extensibility of XML and this allows "loose
coupling". It also allows non-RPC message exchange patterns --
particularly asynchronous ones. 

Slide 21:

There should probably be a Meerkat WSDL. I'll look into that one day.
Meerkat could be even better if it had a way to do discovery by
hyperlink navigation rather than just queries.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1275
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-05-19 16:52:55
Subject:Re: [rest-discuss] REST Tutorial
Message:

Thanks a lot Paul!  I have incorporated all of your suggestions, as well
as added new material.  

I think that my Parts Depot example is now in line with your
suggestion.  If you (or anyone else) has comments on it I would very
much appreciate hearing them.  

All suggestions, criticisms are welcome. /Roger

http://www.xfront.com/REST.ppt



Paul Prescod wrote:
> 
> Looks like an excellent summary! I'll just go through some nits.
> 
> Here are some points to consider.
> 
>  Slide 5:
> 
> "http://www.parts-depot.com/parts-list?flavor=xml"
> 
> A hard-core HTTP-head would suggest you use content negotiation instead.
> 
>  * http://www.prescod.net/http/content_negotiation.html
> 
> Slide 8:
> 
> I don't think I'd make PartQuantity into a resource type. I'd make
> *Part* into a resource type. Quantity would be just an element in there.
> This could collapse your part list into a simple list of URIs and
> prevent the slightly weird linking from the PartQuantity back into the
> Part.
> 
> Slide 9:
> 
> SOAP is not an application protocol so it doesn't prescribe much of a
> data model (roughly the same data model as UDP -- there are things you
> can send messages to) This makes it hard to assess the "SOAP Way" of
> doing any particular thing. Really it is SOAP toolkits and WSDL that
> most clearly say what you can and cannot do easily with SOAP. In
> particular, the SOAP specification does not say that an entire service
> must be served off of a particular URI (even if it is strongly implied).
> I doubt that the most popular SOAP toolkits are well set-up to allow
> dynamically created SOAP endpoints so practically speaking the "SOAP
> way" is accurate but you should know the difference between what SOAP
> requires and what it "strongly suggests".
> 
> Slide 11:
> 
> You say: "Note the absence of
> links.  Why is this?
> Links use HTTP GET,
> but SOAP only supports
> HTTP POST."
> 
> I don't think that's quite the way to put it.
> 
> Given an HTTP URI, it is possible to treat it as either an HTTP resource
> or a SOAP endpoint. If you decide to treat it as an HTTP resource then
> that part of your service is REST-ful. If you decide to treat it as a
> SOAP endpoint then you have a problem: what method do you use to resolve
> it to some actual information? You can't look in the WSDL because WSDL's
> describes one and only one endpoint, not the relationship between
> endpoints. Even if you had the WSDL available, how would you know which
> of the methods to use? Unless there were some "GET-ter" annotation in
> WSDL, you don't know.
> 
>  Slide 16:
> 
> "As a result of REST having a common interface any client can use any
> service without prior coordination."
> 
> There is a little bit of subtlety here. Any HTTP client can talk to any
> HTTP server. This is mostly true also of SOAP, except for the fact that
> SOAP runs on a bunch of transports so you also have to get the transport
> right.
> 
> But in either case the more important question is whether you can do
> anything useful without prior coordination. Here's a document I've
> written about that:
> 
>  * http://www.prescod.net/rest/standardization.html
> 
>  Slide 19:
> 
> "SOAP is simply an XML version of CORBA/DCOM/RMI"
> 
> That's the case for SOAP RPC but for SOAP in general, I predict SOAP
> advocates would say:
> 
>     1. The "big problem" with CORBA was that Microsoft didn't support
> it. The "big problem" with DCOM was that it doesn't work on Unix. The
> problem with Java RMI is that it doesn't work with non-Java programming
> languages. Everyone agrees on SOAP so the network effects can kick in.
> (not the level of network effects we get from HTTP, but better than the
> network effects from proprietary RPC protocols)
> 
>    2. SOAP inherits the extensibility of XML and this allows "loose
> coupling". It also allows non-RPC message exchange patterns --
> particularly asynchronous ones.
> 
> Slide 21:
> 
> There should probably be a Meerkat WSDL. I'll look into that one day.
> Meerkat could be even better if it had a way to do discovery by
> hyperlink navigation rather than just queries.
> 
>  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:1276
Sender:"xemplify" <xemplify@...>
Post Date/Time:2002-05-19 17:09:15
Subject:Re: REST Tutorial
Message:

--- In rest-discuss@y..., "Roger L. Costello" <costello@m...> wrote:
> I have posted my first release of a tutorial on REST[1].  I would
> appreciate it if you would notify me if you notice any mistakes,
> or have
> suggestions on things to add, or suggestions on how to improve it. 
> Thanks!  /Roger
> 
> [1] http://www.xfront.com/REST.ppt


I'm very interested in reading your tutorial. Unfortunately I haven't
worked out how to view ppt files in Linux yet, nor do I think I should
have to. So reading your tutorial will have to wait until I next boot
an operating system that has an application that can view that
proprietary format.

Perhaps your REST tutorial resource URI should follow REST
principles? ;)

Then I could:

GET /rest/tutorial?flavor=html HTTP/1.1
Host: www.xfront.com

or following Paul's content negotiation suggestion:

GET /rest/tutorial HTTP/1.1
Host: www.xfront.com
Accept: text/plain, text/html

and hopefully get a version of the tutorial that my browser can
render.

Regards,
Robert







-----------------------------------------------------------------------------------
Post ID:1277
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-19 17:48:32
Subject:Re: [rest-discuss] Re: REST Tutorial
Message:

xemplify wrote:
> 
> ...
> 
> Perhaps your REST tutorial resource URI should follow REST
> principles? ;)

Or Google could expose a REST interface to their PPT->HTML rendering
engine. ;)

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1278
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-05-19 17:49:13
Subject:Re: [rest-discuss] Re: REST Tutorial
Message:

On Sun, May 19, 2002 at 05:09:15PM -0000, xemplify wrote:

> > I have posted my first release of a tutorial on REST[1].  I would
> 
> I'm very interested in reading your tutorial. Unfortunately I haven't
> worked out how to view ppt files in Linux yet, nor do I think I should
> have to.

I agree you shouldn't have to, but if you want to, StarOffice/OpenOffice
and KPresenter have PowerPoint import filters. I haven't used them a
whole lot, but to the extent I have the results are usually imperfect
but readable. Though KPresenter seems to be choking on this particular
file.

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:1279
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-19 17:54:42
Subject:Re: [rest-discuss] REST/SOAP ETCon session details?
Message:

Sam Ruby wrote:
> 
> Paul Prescod wrote:
> >
> > I also found it frustrating that ... [snip]
> >
> > <SOAP-crap>
> > <getStockQuote>IBM</getStockQuote>
> > </SOAP-crap>
> 
> What I find frustrating is the consistent, continued, and entirely
> unnecessary use of such derogatory terms.  Quite frankly, it makes a
> rational discourse on the subject impossible.

I won't apologize, because I think that that's pretty par for the course
on technical mailing lists on the Internet. After all, you aren't SOAP
and SOAP isn't you. Therefore I haven't insulted you. Nevertheless,
since it bothers you I'll try to be more ecumenical in posts that I
expect you to see.

Still, there have been occasions where you have taken my statements of
fact as rhetoric. For instance, when I say that a Java client generated
from a WSDL+HTTP client can be byte-for-byte the same as one generated
from a WSDL+SOAP client, that's just a statement of fact. When I say
that Google's service would have become very popular (as long as they
documented it and provided Java client libraries) even if it had been
based upon S-expressions or binary or totally proprietary XML, that's a
statement of opinion, but not, in my mind, empty rhetoric.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1280
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-19 18:27:46
Subject:Re: [rest-discuss] REST/SOAP ETCon session details? [long]
Message:

Sam Ruby wrote:
> 
>...
> 
> I could try to do a point by point rebuttal, but for now, the following
> will suffice:
> 
> > * Shouldn't use port 80 (in fact shouldn't have a predefined port at
> > all)
> 
> It doesn't.

If you use the SOAP HTTP binding and you do not choose a port
explicitly, it uses port 80 by default. It shouldn't. It should run
underneath the application protocol and let the application protocol
pick the port.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1281
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-19 18:12:12
Subject:Re: [rest-discuss] REST Tutorial
Message:

First the nits:

*  a more "RESTful" version of the xlink:href would expose the part as a
   part of the path and not merely as a query expression.  In other words,
   I'd suggest replacing:

      xlink:href="http://www.parts-depot.com/part?id=00345

   with

      xlink:href="http://www.parts-depot.com/part/00345

*  Soap encoding tends to favor usage of the element content over
   attributes.  I'd suggest changing your example for getPartsListResponse
   from:

      <part id="00345">

   to

      <part-id>00345</part-id>

 = = = =

The next point is a bit more subtle.  I've tried to express it in a number
of different forums in a number of different ways, each time with little
success.  I'm not going to try a bit of humor to see if it helps.

It is a bit ironic that a set of architectural practices under the title of
"Representation State Transfer" defines virtually nothing about the way in
which state is to be represented, and instead focuses on how Objects (or
more precisely, resources) are to be accessed.

Similarly, I find it a bit ironic that a protocol originally created as an
acronym for Simple Object Access Protocol specifies nothing about how an
object is to be accessed, but instead focuses pretty much exclusively on
how messages are to be represented.  For more details on this subject, see
http://radio.weblogs.com/0101679/stories/2002/01/25/whatObjectDoesSoapAccess.html

It is very easy to come up with an example where one schema includes links
and other does not, associate the first with a URL and place the second in
an envelope and then portray this as a fundamental difference between SOAP
and REST.  The truth is that HTTP nor SOAP require nor preclude "proper"
links.

Similarly, one can come up with an example where a resource is identified
based on query parameters in a URL and another in which a resource is
identified inside the body and portray this too as a fundamental
difference.  This too is false as there are a number of SOAP toolkits which
will happily dispatch requests based on the URL.  Furthermore, REST is an
architectural style - it does not dictate syntax.  See
http://www.xent.com/pipermail/fork/2001-August/002941.html for more on this
topic, including the views of Roy Fielding on XML itself.

I will go a step further and indicate that it is possible to architect a
system in accordance to the principles of REST and then implement it using
SOAP.  In other words, these two are compatible.  I would argue that the
deeper issue is that SOAP does little to require such an architectural
style, in fact, most of the examples to date seem to espouse a different
architectural style.   I discuss this further in
http://www.oreillynet.com/cs/weblog/view/wlg/1351#Analogy

 = = = =

 The reason I joined this mailing list, and have persisted, is that it is
my hope that some day a paper can be jointly authored which shows both SOAP
and REST in a positive light, shows the strengths of both, and how they can
be used in concert.

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1282
Sender:Chris Croome <chris@...>
Post Date/Time:2002-05-19 18:43:18
Subject:Re: [rest-discuss] Re: REST Tutorial
Message:

Hi

On Sun 19-May-2002 at 11:49:13 -0600, Matt Gushee wrote:
> 
> I agree you shouldn't have to, but if you want to,
> StarOffice/OpenOffice and KPresenter have PowerPoint import filters. I
> haven't used them a whole lot, but to the extent I have the results
> are usually imperfect but readable. Though KPresenter seems to be
> choking on this particular file.

I didn't have any luck with it either using OpenOffice (got the lines
and boxes but no text). Generally I find that the free office viewers
from MS running in wine are often the best way to view .ppt and .doc
files.

Chris

-- 
Chris Croome                               <chris@...>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   
everything else                               http://chris.croome.net/  






-----------------------------------------------------------------------------------
Post ID:1283
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-19 19:30:39
Subject:Re: [rest-discuss] REST Tutorial
Message:

Sam Ruby wrote:
> 
>...
> 
> It is a bit ironic that a set of architectural practices under the title of
> "Representation State Transfer" defines virtually nothing about the way in
> which state is to be represented, and instead focuses on how Objects (or
> more precisely, resources) are to be accessed.
> 
> Similarly, I find it a bit ironic that a protocol originally created as an
> acronym for Simple Object Access Protocol specifies nothing about how an
> object is to be accessed, but instead focuses pretty much exclusively on
> how messages are to be represented.  For more details on this subject, see
> http://radio.weblogs.com/0101679/stories/2002/01/25/whatObjectDoesSoapAccess.html


Interesting point.

> It is very easy to come up with an example where one schema includes links
> and other does not, associate the first with a URL and place the second in
> an envelope and then portray this as a fundamental difference between SOAP
> and REST.  The truth is that HTTP nor SOAP require nor preclude "proper"
> links.

True. But HTTP defines a way to transform a URI into bit stream (GET
$URI). SOAP does not. 

> Similarly, one can come up with an example where a resource is identified
> based on query parameters in a URL and another in which a resource is
> identified inside the body and portray this too as a fundamental
> difference.  This too is false as there are a number of SOAP toolkits which
> will happily dispatch requests based on the URL.  

That is certainly true for URLs known at "deploy time". But I do not
believe that it is true for URLs invented at runtime. For instance if I
do a createStockTicker("RUBY") message, can any existing SOAP toolkit
return:

<NewTickerURI>http://www...../RUBY</NewTickerURI>

And then have the client do method calls against the newly created
endpoint. WSDL certainly does not support strongly and statically type
declaring this interaction. That's its biggest flaw when it comes to
REST.

> .... Furthermore, REST is an
> architectural style - it does not dictate syntax.  

That's absolutely true. I've thought about the idea of a REST-on-SOAP
and found a few problems:

 1. in order for us to achieve economies of scale, we must agree on
syntax. If half of the world uses REST-HTTP and half uses REST-SOAP then
we will have problems talking to each other.

 2. Who is going to go to the effort of creating REST-SOAP? If it isn't
people who were involved with HTTP, are they likely to get it right?

 3. REST-on-SOAP would not combine the best virtues of HTTP and SOAP.
One of HTTP's virtues as an envelope is that it is data type agnostic.
It is as happy to carry binary as text. XML wasn't engineered for that.
Therefore I don't see XML is a good choice for an envelope format.

    * http://www.prescod.net/xml/envelopes/

 4. I don't personally like the SOAP encoding much (IMO, confusing and
complicated) and there are a variety of choices for XML-based object
encoding out there. So I don't see SOAPENC as much of a "win".

 5. If the default transport for SOAP will be HTTP then we'll have SOAP
running on HTTP and something HTTP-like running on SOAP. We'll be up to
"layer 9" in the protocol stack and layer 7 will be totally useless --
just a firewall-evasion technique.

> I will go a step further and indicate that it is possible to architect a
> system in accordance to the principles of REST and then implement it using
> SOAP.  In other words, these two are compatible.  I would argue that the
> deeper issue is that SOAP does little to require such an architectural
> style, in fact, most of the examples to date seem to espouse a different
> architectural style.   I discuss this further in
> http://www.oreillynet.com/cs/weblog/view/wlg/1351#Analogy

I think that my point 1 is crucial. If Sam Ruby architects a system
according to REST principles using a SOAP syntax that Sam Ruby invents,
and Paul Prescod architects a system according to REST principles
according to a SOAP syntax that Paul Prescod invents, etc., then we have
no economies of scale and all of the virtues of REST are lost. We only
win if we agree. One way to agree is to say: "Use HTTP". Another way to
agree is to invent HTTP-on-SOAP-on-HTTP and then say "use that". If
three years from now we decide that we really can't convince people to
use HTTP then probably we will have to reinvent it two levels up ("Web
Services Resource Manipulation Language") and then we could launch a
buzzword offensive around it, rewrite all of the existing software two
levels up and become IPO millionaires. Wait a second, why didn't I like
that idea again?

Nevertheless, you are right that syntax is just syntax. HTTP could be
reinvented in SOAP syntax and if we all adopted it we would get all of
the advantages of REST. You would lose some aspects of the HTTP syntax
(e.g. straightforward binary handling) but that wouldn't be major.

>  = = = =
> 
>  The reason I joined this mailing list, and have persisted, is that it is
> my hope that some day a paper can be jointly authored which shows both SOAP
> and REST in a positive light, shows the strengths of both, and how they can
> be used in concert.

Actually, I am interested in this also, but I have a feeling that we
would disagree on the virtues of SOAP. Nevertheless, it would be
illuminating for me to hear your list of what SOAP has to offer REST.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1284
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-05-19 20:46:41
Subject:REST Tutorial - HTML version
Message:

I have created an HTML version of my REST tutorial:

http://www.xfront.com/REST.html

All suggestions, criticisms are welcome.  /Roger







-----------------------------------------------------------------------------------
Post ID:1285
Sender:Simon Fell <sf@...>
Post Date/Time:2002-05-19 20:58:30
Subject:Re[2]: [rest-discuss] HTTP caching questions ?
Message:

ok, here goes.

Basically i need to support efficient checks that content is upto
date, and to also support resumable downloads [some of the content is large
binary files accessed via a potentially un-reliable low bandwidth
connection]. This content is potentially served by a set of web servers
running behind a HTTP load balancer.

For a single server scenario, this seems pretty straightforward, At
the client cache I track expected size [from the content-length
header], Etag and last-modified. for subsequent requests I populate a
If-None-Match header from the etag, a Range & Range-If header if the
expected size is not the same as the cached file size, and i send a
If-Modified-Since header if i don't have a Range header [my reading of
the use of Range & Range-If lead me to believe to not use
If-Modified-Since if i'm using ranges].

My concern is when i have 2 or more web servers, all running behind a
load balancer [local director etc], that each server will be assigning
different etags to the same content (i don't see anything in the spec
that lets me assume different server instances will generate the same
etag for the same content, even for the same versions of HTTP server
software). This is leading me to think about not using etags, and to
just use the modified date, but then it doesn't look like you can do
ranges with modified dates. Its also crossed my mind to use
content-md5, but this doesn't seem very widely support [if at all].

Any suggestions ?

Thanks
Simon

Saturday, May 18, 2002, 1:50:51 PM, you wrote:

> I think it would be great if you asked the questions here. I am not
> "deep" in HTTP cacheing but I know that Mark Nottingham is and I suspect
> Mark Baker knows quite a bit also. This list seems to be the last refuge
> of people who don't think of HTTP as a dinosaur ;). 

> simonfell99 wrote:
>> 
>> Hi,
>> 
>> I'm in the process of prototyping a REST version of an existing RPC
>> based system, a large chunk of this system revolves around
>> efficiently managing updates to content at the client system. I'm
>> looking at using the HTTP/1.1 caching support (Etag, If-Modified-
>> Since, If-None-Match and If-Range). I have some questions about how
>> this works when deployed on a cluster of servers with a load
>> balancer, is this a good place to ask, or can someone recommend a
>> good list to discuss HTTP caching.
>> 
>> Tx
>> Simon
>> 
>> 
>> To unsubscribe from this group, send an email to:
>> rest-discuss-unsubscribe@yahoogroups.com
>> 
>> 
>> 
>> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:1286
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-20 00:41:04
Subject:Re: [rest-discuss] REST Tutorial
Message:

Paul Prescod wrote:
>
> Interesting point.

Whoah!

Are the lines of communication cracking open, if even a tiny bit?

;-)

> For instance if I
> do a createStockTicker("RUBY") message, can any existing SOAP toolkit
> return:
>
> <NewTickerURI>http://www...../RUBY</NewTickerURI>
>
> And then have the client do method calls against the newly created
> endpoint.

Would Axis count?  When Axis is deployed as a servlet, one can map a
url-pattern to the AxisServlet.  One can then deploy a transport specific
handler which obtains the relative path and does something appropriate with
that information.

> WSDL certainly does not support strongly and statically type
> declaring this interaction. That's its biggest flaw when it comes to
> REST.

Several points.  First, WSDL need not be strongly typed.  I provide a
complete and working example of this in
http://radio.weblogs.com/0101679/stories/2002/02/15/aBusyDevelopersGuideToWsdl11.html.

 Second, it is possible that a WSDL could be generated dynamically for such
URLs.  And finally, WSDL is not required.

> I've thought about the idea of a REST-on-SOAP
> and found a few problems

I won't go point by point through these at this time.  I feel that you do
have a legitimate beef about SOAP over HTTP, but continue to make
distracting and somewhat irrelevant points, and I would like to focus first
on the core issues.  For example, a position that SOAP over HTTP should
never be used is one that I see as internally self consistent, but not one
that says that HTTP should have a default port, but SOAP over HTTP should
not.

The next step is to discuss the relationship between HTTP and REST.  There
are not synonymous.  In particular, there are quite a number of uses of
HTTP that are inconsistent with REST, including most CGI based
applications, and by implication most servlets, ASPs, ColdFusion
applications, PHP applications and the like.  And don't even begin to
mention cookies...

Yet none of these seem to inspire the vitriol that SOAP has received.

> Actually, I am interested in this also, but I have a feeling that we
> would disagree on the virtues of SOAP. Nevertheless, it would be
> illuminating for me to hear your list of what SOAP has to offer REST.

Again, I think we need to separate REST and HTTP first.  And establish that
HTTP is not the one answer to every question.

A good place to start that discussion is with Don Box's observations:
http://zdnet.com.com/2100-1105-845220.html

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1287
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-05-20 01:09:55
Subject:RE: [rest-discuss] REST Tutorial - HTML version
Message:

Very nice, Roger.
 
Some comments;
 
- slide 9, I'd avoid using fragment identifiers.  Better to just use
/part/23234 or /part?id=23234
- slide 18, REST allows for extension methods beyond
GET/PUT/POST/DELETE, so long as the method is applicable to all
resources
- slide 19, you might also want to mention that security is also better
with REST because it is well known what the methods mean
- slide 21, I think you mean "Web", not "Internet"
 
MB





-----------------------------------------------------------------------------------
Post ID:1288
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-05-20 02:03:59
Subject:Re: [rest-discuss] REST Tutorial
Message:

On Sun, May 19, 2002 at 08:41:04PM -0400, Sam Ruby wrote:
> The next step is to discuss the relationship between HTTP and REST.  There
> are not synonymous. 

So far, so good, but ...

> In particular, there are quite a number of uses of
> HTTP that are inconsistent with REST, including most CGI based
> applications, and by implication most servlets, ASPs, ColdFusion
> applications, PHP applications and the like.

Where do you get that idea? I don't claim to be a REST wizard, but I've
been following this discussion for 3 months, and I haven't known anyone
to suggest such a thing. In fact, one of the core principles of REST as
I understand it is that the implementation of a REST resource is opaque
to the client, which implies that it would be quite appropriate to 
generate a representation using any of the above technologies.

Or are you referring to the fact that CGI apps and such tend to use a
lot of query strings? But that's really a matter of common usage, not
an intrinsic feature of any of those technologies. And it seems to me
that the consensus--to the extent there is one--is that query strings 
are discouraged because they obscure the relationships between resources,
but are by no means forbidden. 

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:1289
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-20 02:12:30
Subject:Re: [rest-discuss] REST Tutorial
Message:

Matt Gushee wrote:
>
> So far, so good, but ...
>
>> In particular, there are quite a number of uses of
>> HTTP that are inconsistent with REST, including most CGI based
>> applications, and by implication most servlets, ASPs, ColdFusion
>> applications, PHP applications and the like.
>
> Where do you get that idea? I don't claim to be a REST wizard, but I've
> been following this discussion for 3 months, and I haven't known anyone
> to suggest such a thing. In fact, one of the core principles of REST as
> I understand it is that the implementation of a REST resource is opaque
> to the client, which implies that it would be quite appropriate to
> generate a representation using any of the above technologies.
>
> Or are you referring to the fact that CGI apps and such tend to use a
> lot of query strings? But that's really a matter of common usage, not
> an intrinsic feature of any of those technologies. And it seems to me
> that the consensus--to the extent there is one--is that query strings
> are discouraged because they obscure the relationships between resources,
> but are by no means forbidden.

http://lists.w3.org/Archives/Public/www-tag/2002Apr/0181.html

This was written by the same Roy T. Fielding that wrote:

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1290
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-20 02:15:15
Subject:Re: [rest-discuss] REST Tutorial
Message:

Sam Ruby wrote:
> 
>...
> > For instance if I
> > do a createStockTicker("RUBY") message, can any existing SOAP toolkit
> > return:
> >
> > <NewTickerURI>http://www...../RUBY</NewTickerURI>
> >
> > And then have the client do method calls against the newly created
> > endpoint.
> 
> Would Axis count?  When Axis is deployed as a servlet, one can map a
> url-pattern to the AxisServlet.  One can then deploy a transport specific
> handler which obtains the relative path and does something appropriate with
> that information.

Is this simple or rocket science? Maybe you could write a tutorial one
day.
 
> > WSDL certainly does not support strongly and statically type
> > declaring this interaction. That's its biggest flaw when it comes to
> > REST.
> 
> Several points.  First, WSDL need not be strongly typed.  I provide a
> complete and working example of this in
> http://radio.weblogs.com/0101679/stories/2002/02/15/aBusyDevelopersGuideToWsdl11.html.
> 
>  Second, it is possible that a WSDL could be generated dynamically for such
> URLs.  And finally, WSDL is not required.

WSDL is not required in a theoretical sense but it is in a practical
sense. Deploying WSDL-less web services will become increasingly
difficult over the next few months. Already XMethods does not support
WSDL-less services. Java and .NET programmers will start screaming
bloody murder if you don't give them WSDLs compatible with "wsdl.exe"
and "wsdl2java". They will not be happy with WSDLs that are not strongly
typed. IMO, WSDL is for strong, static type declarations. Generating it
dynamically, or declaring things anyType remove its value.

> > I've thought about the idea of a REST-on-SOAP
> > and found a few problems
> 
> I won't go point by point through these at this time.  I feel that you do
> have a legitimate beef about SOAP over HTTP, but continue to make
> distracting and somewhat irrelevant points, and I would like to focus first
> on the core issues.  For example, a position that SOAP over HTTP should
> never be used is one that I see as internally self consistent, but not one
> that says that HTTP should have a default port, but SOAP over HTTP should
> not.

"Applications communicate with the transport protocols through the use
of 'ports' which are unique I/O identifiers used by the ransport
protocols and hte specific instance of the application protocol."

"Just as every device on an IP network has a unique IP address, every
instance of every application protocol also has a unique port number
that is used to identify it to the transport protocols on the local
system."

 * "Internet Core Protocols"

It is my belief that a protocol should have a port number if and only if
it is an application protocol. I define application protocol as a
protocol that has a concept of:

 a) addressable data objects
 b) standardized methods on those data objects
 c) standardized semantics for those methods

This definition holds for FTP, HTTP, SMTP, NNTP etc. It doesn't hold for
SOAP, DCOM, RMI, etc. Individual applications *built on top of* SOAP,
DCOM, and RMI should have ports. For instance if you use SOAP and WSDL
to define the Astronomical Data Interchange Protocol then it should have
a port. If you use them to define the Supermodel Scheduling Protocol,
that should have a port too. The fact that they have different ports
would allow system administrators to do different different kinds of
filtering on different ports. 

For instance, virus checking on HTTP is relatively easy because there
are only a couple of different ways to *directly* represent a binary
attachment in HTTP. But then XML-RPC adds another. And SOAP adds two or
three more (base64, SwA, DIME). The "multiplexing" of the multiple
protocols on the same port makes system administration more difficult.
"Party at port 80."

> The next step is to discuss the relationship between HTTP and REST.  There
> are not synonymous.  In particular, there are quite a number of uses of
> HTTP that are inconsistent with REST, including most CGI based
> applications, and by implication most servlets, ASPs, ColdFusion
> applications, PHP applications and the like.  And don't even begin to
> mention cookies...

There are varying degrees of compatibility with REST. I don't know how
to count "most" CGIs etc. There are a ton out there that are mostly
RESTful, like Google, Mapquest, Expedia, Slashdot, Wiki. All over the
Web I see URIs of the form 

http://..../foo.php?some_other_stuff

They are obeying the REST principle of "identification of resources" and
"hypermedia as the engine of application state." They adhere to the
other REST constraints basically for free by using HTTP.
 
> Yet none of these seem to inspire the vitriol that SOAP has received.

It is not possible to prevent all people everywhere from abusing a
protocol. I'm not that much of a windmill tilter. But it should be
possible to prevent the standards body tasked with the advancement of
the Web from canonizing a specification that abuses the Web protocol.
There are also sociological reasons to dislike a specification handed
down from a smoke-filled room to be rubber stamped by the masses,
whether it makes technical sense or not. But note that the sociological
problems only started to bother me when I came to recognize the
technical shortcomings. WSDL will stay in my good graces if it fixes its
technical problems although it also came from a smoke-filled room.
 
> > Actually, I am interested in this also, but I have a feeling that we
> > would disagree on the virtues of SOAP. Nevertheless, it would be
> > illuminating for me to hear your list of what SOAP has to offer REST.
> 
> Again, I think we need to separate REST and HTTP first.  And establish that
> HTTP is not the one answer to every question.

I am willing to grant that HTTP is not the answer to every question.
Then we can move on to the next part of the conversation. ;)

> A good place to start that discussion is with Don Box's observations:
> http://zdnet.com.com/2100-1105-845220.html

We discussed that before you came to rest-discuss. If you can stand to
go through Yahoo's increasingly intrusive interfaces:

 * http://groups.yahoo.com/group/rest-discuss/message/799

Summary: You can build synchrony on top of asynchrony or vice versa. You
can build reliable-but-inefficient on top of unreliable-but-efficient
(though not vice versa!).You can build bidirectional on top of
unidirectional or vice versa. Anyhow, if you want to go out and define a
REST-friendly protocol that selects a different set of defaults than
HTTP, by all means do that. I think it will lose out on some network
effects but it still might be a tecnically interesting protocol.

SOAP does not, in my mind, represent forward progress in that direction.
SOAP "handles" asynchrony by delegating it down to the underlying
transport protocol. SOAP handles REST (and addressing, and method
standardization) by delegating it up to the application level. In
increasingly mainstream usage, SOAP "handles" type declarations by
delegating them XML Schema and WSDL. So if I want to build an
asynchronous system why don't I directly use WSDL-described-XML-on-SMTP
or something like that? You're the best person on the list to tell me
what value I get out of SOAP.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1291
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-20 02:51:45
Subject:Re: [rest-discuss] REST Tutorial
Message:

Paul Prescod wrote:
>
>> Would Axis count?  When Axis is deployed as a servlet, one can map a
>> url-pattern to the AxisServlet.  One can then deploy a transport specific
>> handler which obtains the relative path and does something appropriate with
>> that information.
>
> Is this simple or rocket science? Maybe you could write a tutorial one
> day.

My current feeling is that whatever I write - even if it directly addresses
a question or concern you have expressed - you will pick it apart and call
it names, so forgive me if I continue to seek to confirm to my satisfaction
that there is the possibility of finding common ground before proceeding on
this suggestion.  Meanwhile, here are two pointers if you would like to
pursue it further.

http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/webapps/axis/WEB-INF/web.xml
http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/src/org/apache/axis/handlers/http/URLMapper.java

> "Applications communicate with the transport protocols through the use
> of 'ports' which are unique I/O identifiers used by the ransport
> protocols and hte specific instance of the application protocol."
>
> "Just as every device on an IP network has a unique IP address, every
> instance of every application protocol also has a unique port number
> that is used to identify it to the transport protocols on the local
> system."
>
> * "Internet Core Protocols"
>
> It is my belief that a protocol should have a port number if and only if
> it is an application protocol. I define application protocol as a
> protocol that has a concept of:
>
> a) addressable data objects
> b) standardized methods on those data objects
> c) standardized semantics for those methods
>
> This definition holds for FTP, HTTP, SMTP, NNTP etc. It doesn't hold for
> SOAP, DCOM, RMI, etc. Individual applications *built on top of* SOAP,
> DCOM, and RMI should have ports.

My perception is that amazon.com's shopping basket is an application built
upon HTTP.  Care to comment?

> Summary: You can build synchrony on top of asynchrony or vice versa.

I view that statement as akin to the statement that all computers are
Turing complete.  A true statement, but one that misses a number of
important subtleties.

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1292
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-20 03:26:59
Subject:Re: [rest-discuss] REST Tutorial
Message:

----- Original Message -----
From: "Sam Ruby" <rubys@...>

>
> It is a bit ironic that a set of architectural practices under the title
of
> "Representation State Transfer" defines virtually nothing about the way in
> which state is to be represented, and instead focuses on how Objects (or
> more precisely, resources) are to be accessed.
I don't think that many architectures define representations. You know -
'architecture' 'design' 'implementation' - there is a reason that there are
three different words... I don't think it is a pedantic/semantic argument
either. Other architectures ('event based integration', 'remote procedure
call') do not define the details - a particular design or implementation of
the architecture does (there are several RPC systems that have different
representations - yet they are all recognizably 'rpc').

As an implementation of a large-scale system that exhibits the
characteristics enumerated by REST - HTTP does define the way in which state
is represented by the protocol: content-type, content-length, accept, etc..
The architecture does not constrain which representations to use, only that
you must use some and be clear about what representation you are using.








-----------------------------------------------------------------------------------
Post ID:1293
Sender:"simonfell99" <sf@...>
Post Date/Time:2002-05-20 03:30:12
Subject:Re: REST Tutorial
Message:

--- In rest-discuss@y..., Matt Gushee <mgushee@h...> wrote:
> > In particular, there are quite a number of uses of
> > HTTP that are inconsistent with REST, including most CGI based
> > applications, and by implication most servlets, ASPs, ColdFusion
> > applications, PHP applications and the like.
> 
> Where do you get that idea? I don't claim to be a REST wizard, but
> I've been following this discussion for 3 months, and I haven't
> known anyone to suggest such a thing. In fact, one of the core
> principles of REST as I understand it is that the implementation 
> of a REST resource is opaque to the client, which implies that 
> it would be quite appropriate to generate a representation 
> using any of the above technologies.

ASP.NET webforms for one always use POST regardless of whether its apropriate.

Cheers
Simon







-----------------------------------------------------------------------------------
Post ID:1294
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-20 04:18:57
Subject:Re: [rest-discuss] REST Tutorial
Message:

S. Mike Dierken wrote:
>
>> It is a bit ironic that a set of architectural practices under the title of
>> "Representation State Transfer" defines virtually nothing about the way in
>> which state is to be represented, and instead focuses on how Objects (or
>> more precisely, resources) are to be accessed.
>>
> I don't think that many architectures define representations. You know -
> 'architecture' 'design' 'implementation' - there is a reason that there are
> three different words... I don't think it is a pedantic/semantic argument
> either. Other architectures ('event based integration', 'remote procedure
> call') do not define the details - a particular design or implementation of
> the architecture does (there are several RPC systems that have different
> representations - yet they are all recognizably 'rpc').

Agreed.

I am actually trying to tease out the distinction between REST and HTTP.  I
see people outraged when SOAP uses POST when it could have equally validly
used GET.  Few of these people seem outraged when GET is used in a
non-idempotent manner.  In many cases, this makes me wonder if the thing
most people find appealing is actually the concept of a URI and not of the
underlying architecture or even the validity of the usage of HTTP.

In contrast, I find the statement in the Rest Wiki
(http://conveyor.com/RESTwiki/moin.cgi/RestArchitecturalStyle) that Rest
most closely resembles tuplspaces - an architecture in which there is no
identifiable resources, and one in which all routing is based on content.
A vision which is not terribly dissimilar from the one that Adam Bosworth
exposes at
http://www.fawcette.com/xmlmag/2002_04/magazine/departments/endtag/default.asp

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1295
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-20 05:03:23
Subject:Re: [rest-discuss] REST Tutorial
Message:

----- Original Message -----
From: "Sam Ruby" <rubys@...>

>
> I am actually trying to tease out the distinction between REST and HTTP.
I would like to see these two in counterpoint also. Comparisons of other
systems to the facets of REST can help illuminate - for example a comparison
of RDBMS systems with aspects of REST and the reasons they differ. I'd also
like to see a 'how to use REST with JMS' - I belived that would foster
discussion of the architectural issues separate from HTTP.

> I see people outraged when SOAP uses POST when it could have equally
validly
> used GET.  Few of these people seem outraged when GET is used in a
> non-idempotent manner.
Probably because 99% of the time it is used correctly, and all architectural
and design discussions talk about using GET correctly - the 1% (or so) of
abusers aren't considered restless heathens mainly because people do it out
of ignorance or desparation and most understand the issues once they are
explained and fix it themselves. The protocol isn't broken, the servers
aren't broken - people are just used in a non-conformant way.

Promoting at the design, implementation and cultural level a non-conformant
use is more of a catastrophe. Kind of like if I suggested a shortened
end-tag syntax for soap to cut down on size - like </> instead of
</end-tag>. I wouldn't have to get it in the spec, I'd just check the code
into Apache code base and let people choose use it when they wanted better
performance. Nothing wrong with that is there? The programmers would like
it... faster parsing, less memory...

> In many cases, this makes me wonder if the thing
> most people find appealing is actually the concept of a URI and not of the
> underlying architecture or even the validity of the usage of HTTP.
The URI basis is probably the single greatest strength of the Web. All else
could be trimmed and there would be value there - without the other aspects
of REST it won't be as strong or as complete, but if you are constrained for
time or resources in coming up with an architecture it may be a viable
approach.
Or if you are implementing an isolated system, at least using the URI aspect
of REST (and the Web) provides a lot of value.

For example, if you use JMS to implement an event notification system you
can easily pick a JMS property for the 'resource id' that the message is
'about'. Subscriptions can match against this header and do things.
Distributed session caches can start listening and start purging their
data - a nice add-on benefit. But then you have to start saying more about
the message, like did the resource change or not. Then you get into
op-codes, and how do you tell the cache which operations imply a read vs
write vs delete from the point of view of the cache... and so on. You end up
working toward the features identified by REST - the underlying architecture
of the Web, regardless of the validity of using HTTP.









-----------------------------------------------------------------------------------
Post ID:1296
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-20 06:24:38
Subject:Re: [rest-discuss] REST Tutorial
Message:

S. Mike Dierken wrote:
>
>> I see people outraged when SOAP uses POST when it could have equally validly
>> used GET.  Few of these people seem outraged when GET is used in a
>> non-idempotent manner.
>
> Probably because 99% of the time it is used correctly, and all architectural
> and design discussions talk about using GET correctly - the 1% (or so) of
> abusers aren't considered restless heathens mainly because people do it out
> of ignorance or desparation and most understand the issues once they are
> explained and fix it themselves. The protocol isn't broken, the servers
> aren't broken - people are just used in a non-conformant way.

Care to comment on frames and cookies?

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1297
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-20 07:22:27
Subject:Re: [rest-discuss] REST Tutorial
Message:

Sam Ruby wrote:
> 
>...
> 
> My current feeling is that whatever I write - even if it directly addresses
> a question or concern you have expressed - you will pick it apart and call
> it names, so forgive me if I continue to seek to confirm to my satisfaction
> that there is the possibility of finding common ground before proceeding on
> this suggestion.  

I was only trying to get a more accurate sense of whether it was
feasible to use SOAP in a URI-sensible manner in the real world.
Everything I've heard so far says that it is quite difficult with
existing toolkits. If you want to provide a counter-example, so be it.
If not, that's fine too.

>...
> >
> > This definition holds for FTP, HTTP, SMTP, NNTP etc. It doesn't hold for
> > SOAP, DCOM, RMI, etc. Individual applications *built on top of* SOAP,
> > DCOM, and RMI should have ports.
> 
> My perception is that amazon.com's shopping basket is an application built
> upon HTTP.  Care to comment?

Amazon.com's shopping basket is a software application built on top of
the HTTP application protocol. The addressing model and methods for the
application come from the HTTP application protocol. HTTP does not
address the payload syntax but neither do (nor can!) NNTP, POP, IMAP or
the other application protocols.

> > Summary: You can build synchrony on top of asynchrony or vice versa.
> 
> I view that statement as akin to the statement that all computers are
> Turing complete.  A true statement, but one that misses a number of
> important subtleties.

Which subtleties in particular do you feel are relevant?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1298
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-20 16:53:06
Subject:Re: [rest-discuss] REST Tutorial
Message:

----- Original Message -----
From: "Sam Ruby" <rubys@...>
>
> Care to comment on frames and cookies?
Frames are an issue with a particular representation language (html) and the
client(s) built to handle it. I don't know of any aspect of the protocol
that explicitly deals with frames.

Frames are a way to deal with the gap between the idealized 'resource model'
approach supportable by HTTP and the 'user-interaction model' approach
supported by browser client apps and familiar with many developers - coupled
with server-side technology that didn't always support dynamically creating
representations easily. A server-side-include/template mechanism pretty much
removes the need for client-side frames. Frames as 'client-side-includes'
(paul - correct me on the terminology) were used when you didn't have
server-side-includes.

Other representation languages and clients do not need to follow the
html/frameset approach.

Cookies - in my opinion - are a valid approach to provide stateful
applications without making the protocol stateful (which would be a Bad
Thing). Their use grew outside this problem space and started to take on
things better provided by the protocol - like user identification (cookies
with sessionId) and resource identification (I've seen redirect locations,
'next page', etc in cookies).

I think a lot of stuff has built up to support browser-client access for the
'visual web' application. I believe there is a need to step back and take a
look at the HTTP with an eye toward machine-to-machine communication. We
should not just re-apply every aspect of existing HTTP tools (servers, etc)
to this new application - we should apply the protocol basics where they
fit, regardless of 'common use' by the visual web.









-----------------------------------------------------------------------------------
Post ID:1299
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-05-20 18:49:07
Subject:REST & HTTP
Message:

I took a stab at extracting REST features from HTTP a while ago, on the
RESTwiki;
 
http://conveyor.com/RESTwiki/moin.cgi/WhereRestStopsAndHttpStarts
 
MB





-----------------------------------------------------------------------------------
Post ID:1300
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-05-21 02:01:19
Subject:SOAP; where's the REST?
Message:

Sam, I've been perhaps the biggest supporter of using SOAP in a manner
consistent with REST, both inside and out of the XML Protocol WG for the
past couple of years.  But at some point, I have to ask "ok, where is
it?"  Where is the spec that I can look to, to show me and others how to
use SOAP in this way?  Are you going to write it?  If not, who will?  I
haven't heard anybody else volunteer, nor even identify the need for it.
 
Frankly, I've now given up on SOAP ever being used in this way because
it's become synonymous (in developers' minds, and in deployed code) with
non-REST style interactions.  If, at some point in the future this
changes, then I'll be very happy.  But until that point, I'm going to
use the only protocol that lets me do REST out of the box; HTTP.
 
Thanks.
 
MB
 
 = = = = 

	 The reason I joined this mailing list, and have persisted, is
that it is 
	my hope that some day a paper can be jointly authored which
shows both SOAP 
	and REST in a positive light, shows the strengths of both, and
how they can 
	be used in concert. 

	- Sam Ruby 


	------------------------ Yahoo! Groups Sponsor
---------------------~--> 
	Take the Yahoo! Groups survey for a chance to win $1,000. 
	Your opinion is very important to us! 
	http://us.click.yahoo.com/NOFBfD/uAJEAA/Ey.GAA/W6uqlB/TM 
	
---------------------------------------------------------------------~->
To unsubscribe from this group, send an email to: 
	rest-discuss-unsubscribe@yahoogroups.com 

	

	Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:1301
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-21 06:16:25
Subject:REST/SOAP ideas summary
Message:

(very rough)
	== Roots of the REST/SOAP debate ==

There is one thing we can all agree upon: the REST vs. SOAP debate is
complicated.  Debates about architecture are invariably complicated
because they inevitably revolve around abstract models as opposed
to syntactic details. In many cases different people's mental models
have developed differently through their years of experience.

This paper is intended to help readers to understand the point of
view of a REST advocate at a high level.

REST stands for REpresentational State Transfer, which is Roy
Fielding's name for the architecture of the current Web. If the Web
had had a design document in advance, it would have outlined the
principles of REST. But The Web did not have a design document and
so many people think it merely accumulated. Nevertheless, the design
of the Web can be determined by analyzing the major documents that
describe its protocols and formats: URIs (RFC XXXX), HTTP (RFC XXXX),
HTML (RFC XXXX) and XML (RFC XXXX).

The term REST has evolved (for better or worse) from what Roy
Fielding used it to mean. He was mostly focused on discussing the
virtues and vices of HTTP. What most people mean when they say that
they support REST is that they want Web services to integrate deeply
into the architecture of the Web and use Web technologies to their
fullest. REST only became a rallying cry when it became clear that
an alternative model was arising and that this alternative was in
some senses competitive with the Web.

	== In the Beginning ==


There are four main concepts that serve as the characters in this
story. You are probably familiar with them but I need very precise
definitions so bear with me.  Our protagonists are documents, data,
programs and protocols. Historically a document was a bag of bits
intended for viewing by a human being. Documents were written by
people for people.  Because people are creative, documents vary
radically in size and shape. Data is more often "collected" rather
than "created". For easy maintenance it is often collected in very
constrained ways and stored in highly organized containers: databases.
Programs are sets of instructions written in some language, usually a
programming language.  Protocols are ways for programs to communicate
with each other across computer networks.

Without programs there would be no computing so in that sense programs
are wonderful. But in another sense they are a necessary evil.
In particular, programs are extremely hard to analyze. That is why
there are so many bugs in them! Computers can do only very rough
validity checks on them.  Programs are also quite hard to use in new
contexts that they were not prepared for.  A Macintosh program cannot
(in general) run on a PC. This is because it is hard to analyze the
program and understand what parts of it depend on what quirks of
the Macintosh platform. If programmers need to write code that runs
on both Macintoshes and PCs, they tend to code in a very particular
way from the beginning (choosing their tools carefully and testing as
they go). In essence they do the required analysis a little bit at a
time as they go rather than expecting to be able to automate it later.

To put it another way: if somebody drops 100MB of data into your lap
and asks you to do something useful with it, there are a variety of
analysis tools and techniques you can use to determine its nature and
figure out how to re-use it. If they drop the same 100MB of program
code into your lap you will find that the analysis is in general much
more difficult because analyszing code is intrinsically difficult.

Around the late 1960s, some IBM researchers noticed that existing
technologies did not make a clear boundary between programs
and documents. Some forms of documents were really just simple
programs. Some were actually very complex programs! One virtue
of modern computers is that they can treat code as data and data
as code but usually it makes more sense to treat them as separate
entities. The researchers noticed that if you treat documents as data,
rather than programs, you can much more easily repurpose them for
new environments. They sought to clearly delineate the line between
document data and the code that processed it.

Let me give a concrete example. Suppose you work in a highly secure
environment.  Someone sends you a Word document and a Docbook/XML
version. Word mixes code and data. Docbook/XML does not. You load the
one up into Word and the other up into an XML editor. There is a chance
that the first one will cause Word to say something along the lines
of: "I'm sorry. There seems to be a macro in this program. Macros are
program code. Analyzing program code is extremely difficult. Therefore
I can't tell you whether this document is safe or unsafe. Open it at
your own risk." The Docbook version will never give such a warning
because Docbook separates document data from code so that there is
no need for such a security audit. Similarly, Word macros tend not
to work properly in Word-like programs that claim to work with Word
documents. Docbook documents are entirely platform independent.


	== SGML Philosophy ==


Docbook was orginally based upon SGML. SGML was the language that came
out of that research at IBM. Docbook's easy environment-independence
comes from using the two markup languages and keeping in mind the
philosophies that surround them.


People who grew up with SGML and XML came to internalize certain
philosophies. One was that separation of data and processing is
sometimes inconvenient in the short term but generally pays dividends
in the long term. Once you've separated the data from its processing
you can often find new uses for the data that you did not originally
expect. Because it is easy to analyze and reuse data, not programs,
SGML people tend to strongly prefer systems that encode as much of
the logic as possible in data rather than programs.

Average programmers, not surprisingly, feel uncomfortable with this.
If programming is what you get paid for, why would you want to
decrease the importance of programs? Moving logic from program code
to data is also a hard sell for the same reason that jogging is a
hard sell. It often (but not always) involves short-term pain for
long-term gain. Furthermore, the nature of the long-term gain is
typically unforseeable. Any well-defined, present requirement can be
coded into a program. It is the ill-defined, future requirement that
the program will probably have problems with. Because data is easier
to analyze, it is easier to repurpose it to solve new problems easier.

Most people do not understand that the Web was designed precisely
in opposition to the idea that data should be accessed through
programmatic methods rather than being treated as intrinsically 
inert.

http://www.w3.org/DesignIssues/Principles.html#PLP

The most advanced techniques for moving logic from code to data are
called "knowledge technologies." RDF is the knowledge technology from
the W3C. Topic maps are from ISO. These knowledge technologies allow
the classification of information items, the association of metadata
with the items and allow relationships betwen items to be expressed
explicitly in some cases and inferenced (inferred) in other cases.
Inferencing is a way of uniting partially understood information
sources to create new knowledge.

People vary in their level of skepticism about the applicability
of these knowledge technologies.  In my mind, that debate is
marginal. Sophisticated developers separate data from processing as
much as possible, whether or not the data conforms to some particular
standard. The knowledge technology standards are just points far
along a spectrum of declarative technologies. Every hyperlink in the
world is a declarative assertion of a relationship between two data
objects. If you understand the benefit of hyperlinks then you 
understand what declarative techniques can do for you.

	== The SGML Tribe ==

Members of the SGML tribe also came to deeply revere the related
concepts of linking and addressing. Once again, this comes back to
the idea of reusing information in ways that it was not originally
intended for. If you can get some kind of handle or reference to
an information item, you can reuse it in new forms of information
packaging. For instance, it is possible to link a range of Excel cells
into a Word document. As you change the cells in Excel, the changes
are reflected in Word. You don't have to create the original Excel
spreadsheet with some special flag that says: "I want to reuse this
information." You just tell Word (through drag and drop) that you
are interested in cells A3-D5 in "myfile.xls".


SGML people took this technique to new heights and created extremely
sophisticated systems built upon it. The most sophisticated of these
systems is the World Wide Web, built in part by people who were
part of the SGML tribe (like Dave Raggett), in part by people who
had discovered or reinvented its core ideas without joining the tribe
(like Tim Berners-Lee) and also by people who simply did not understand
it at all (like Marc Andreesen and is cronies, who I will probably
never forgive for lamentably poor extensions to HTML and the Web).


	== The Google Example ==

Let us consider a particular example. One way to do hyperlinking is
with declarative statements about what pages are linked to other
pages. Another way is to put little programs in each element that
invoke the hyperlinking behaviour.

A programmatic approach to hyperlinking would encourage you to
represent the relationships between pages as little snippets of code
that load and display the next page.  At first glance this would seem
to be a more sophisticated system because it would be possible to write
sophisticated hyperlinks that do complicated computations and then
choose the appropriate page to load based on those computations. The
code could also do interesting things with the placement and styling
of the pages.


http://www.w3.org/DesignIssues/Evolution.html#Least

Unfortunately, code is difficult to analyze. This means that once
code is deployed the user typically has only a boolean choice:
"run it" or "don't run it."

On the other hand, consider one result of our declarative approach
to hyperlinking: Google. Google is built upon the analysis of Web
hyperlinks. If hyperlinks were code rather than data, Google could
not come along ten years after the invention of the Web and figure
out a completely new way for analyzing and reusing the deata embedded
in it. Nobody foresaw Google's ranking algorithm when the Web was
invented. In fact the idea of a central search engine would probably
have seemed insane. But years later, the people at Google noticed
all of the Web data sitting around and they found a new way to make
it valuable. Yahoo has a similar story.

Another interesting thing about Google is that it works despite the
fact that it does not always know exactly what it is doing. Google
does not know when it sees a link of whether it is a link from a
child document to a parent document or vice versal.  It does not
know whether the two documents are created by the same person. Google
does not know why the documents are linked. Google sees a link and it
records it. It works from partial understanding rather than waiting
around for complete information.

If Google could only get information out of a service by understanding
every detail about the service's interface, it would not be able to work
with partial understanding and will be consequently crippled (later
on I present an analogy with the phone system that makes this clearer).

http://www.w3.org/DesignIssues/Evolution.html#PartialUnderstanding

Web-based services such as Google, Yahoo, Blogger and Meerkat add value
to existing information by making links to that information. They
show what you can do by using XML and hyperlinks to create services
that work with partial information based on analysis of data.


	== SOAP's Role ==

The programming world spent years trying to avoid using a data-centric
model for networking. They used protocols such as DCOM and CORBA which
hid the data behind programmatic interfaces (APIs) and delivered the
data across the network in unreadable binary packets. These are called
Remote Procedure Call (RPC) protocols. One camp of people thought
that there were only two things wrong with this strategy. First,
they disliked that there were BOTH DCOM and CORBA. They logically
felt that there should really be a single standard for RPC over the
Internet. Also, they thought that the binary packets were turning
off Internet programmers, who are more comfortable with text-based
formats. This group invented what we will call "SOAP-RPC", which was
an XML-based remote procedure call protocol for use over the Web.

Another camp thought that this was not enough to allow messages to flow
freely between businesses. They thought that an important requirement
was "loose coupling". In other words they wanted to make it possible
for clients and servers to evolve independently. XML allows this but
does not require it. It takes extra effort to create systems that are
loosely coupled. Over the last several years, people espousing this
view have taken over the job of directing the SOAP specification. Most
of the more clued-in architects at vendor companies agree. They see
the RPC model as backwards.

http://www.prescod.net/soap/views

Neither camp incorporated lessons from the SGML and XML tradition. In
particular they did not design SOAP such that individual data objects
would be addressable. For instance, if you were designing a banking
web service using standard SOAP tools, you would almost certainly
make the bank the only explicitly addressable object. In other words
the only URI would be for the bank. To send a message to a particular
account you would do something like this:

bank = new SOAPProxy("http://.....")  bank.addMoneyToAccount(account
23423532, 50 dollars)

To get information about a particular user, you would do something
like this:

bank = new SOAPProxy("http://.....")
bank.getUserNameFromAccount(account 23212343)

Note that the account itself is not addressable. It has no URI.  In the
Web-centric version of the service the accounts would be addressable.

Let me offer an analogy. Suppose you were living temporarily in
a hotel.  The hotel might not have direct dial connections from the
outside. In order to call a room you have to contact the operator first
(this is like contacting the "SOAP endpoint") and then ask them to
connect you to your room. Now imagine that there is an outside service
that you would like to buy. It is a onc-a-day automated wake-up call
and horoscope service. You try to sign up for the service but when
you are asked to enter the phone number to call back you realize that
there is no single number. The service must contact the operator first
and then the operator must patch them through to you.  Obviously the
computer on the other end is not going to be smart enough to know to
go through the operator and the operator will not know to patch the
call through to your room.

If everybody lived in a hotel like that, the operator service would
be practically impossible. A particular application of the phone
sysstem would simply cease to exist. Telemarketers would find their
job a little harder too but I think that they would adapt! 

Note that the problem is not obvious in the design of either system. It
is when you try to unite the two systems that you wish that the hotel
had used the international standard phone addressing "syntax" rather
than having an extra level of misdirection through the operator. SOAP
services are the operator. The objects they work with (purchase orders,
bank accounts, personelle records) are the hotel rooms. The data is at
the mercy of the soap endpoint. If the interfaces of the client and
server do not exactly align, the two cannot communicate. And yet,
participants are often happy to work with partial knowledge and
loosely coupled interfaces. For instance, the automated horoscope
system was not interested in the fact that you happened to be in a
hotel room. Similarly, a system for tabulating monthly pay checks would
not care what precise human resources management system the enterprise
was using. As long as the employee records are available in EmployeeML,
it doesn't matter what workflow was used to get them there.

Bear in mind that SOAP's weakness around addressing does not stem
merely from ignoring the lessons of XML and SGML. In fact, older
standards like CORBA and DCOM did much better in this area. Every
object had an address and although the address syntaxes were not
URIs, they were at least standardized within the domain of each RPC
protocol. SOAP lacks any equivalent addressing model.  Although it
is the new, new thing, it is actually less sophisticated in this way
than its predecessors.

	== SOAP and the Web ==

There is a reason for SOAP's weakness around addressing. If SOAP
unambiguously stated that the addressing syntax for SOAP is URIs then
that would be equivalent to saying that SOAP is designed for use on
the Web and only on the Web. But SOAP advocates are quite clear about
the fact that Web protocols and Web addressing models serve only as
"transports" for SOAP. That is like saying that the Web is a taxi
driver and its only job is to get SOAP from place to place. The SOAP
message can get out of the taxi and into another vehicle for the next
leg of its trip. In technical terms, SOAP "tunnels" through the Web.

This is a core area of digression between the REST viewpoint and
that of the SOAP specificatoin. The REST viewpoint is that the 
Web architecture is incredibly scalable and well-designed. The Web 
was explicitly designed
to integrate disparate information systems. But the Web did it on its
terms, by binding them all into a single namespace and encouraging them
to use a single protocol. The central virtue of the Web is that you
don't glue system X and system Y together using the Web as transport
middleware. Rather you make a web interface to system X and a web
interface to system Y and the two systems can link to each other and
exchange information with each other just by virtue of the fact that
they are using the same namespaces, protocols and formats.

Yes, the Web is middleware. But like any middleware you would buy from
a high priced vendor, the middleware encourages you to map your data
into a common model. This model is REST, the Web Architecture. Any
middleware vendor will tell you that you want to do this kind
of mapping rather than create N*M connections between individual
services. Even so, some people really want to take the short-cut of
tunnelling through the Web. In some cases that might be useful but it
is highly debatable whether it is the W3C's job to make that easier
rather than concentrating on improving the Web so that tunnelling
is not necessary. I, for one, am in favour of treating the Web as a
translator rather than a taxi driver.


	== Interoperability is Key ==

Many of the usage scenarios for SOAP seem to be inddirect
point-to-point integrations of system X and system Y, using the
Web as transport middleware. Considering how many systems there are
out there, this model cannot scale. It quickly becomes obvious that
there will need to be standardized interfaces with many interoperable
implementations, just as there are many interoperable implementations
of HTTP and SMTP. SOAP itself does not guarantee interoperability. It
is protocols built on top of SOAP (probably specified in WSDL) that
will guarantee interoperability.

These standardized interfaces will be the basis of the Web Services
revolution. Some vendors promote SOAP as a way that any half-decent
programmer can generate a new protocol by running a tool over their
Java or C# program. Even the vendors are coming to agree that this
is a naive point of view. First, it is naive because the services so
generated are extremely poor from a distributed computing point of
view. They are as brittle as communion wafers. They are as tightly
coupled as salsa dancers. Try adding an extra parameter on the
Google service!

Second, it is naive because a blossoming of thousands of protocols
does not get us any closer to interoperability. What we need for
interoperability are a few well-engineered, well-designed, scalable,
secure protocols. The success of the existing web and of email shows
that a few protocols can get a ton of work done. When you book a
plane trip through an online travel agent, that agent isn't using the
"Travel Agent Protocol." It uses the generic HTTP protocol.


HTTP is a special protocol in that it explicitly embodies the Web's
principles. In particular HTTP revolves around URIs and uses very
self-describing messages. A radical viewpoint is that HTTP is the
only web services protocol we will need!

Whether or not this is true, there is a sense that the whole SOAP
exercise has been a distraction from the main event. The main event
is determining the data models and data flows necessary to allow
ebusiness to begin to flow.  ebXML (whether it turns out to be a
success or failure) is nevertheless attempting to solve the right
problems. The SOAP prject is not.

But SOAP is not just a distraction. It actually works against the
process of getting ebusiness correct by training application developers
to avoid using one of their most powerful tools, the hyperlink. This
is analogous to teaching database designers not to use foreign keys,
C programmers not to use pointers or Java programmers not to use
references.

	== Separation of Processing from Data ==

Remember that one of the lessons from the SGML days was that it is
good to separate data and program code? The HTTP protocol is brilliant
at ensuring that data is not dependent on code. For instance imagine
that the department of motor vehicles had a web service that could
deliver information on who owns a particular license plate. I could
integrate the information into an XML document using one line of code:

<xi:include href="http://..../license_handler?V6A4G5">

This will execute an HTTP GET. The important thing is that HTTP defines
a protocol for turning URIs into bit streams that can be incorporated
into other documents.


The web infrastructure guarantees that a client may execute this as
often as they like with no repurcsions because GET operations are
guaranteed to be safe.

On the other hand, SOAP would require me to somehow embed a method
call in my XML document. There is no syntax for doing this and there
cannot be one. One of the Web's principle axioms is that users are not
responsible for any damage that is done by following a hyperlink. SOAP
methods have no way to communicate whether the method does or does
not do anything that could be considered damaging. This shifts the
responsibility to the client software in a manner that is not scalable.


	== REST From a Protocols Point of View ==

There is another way to come to the REST position without any interest
in Web architecture. One can look at SOAP purely as a protocol without
even considering the problems it is supposed to solve. It bends or
breaks all of the rules common among Internet protocols. For instance,
if one reads a book on the roles of networking protocols, it is clear
that SOAP is a layer 6 (presentation layer) protocol but SOAP actually
runs on top of HTTP and SMTP, which are both layer 7 protocols. That
makes SOAP a layer 8 protocol. Unfortunately the standard network stack
diagrams max out at 7! By definition the 7th layer, the application
layer, is the top layer. SOAP treats layer 7 protocols as "transport"
protocols. It pretends that they are layer 4 protocols. This causes
various sorts of discomfort for system administrators, security
analysts and protocol purists.

There is a sense that there will be one or two widely publicized SOAP
security breaches and firewall administrators will shut SOAP traffic
down. Although any protocol can be used as the basis for a security
hole, SOAP arguably encourages security holes by encouraging every
business analyst to become a protocol designer.  Also, the industry
has not been clear from a marketing perspective that SOAP is just a
basis for application protocols, not a top-level protocol itself. That
means that SOAP could get tarred with the security flaws that appear
in protocols based upon it.

But REST's biggest hole when it comes to protocols is the issue
I discussed of many protocols versus a few. No "many protocols"
framework has ever taken hold on the Internet. Security concerns
are one reason. It is easier to analyze and understand the security
implications of a few standarized protocols rather than hundreds of
unstandardized ones. Another reason is administration.	Administrating
a firewall that supports many protocols is harder than maintaining
few. Finally there is the big one, interoperability. Getting all of
these independently created protocols to talk to each other will be
a nightmare.


	== HTTP Does More than you Think ==

HTTP is wonderful in that it natively separates data from
processing. But it is also more general than just a document
fetching protocol. Most people do not know that HTTP is 100%
CRUD-compliant. That means that it has methods that map to "create",
"retrieve", "update", "delete" and "replace", just as SQL does. The
power of URIs and of the HTTP methods combine to make HTTP an extremely
general protocol for manipulating information sources.	The SQL
analogy should be suggestive of the sort of flexibility available!


	== Limits of The Web-As-We-Know-It ==

HTTP is not perfect. The Web is not perfect. We are not at the end
of history. We need new and better stuff. The REST argument is that
we need to understand what we have and make certain we do not lose
features we have today. SOAP makes it extremely difficult to use
hyperlinks because SOAP is fundamentally a technology for tunnelling
through the Web.






-----------------------------------------------------------------------------------
Post ID:1302
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-21 08:44:17
Subject:Re: [rest-discuss] SOAP; where's the REST?
Message:

Mark Baker wrote:
>
> Sam, I've been perhaps the biggest supporter of using SOAP in a manner
> consistent with REST, both inside and out of the XML Protocol WG for the
> past couple of years.  But at some point, I have to ask "ok, where is
> it?"  Where is the spec that I can look to, to show me and others how to
> use SOAP in this way?  Are you going to write it?  If not, who will?  I
> haven't heard anybody else volunteer, nor even identify the need for it.
>
> Frankly, I've now given up on SOAP ever being used in this way because
> it's become synonymous (in developers' minds, and in deployed code) with
> non-REST style interactions.  If, at some point in the future this
> changes, then I'll be very happy.  But until that point, I'm going to
> use the only protocol that lets me do REST out of the box; HTTP.

Probably the best way to describe where my head is at is that I feel that
there ultimately will be a unification of the various approaches, and I do
plan on playing an active role in documenting that unification.  The
unification, IMHO, will not be precisely REST as documented and practiced
today, but will share a number of important characteristics with that
architectural aproach.  It most definately will NOT be RPC as practiced
today.

A fairly approachable overview of where I think things are headed can be
found at:

   http://radio.weblogs.com/0101679/stories/2002/04/05/neurotransmitters.html

Feedback welcome.

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1303
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-05-21 08:48:23
Subject:Re: [rest-discuss] REST/SOAP ideas summary
Message:

Excellent.

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:1304
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-05-21 12:28:48
Subject:RE: [rest-discuss] SOAP; where's the REST?
Message:

Nice piece.  I liked the RPC/virus analogy. 8-)
 
I suppose that we'll just have to agree to disagree on the value of XML
over existing, working protocols.  That doesn't mean I don't think that
new work is required or useful (like ALIN, as  a refinement of one part
of REST; focusing on decoupling request from response and providing a
more rigorous intermediary model), just that a new syntax isn't going to
buy much.
 
As I see it, there are two ways in which SOAP can leverage REST.  One is
to bind to HTTP (or other REST-based protocols, as they arrive), and
reuse the application semantics of those protocols.  The other is to
build REST semantics on top.  IMO, if SOAP is to be successful in the
short/medium term, it will be because of the former use.  And if that
works, then we can progress to the latter use.  But I can't see going
straight to the latter use because without the former, SOAP will already
have fallen out of favour with developers and the press.
 
So IMHO, if you want to do something to help SOAP developers (and
therefore SOAP), show them how to use HTTP.
 
MB





-----------------------------------------------------------------------------------
Post ID:1305
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-05-22 10:00:41
Subject:API for the REST service yellowbrix?
Message:

Hi Folks,

Someone was telling me that yellowbrix[1] has a REST-ful web service,
similar to Meerkat.  I have been unsuccessful at finding its API.  Does
anyone have its API?  /Roger


[1] http://www.yellowbrix.com/pages/www/index.nsp







-----------------------------------------------------------------------------------
Post ID:1306
Sender:"hilbert_casey" <casey_richardson@...>
Post Date/Time:2002-05-22 17:36:40
Subject:File extensions in URI
Message:

Hi-
Excuse me if this is a simple question, but I'm trying to fully 
understand how to best use URIs.  If I have a URI that is labeling a 
resource to which I can POST data to be processed, it is not good 
practice to include a file extension in that URI, correct?  In other 
words, if I implement that resource using  ASP, JSP, ASP.NET, ..., I 
wouldn't want to betray that implementation detail, right?  It seems 
that

http://www.mycompany.com/purchaseOrders

would be better in than

http://www.mycompany.com/purchaseOrders.aspx

How would this translate to all file extensions?  Its seems to me 
there is an awful lot of .html, .asp, etc. labeling all sorts of web 
resources, and yet this seems to go against "Cool URIs do not 
change," etc.  To me this seems like a basic principle that is 
violated everywhere.

Thanks,
Casey

 







-----------------------------------------------------------------------------------
Post ID:1307
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-22 18:07:11
Subject:Re: [rest-discuss] File extensions in URI
Message:

hilbert_casey wrote:
> 
> Hi-
> Excuse me if this is a simple question, but I'm trying to fully
> understand how to best use URIs.  If I have a URI that is labeling a
> resource to which I can POST data to be processed, it is not good
> practice to include a file extension in that URI, correct?  In other
> words, if I implement that resource using  ASP, JSP, ASP.NET, ..., I
> wouldn't want to betray that implementation detail, right?  

As a matter of style, I agree. But the effort to hide it often outweighs
the stylistic concern. The root of the problem is that the Windows and
Unix file systems determine file type by extension. So it takes extra
effort to keep both the operating system and the web happy.

I say it is "only" a matter of style because if push came to shove you
could swap your .aspx for a .jsp and with the right configuration
everything should still work okay. You might have to do some web server
tweaking, but your "cool URI" would "not change". The thing that is
uncool about it is that you betrayed your implementation technology in
your URI, which is a little bit like leaving wires hanging out of a
computer case. Also, it could be a hint to hackers who want to exploit
known security holes in your implementation technology. Finally, I
wouldn't be surprised if IE uses file extension as one of its hints
about file type even when the server has labelled the content-type.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1308
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-22 18:51:31
Subject:REST on WikiWiki
Message:

REST argument page on WikiWikiWeb:
http://c2.com/cgi/wiki?RestArchitecturalStyle 

In the middle, someone writes plaintively "We need Mark Baker."







-----------------------------------------------------------------------------------
Post ID:1309
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-22 21:46:02
Subject:Re: [rest-discuss] File extensions in URI
Message:


> In other
> words, if I implement that resource using  ASP, JSP, ASP.NET, ..., I
> wouldn't want to betray that implementation detail, right?
For security and resume reasons, sure.

> It seems that
>
> http://www.mycompany.com/purchaseOrders
>
> would be better in than
>
> http://www.mycompany.com/purchaseOrders.aspx
>

> How would this translate to all file extensions?  Its seems to me
> there is an awful lot of .html, .asp, etc. labeling all sorts of web
> resources, and yet this seems to go against "Cool URIs do not
> change," etc.
The 'do not change' depends on how widespread the value of that URI is goes.
If that URI is retrieved quite often and never cached, then it doesn't
matter as much. If it is cached (in Google, on drives, in code, etc.) then
being generic is better.

> To me this seems like a basic principle that is violated everywhere.
Yep.








-----------------------------------------------------------------------------------
Post ID:1310
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-05-22 22:57:04
Subject:RE: [rest-discuss] SOAP; where's the REST?
Message:

Mark Baker wrote:

>I suppose that we'll just have to agree to disagree on the value of XML 
>over existing, working protocols.

Would you care to elaborate on what existing protocols you are referring to?


One issue I see with REST and why SOAP is attractive to many developers is that of the comfort zone - the vast majority of developers are far more comfortable with program logic in code than in data. After all, it is what we've been doing for years, there is a huge body of information out there on ways and means of  doing it effectively and as several people have highlighted recently, REST is more about resource (information/knowledge) modelling which by comparison is less widely known and less 'supported' in the how-to sense - it is out of most developers' comfort zones.
The issue of getting a handle on resource modelling, designing effective representations for REST-ified systems to deal in, is one with which I am currently struggling. A good starting point may be adding appropriate links to the resources page on the REST wiki. I'm happy to do the maintenance if people would care to contribute appropriate links (either directly to me or to this list).

Robert







-----------------------------------------------------------------------------------
Post ID:1311
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-05-22 23:24:42
Subject:REST Questions
Message:

Hi Folks,

I have 2 questions:

1. Doing an HTTP POST the REST way

From comments on my REST tutorial I have realized that to successfully
argue the case for REST I need to include an example of doing an HTTP
POST.  To my embarrassment, I am not sure that I understand the REST
position on HTTP POST...  

In my REST tutorial I have an example of a fictitious company, Parts
Depot, Inc.  The company wishes to make available on the Web the
following services:

(a) A service to enable a client to get a list of parts.
(b) A service to enable a client to get detailed information about a
particular part.
(c) A service to enable a client to submit a Purchase Order (PO). 

Clearly, an HTTP GET is the way to implement services (a) and (b).  For
service (c) a client will want to do an HTTP POST.  (Correct?)  I would
like to consider further how service (c) would be implemented in a
REST-ful manner.

My understanding is that an XML Schema (or DTD) would be created by
Parts Depot, Inc which defines the format that the PO must take.  A
client then will create a PO instance document which conforms to the XML
Schema, and submit that XML document as the payload of an HTTP POST. 
Correct?  With a SOAP implementation of this service the only difference
would be that the XML document would be wrapped within a SOAP envelope
(and there may be a SOAP header).  Is this a correct assessment of the
differences between REST and SOAP for this service?  Is the ability to
add headers in SOAP going to be an advantage over REST in this
scenario?  
2. Distinguishing characteristics of REST?

I am not clear on what characterizes a REST architecture.  For example,
consider this HTTP GET for getting information about the part whose id
is 00345:

   http://www.parts-depot.com?part=00345

It is my understanding that this is not REST-ful.  The REST approach
would be to use this URL:

   http://www.parts-depot.com/part/00345

Why is the later REST-ful but the former is not?  May I conclude that in
a REST-ful system you would not use URLs with query strings?  

Can someone enumerate the distinguishing characteristics of a REST
system?  In other words, how will I recognize a REST service when I see
one?

Thanks!  /Roger







-----------------------------------------------------------------------------------
Post ID:1312
Sender:"xemplify" <xemplify@...>
Post Date/Time:2002-05-23 01:00:33
Subject:Re: REST Questions
Message:

--- In rest-discuss@y..., "Roger L. Costello" <costello@m...> wrote:

> (c) A service to enable a client to submit a Purchase Order (PO). 

> I would like to consider further how service (c) would be 
> implemented in a REST-ful manner.

Yes I am interested in how this could be done too.

> My understanding is that an XML Schema (or DTD) would be created by
> Parts Depot, Inc which defines the format that the PO must take.  A
> client then will create a PO instance document which conforms to
> the XML Schema, and submit that XML document as the payload of an
> HTTP POST. 
> Correct?

Walter Perry, leader of the NY XML SIG, has a different view when it 
comes to interacting with processes. I will do my best try to express 
my understanding of his views. In Walter's eyes the most important 
thing for a user to determine is what is a process's output. If the 
output is not of use, then the process is not of use. Walter is a 
little bit vaguer about how to identify a processes input format, he 
always says something like 'the best way to determine a process's 
input is to look at its output' (paraphrased).

Perhaps in this example of a PO, a more interesting approach is for 
the user to do a GET on a blank PO URI. This could return a PO XML 
instance with the parts and amounts left blank, but the whole XML 
structure present. Then the user could fill in the amounts and parts 
required and do a POST to the orders URI. This way if the service 
provider needs to change the PO format in a minor way, the chance of 
affecting the users is less because for each transaction the user 
begins by doing a GET on the blank PO URI. And if the user is clever 
they will add their details to the blank order in a way that won't be 
affected by such minor changes (for example if an extra element is 
added). (This is my personal interpretation of Walter's 
mysterious "start with the output").

What does everyone think?

As for validation, Walter says it is up for the process to 
instantiate an instance of the data from the input it is given. And 
the user can determine if their input to the process was adequate if 
they get meaningful output. So schemata and DTDs are not required.

Regards,
Robert McKinnon








-----------------------------------------------------------------------------------
Post ID:1313
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-05-23 01:15:07
Subject:REST Questions
Message:

Roger L. Costello wrote:

>. Doing an HTTP POST the REST way....
>My understanding is that an XML Schema (or DTD) would be created by
>Parts Depot, Inc which defines the format that the PO must take.  A
>client then will create a PO instance document which conforms to the XML
>Schema, and submit that XML document as the payload of an HTTP POST. 
>Correct?  With a SOAP implementation of this service the only difference
>would be that the XML document would be wrapped within a SOAP envelope
>(and there may be a SOAP header).  Is this a correct assessment of the
>differences between REST and SOAP for this service?  

My (newly acquired) understanding agrees with this assessment :-/

>Is the ability to
>add headers in SOAP going to be an advantage over REST in this
>scenario?

There has been some discussion on this topic on the list with the consensus being that Http headers are the equivalent.

>Distinguishing characteristics of REST?...
>May I conclude that in
>a REST-ful system you would not use URLs with query strings? 

It is my understanding that a query string is valid if used as an optimization to a query-less URI mechanism, i.e. if in your scenario http://www.parts-depot.com/part/00345 is traversable/find-able via http://www.parts-depot.com/part/ which returns an XML list of all the available parts that includes links to the individual parts as in your tutorial (incidentally I think http://www.parts-depot.com/parts/00345 and http://www.parts-depot.com/parts/ are regarded as a slightly better naming approach because the name more closely matches the resource). 

>Can someone enumerate the distinguishing characteristics of a REST
>system?

You might take a look at Extreme Web Services at http://groups.yahoo.com/group/rest-discuss/message/1204

Robert







-----------------------------------------------------------------------------------
Post ID:1314
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-23 02:28:07
Subject:Re: [rest-discuss] REST Questions
Message:

"Roger L. Costello" wrote:
> 
>...
> 
> My understanding is that an XML Schema (or DTD) would be created by
> Parts Depot, Inc which defines the format that the PO must take.  A
> client then will create a PO instance document which conforms to the XML
> Schema, and submit that XML document as the payload of an HTTP POST.
> Correct?  With a SOAP implementation of this service the only difference
> would be that the XML document would be wrapped within a SOAP envelope
> (and there may be a SOAP header).  Is this a correct assessment of the
> differences between REST and SOAP for this service?  

Well, don't forget that the REST version returns you a URI that can be
used to address that purchase order for ever after. The SOAP version
would typically not.

Also, Mark Baker would probably use RDF instead of generic XML. (I would
not...but I may change my mind as I learn more about RDF).

An important subtlety: *if* the SOAP version accepts an arbitrary
"purchase order vocabulary" document, *then* the SOAP version probably
does not use the SOAP encoding, which negates many of the "ease of use"
advantages of SOAP. We are in a confusing time right now where half of
the world thinks SOAP is much easier to use than "regular" XML because
they don't have to parse it or map it and the other half says that the
right thing to do is parse it or map it. That means that SOAP advocates
can say that SOAP is really easy (no parsing required!) and really
extensible (pure XML!). But the truth is that you can't have them both
at the same time.

> ... Is the ability to
> add headers in SOAP going to be an advantage over REST in this
> scenario?

Doubtful but possible. You can add headers in HTTP also. You can also
add arbitrary XML to the body message if the schema is well designed.
Maybe in some circumstances you want the information to be logically a
header AND you need the header to have deep structure (i.e. XML). That's
why I've said that one of the few things I would like to steal from SOAP
is headers:

http://www.prescod.net/xml/envelopes/

> 2. Distinguishing characteristics of REST?
> 
> I am not clear on what characterizes a REST architecture.  For example,
> consider this HTTP GET for getting information about the part whose id
> is 00345:
> 
>    http://www.parts-depot.com?part=00345
> 
> It is my understanding that this is not REST-ful.  The REST approach
> would be to use this URL:
> 
>    http://www.parts-depot.com/part/00345
> 
> Why is the later REST-ful but the former is not?  May I conclude that in
> a REST-ful system you would not use URLs with query strings?

I wouldn't go that far. 

First, they are both better than the traditional web services way
because they are addressable. 
Second, the actual syntax of your URIs is a server-side issue and really
the details of the syntax are not the client's business. (i.e. you could
use indecipherable UUID strings and still be RESTful, if not stylistic
ideal, just as you could use meaningless method names in a Java program
but still be "OO").

That said, it is my opinion that the primary mode of navigation through
a service should not be a query. Hyperlinks are more discoverable and
require less client/server pre-negotiation. Queries are good as an
option. But that doesn't really answer the question because you could
have hyperlinks to either one.

So a minor advantage of the latter is that it is more like a canonical
URI for a thing whereas queries can have multiple parameters and
sometimes parameters are optional so it is hard for a caching system or
indexing engine to figure out whether they are canonical. Also some
indexing engines may be leery of following question mark links for
various historical reasons. 

Also, the latter helps you to organize your system into more of a
hierarchy which makes the meaning of POST more predictable to clients.
i.e. given the bottom URI I would expect that a POST to "part" (actually
I would call it "parts") would add a part. But given the former URI I
wouldn't be sure exactly where to POST. Just like on a web site I can
guess that if I see /a/b, I might be able to take off the /b and get
something useful at /a.

Also, there is some debate whether this:

 * http://www.parts-depot.com?part=00345

is actually identifying a resource or sending a query to a resource or
both. The latter is 100% clearly identifying a resource.

That said, all of these are pretty abstract concerns.

> Can someone enumerate the distinguishing characteristics of a REST
> system?  In other words, how will I recognize a REST service when I see
> one?

IMO, the bad news is that it would be a book, just like the
distinguishing characteristics of an OO system. Maybe there will never
be 100% agreement, just as there isn't 100% agreement about the right
way to be OO. Nobody is ready to write the book (whether canonical or
controversial) yet. But here are some ideas:

 * Use URIs and hyperlinks...

 * obey web architecture:
	* http://www.w3.org/DesignIssues/
	* anything else written by Tim B-L

 * understand the design of REST itself (versus REST services)
	*
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

 * as we will typically use HTTP and always use URIs, we need to
understand them:
	* http://www.ietf.org/rfc/rfc2616.txt
	* http://www.ietf.org/rfc/rfc2396.txt

 * nobody has yet argued with these rules (nor hardly commented on them)
	* http://groups.yahoo.com/group/rest-discuss/message/1204

 * RDF technologies are probably going to be important tools for the
REST programmer to understand in the future but I'm not convinced they
are fully baked enough (or at least palatable enough) to recommend
everyone learn them.

Let's be honest. There is too much for your average programmer to learn
here without a good book. Heck, there is too much for me to feel like
I've internalized it all. But that is as true of the standard web
services stack. Show me someone who understands SOAP, WSDL, UDDI, SAML,
GSXA, WS-Routing, WS-Referral, DIME, WS-Security, XLang ...

It is a fulltime job just keeping up with the acronyms, much less
evaluating each proposal. The industry is moving way too fast for people
to understand what we are actually doing. ;) :( 

On the one hand REST people should probably resist the urge to rush
because IMO the standard stack's mistakes arise from their rush and
their closed development model (what standards body worked on SOAP for
the first two or three years of its development?). Following them into
mistakes could be a bad mistake. On the other hand, it is not a good
situation if customers have to choose REST with one checklist of
features versus the standard stack with a different checklist. "They
have transactions. You don't. You have addressing. They don't. How do I
pick?"

Bosworth says he wants to move from within-company services to B2B by
the end of the year! Obviously he means point-to-point B2B rather than
standards-based because we are nowhere near standards-based. But still.

Too much coffee. End of rant.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1315
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-23 07:01:59
Subject:Re: [rest-discuss] REST Questions
Message:

----- Original Message -----
From: "Roger L. Costello" <costello@...>

>
> (a) A service to enable a client to get a list of parts.
> (b) A service to enable a client to get detailed information about a
> particular part.
> (c) A service to enable a client to submit a Purchase Order (PO).
>
> Clearly, an HTTP GET is the way to implement services (a) and (b).  For
> service (c) a client will want to do an HTTP POST.  (Correct?)  I would
> like to consider further how service (c) would be implemented in a
> REST-ful manner.
Just make sure that you don't merge REST and HTTP.
REST is just a summary of the key aspects of the Web that helped it succeed
and keep it strong.
HTTP is one of the Web protocols - which exhibits the most of these aspects.

>
> My understanding is that an XML Schema (or DTD) would be created by
> Parts Depot, Inc which defines the format that the PO must take.  A
> client then will create a PO instance document which conforms to the XML
> Schema, and submit that XML document as the payload of an HTTP POST.
> Correct?
Yes. The POST identifies the format being sent via the Content-Type header.
The receiver can do any mappings it chooses - if sensible.

> With a SOAP implementation of this service the only difference
> would be that the XML document would be wrapped within a SOAP envelope
> (and there may be a SOAP header).  Is this a correct assessment of the
> differences between REST and SOAP for this service?
The HTTP approach would have an HTTP header with "Content-Type:
application/purchase-order", so HTTP aware firewalls, gateways, etc. can do
useful things.
The SOAP approach would require cracking both HTTP (and ignoring the http
headers) and XML to do the same thing.

> Is the ability to
> add headers in SOAP going to be an advantage over REST in this
> scenario?
REST doesn't talk too much about headers - only to the extent that they
shouldn't be used for resource or method identification. You can qualify
operations via headers, like in HTTP you can "GET if-none-match" and stuff.
HTTP does talk about though, and SOAP might have a more rigorous model for
headers. Or it might not.


> 2. Distinguishing characteristics of REST?
>    http://www.parts-depot.com?part=00345
>    http://www.parts-depot.com/part/00345
> Why is the later REST-ful but the former is not?  May I conclude that in
> a REST-ful system you would not use URLs with query strings?
Both are equivalent to REST and to HTTP (even though 'normalizing' query
strings is difficult).
An HTTP based URI has path segments and query strings. The combination of
these is the full resource identifier.
URI also have parameters like http://host/path/path;param/path;param?query -
but these are rarely used and not all libraries/clients/servers parse them
properly.
Both query strings and segment parameters are a convenience for the resource
model implementation on the server. They generally should not be constructed
by the client - they should be provided as opaque blobs via some response
body (likely in XML, but not necessarily).

>
> Can someone enumerate the distinguishing characteristics of a REST
> system?  In other words, how will I recognize a REST service when I see
> one?
 - addressable resources
 - uniform interfaces that apply to all resources
 - stateless messages
 - 'representations' - multiple content types accepted or sent

If you implement a networked system that supported these concepts you'll
have a decent foundation - regardless of the protocol oor technology used.








-----------------------------------------------------------------------------------
Post ID:1316
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-23 07:07:43
Subject:Re: [rest-discuss] Re: REST Questions
Message:

----- Original Message -----
From: "xemplify" <xemplify@...>

>
> Perhaps in this example of a PO, a more interesting approach is for
> the user to do a GET on a blank PO URI. This could return a PO XML
> instance with the parts and amounts left blank, but the whole XML
> structure present. Then the user could fill in the amounts and parts
> required and do a POST to the orders URI. This way if the service
> provider needs to change the PO format in a minor way, the chance of
> affecting the users is less because for each transaction the user
> begins by doing a GET on the blank PO URI. And if the user is clever
> they will add their details to the blank order in a way that won't be
> affected by such minor changes (for example if an extra element is
> added). (This is my personal interpretation of Walter's
> mysterious "start with the output").
>
> What does everyone think?
>
I'd like to hear what Walter said - but a 'template' approach might be
interesting.
Let's say we did that - how would the (automated) client know what parts of
the template to modify?
If we had XML, we could use XPath or something. Then the XML could change as
long as the XPath used didn't need to change.
Then the client and server would be coordinating based on the list of XPath
statements.
So the client would know about the data to write via a set of hardcoded
text - which you could just send to the server directly as name-value pairs.

I'd like to hear more of how this would work... I'm somewhat tangled up in
the world of PO/PO-ACK/etc. right now, so this is interesting to me.








-----------------------------------------------------------------------------------
Post ID:1317
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-23 07:15:03
Subject:Re: [rest-discuss] REST Questions
Message:

----- Original Message -----
From: "Robert Leftwich" <robert@...>

>
> It is my understanding that a query string is valid if used as an
optimization to a query-less
> URI mechanism, i.e. if in your scenario
http://www.parts-depot.com/part/00345 is
> traversable/find-able via http://www.parts-depot.com/part/ which returns
an XML
> list of all the available parts that includes links to the individual
parts as in your tutorial
> (incidentally I think http://www.parts-depot.com/parts/00345 and
http://www.parts-depot.com/parts/
> are regarded as a slightly better naming approach because the name more
closely matches the resource).
The path-based uri looks nicer and I personally favor it, but it is only
important to the server implementation.
The client sees them conceptually as uri1 and uri2 - no paths, no queries,
just blobs. Designing code with this viewpoint results in needing to do
certain things - like returning the URI of the new PO in the response
message rather than assuming the client will know where it is - but that
effort results in a more flexible and interoperable system. It'll work fine
without it, but you are just limiting the scope of your system (which might
be acceptable for the problem you are trying to solve).








-----------------------------------------------------------------------------------
Post ID:1318
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-23 12:35:11
Subject:State Machine As Hypertext
Message:

Yesterday I started a new page in the Rest Wiki, which spun off from 
a discussion in Wiki Wiki:
http://internet.conveyor.com/RESTwiki/moin.cgi/StateMachineAsHypertext

We've had several discussions about related topics on rest-discuss, 
but they have always dead-ended without convergence or resolution.

Some of the related topics include:
* Sessions
* Business protocols like Offer-Acceptance for Purchase Orders and 
extended ones like Order-Delivery-Payment or Order-Payment-Delivery.

Several people from this list have been interested, including Paul 
Prescod, Mike Dierken and me.

Quote from Paul:
"Have you ever booked a ticket on Expedia? It has a very complicated 
state machine expressed through hypertext. The hypertext expression 
has a variety of advantages like for instance (if it is well 
implemented) I can send some body a URL from the middle of the state 
machine and they can continue with the computation without worrying 
about which state it was in. By examining the referenced document 
they can determine the state. This is preferable to having separate 
state machines on the client and the server and requiring them to 
stay in sync. I think it is better to let the server own the state 
machine totally and tell the client where it is in the process. I 
wonder if this wouldn't be easier to discuss on a mailing list like 
rest-discuss? -- PaulPrescod"

I'm hoping that a Wiki page will lead to more convergence than rest-
discuss, and result in a coherent document or set of same.  If nobody 
participates, I'll understand that it was a bad idea and do something 
appropriate with the Wiki page.

-Bob Haugen










-----------------------------------------------------------------------------------
Post ID:1319
Sender:edge@...
Post Date/Time:2002-05-23 12:54:22
Subject:Re: REST Questions
Message:

On Thu, 23 May 2002, xemplify wrote:

> --- In rest-discuss@y..., "Roger L. Costello" <costello@m...> wrote:

> > (c) A service to enable a client to submit a Purchase Order (PO). 

> > I would like to consider further how service (c) would be 
> > implemented in a REST-ful manner.

> Yes I am interested in how this could be done too.

> > My understanding is that an XML Schema (or DTD) would be created by
> > Parts Depot, Inc which defines the format that the PO must take.  A
> > client then will create a PO instance document which conforms to
> > the XML Schema, and submit that XML document as the payload of an
> > HTTP POST. 
> > Correct?

> Walter Perry, leader of the NY XML SIG, has a different view when it 
> comes to interacting with processes. I will do my best try to express 
> my understanding of his views. In Walter's eyes the most important 
> thing for a user to determine is what is a process's output. If the 
> output is not of use, then the process is not of use. Walter is a 
> little bit vaguer about how to identify a processes input format, he 
> always says something like 'the best way to determine a process's 
> input is to look at its output' (paraphrased).

> Perhaps in this example of a PO, a more interesting approach is for 
> the user to do a GET on a blank PO URI. This could return a PO XML 
> instance with the parts and amounts left blank, but the whole XML 
> structure present. Then the user could fill in the amounts and parts 
> required and do a POST to the orders URI. This way if the service 
> provider needs to change the PO format in a minor way, the chance of 
> affecting the users is less because for each transaction the user 
> begins by doing a GET on the blank PO URI. And if the user is clever 
> they will add their details to the blank order in a way that won't be 
> affected by such minor changes (for example if an extra element is 
> added). (This is my personal interpretation of Walter's 
> mysterious "start with the output").

I believe that Roger is more correct in his assessment of the
steps that need to take place. Roberts description of the process
has more of a 'screen scraping' mentality. The DTD/Schema defines
the information required/allowed by the PO, period. Future changes
to the internal representation of that document remain transparent
to the user. Unless Parts Depot, Inc. provides a field in the 
DTD/Schema that allows the user to add their own details (and I'm
not really sure what you mean here) to the PO, doing so would
cause an error. 

> What does everyone think?

> As for validation, Walter says it is up for the process to 
> instantiate an instance of the data from the input it is given. And 
> the user can determine if their input to the process was adequate if 
> they get meaningful output. So schemata and DTDs are not required.

This certainly requires a lot more hand-shaking than forcing the
user to validate their input data against a DTD/Schema. If the user
inputs data that is not validated by the process then the steps
required to notify the user of where and why the errors occured
increase proportionally. If the originator of the PO (Parts Depot)
supplies knowledge of the correct input it is up to the user to
supply correct input.

edge

-- 
                                     e d g e @ e d g i n t o n . n e t
______________________________________________________________________

            "I'd love to go out with you, but I have to floss my cat."






-----------------------------------------------------------------------------------
Post ID:1320
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-23 17:18:20
Subject:Re: [PMX:#] [rest-discuss] State Machine As Hypertext
Message:

bhaugen32 wrote:
> 
>...
> 
> Some of the related topics include:
> * Sessions
> * Business protocols like Offer-Acceptance for Purchase Orders and
> extended ones like Order-Delivery-Payment or Order-Payment-Delivery.

I'm sorry that the conversations didn't end in something concrete. Could
you provide one or two or six URLs with a concrete description of the
Offer-Acceptance for Purchase Orders and similar problems? I've got
distracted by other things as you discussed them with Mike Dierken and
didn't realize that you never came up with solutions you considered
complete. If you can give me the URLs we'll all be at the same place
again (reset our state based on hypertext) and I'll add my thoughts.

One thing I remember is that some people were using "transaction" in the
sense of transactional integrity and some people were using it merely to
mean a "Communication involving two or more people that affects all
those involved; personal interaction"/"The doing or performing of any
business; management of any affair; performance."
http://www.dictionary.com/cgi-bin/dict.pl?term=transaction&r=67

We had this same terminological problem during the REST/SOAP panel.
Lucas used transaction in the latter sense and Rohit thought he meant in
the database sense.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1321
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-23 17:49:44
Subject:Re: [PMX:#] [rest-discuss] State Machine As Hypertext
Message:

Paul Prescod 
> I'm sorry that the conversations didn't end in something concrete. 

Don't be sorry, you stimulated and contributed outstandingly to the 
conversation.

> Could
> you provide one or two or six URLs with a concrete description of 
the
> Offer-Acceptance for Purchase Orders and similar problems?

Got any problems if I provide them on the Rest Wiki page?
The first thing I plan to do (later today) is collect fragments of 
the conversation from rest-discuss and related lists.

> I've got
> distracted by other things as you discussed them with Mike Dierken 
and
> didn't realize that you never came up with solutions you considered
> complete. 

I don't expect "complete" yet.

> If you can give me the URLs we'll all be at the same place
> again (reset our state based on hypertext) and I'll add my thoughts.

If we do it on the Rest Wiki, then the topic will be a Web resource 
(or hyperlinked group of same) and we won't need to chase all the 
fragments again.  Wikis have some problems, but for me, they are much 
more RESTful than Yahoo Groups.

> One thing I remember is that some people were using "transaction" 
in the
> sense of transactional integrity and some people were using it 
merely to
> mean a "Communication involving two or more people that affects all
> those involved; personal interaction"/"The doing or performing of 
any
> business; management of any affair; performance."
> http://www.dictionary.com/cgi-bin/dict.pl?term=transaction&r=67
> 
> We had this same terminological problem during the REST/SOAP panel.
> Lucas used transaction in the latter sense and Rohit thought he 
meant in
> the database sense.

The appropriate transaction model for Web conversations is another 
very closely related issue.  I strongly favor state-alignment 
transactions over anything even remotely resembling database 
transactions, but that may be because I am thinking of business 
exchanges.  I suspect mostly people are not even thinking of the 
issues.  W3C-ws-arch is still thinking database transactions.

-Bob Haugen









-----------------------------------------------------------------------------------
Post ID:1322
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-23 18:14:51
Subject:Re: [PMX:#] [rest-discuss] State Machine As Hypertext
Message:

You are right that wikis are more RESTful. So go ahead and use one. My
only complaints are:

 a) they don't generate events in my inbox

 b) the editing user interface is so brutal.

There are so many web-based forums out there these days that the
limitations of web browsers as text editors are becoming really
annoying. One day I have to think about whether this is purely an
implementation issue or a lack of standardization. For instance maybe
there should be an attribute that would indicate whether a textarea can
contain HTML, so that the editor could use its HTML editor. Maybe there
should be a way to say "UserWillWantSpellCheck".  Also as an
implementation issue it is bad that the "back button" can lose your
edits. But I know these are not problems with wiki in particular and I
will be happy to work on the Wiki.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1323
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-23 18:54:26
Subject:Re: [PMX:#] [rest-discuss] State Machine As Hypertext
Message:

Paul Prescod wrote:
> You are right that wikis are more RESTful. So go ahead and use one. 
My
> only complaints are:
> 
>  a) they don't generate events in my inbox
> 
>  b) the editing user interface is so brutal.

I agree with you on both of the above.  But then I use Yahoo Groups 
strictly from the browser (do not get emails) so it is even worse.

However, you are one of the main people I want to engage, so let's 
keep going in rest-discuss for a bit and I'll summarize anything we 
agree on to the rest-wiki page.  Maybe the best of both venues, such 
as they are.

The three main scenarios I remember from previous rest-discuss 
conversations were:

1. Event notifications (publish-subscribe).  They already have their 
own rest-wiki page: 
http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents

2. Purchasing (offer-acceptance), with many fragments of conversation 
on rest-discuss, but no rest-wiki page.

Purchasing can be client-server, in which case Amazon is probably the 
defacto standard, and is fairly RESTful.  Peer-to-peer for B2B is 
different, and the existing standards (RosettaNet and ebXML) use 
something like EDI-mailbox-style SOAP.  (ebXML actually uses SOAP, 
RNet uses something analogous that they defined way before SOAP.)

3. Travel: your Expedia example, and another based on Appendix D of 
the Web Services Flow Language document.

Expedia is client-server; I think the WSFL example included P2P 
interactions.  

Then there were a couple of rest-discuss threads on session state, 
that is analogous to transaction-state or conversation-state in P2P 
EDI-mailbox-style.

I'm most interested in trying to RESTify B2B transactions.  
By "transaction", I mean "business state alignment" between two 
trading partners, for example, an offer-acceptance transaction where 
both parties have definitive evidence of agreement that the offer was 
accepted (or not).

And yes I do think the transaction-model issue deserves its own rest-
wiki page.

My next step is to collect a bunch of URLs to previous rest-discuss 
thread-starting messages and other related documents.  I'll post them 
on a separate rest-wiki page linked to the StateMachinesAsHypertext 
page.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1324
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-23 18:57:03
Subject:HTTPEvents for Rest-Wiki
Message:

Paul Prescod wrote:
> You are right that wikis are more RESTful. So go ahead and use one. 
My
> only complaints are:
> 
>  a) they don't generate events in my inbox
> 
>  b) the editing user interface is so brutal.

So what would it take to implement HTTPEvents for Rest-Wiki?
http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents







-----------------------------------------------------------------------------------
Post ID:1325
Sender:"xemplify" <xemplify@...>
Post Date/Time:2002-05-23 19:48:56
Subject:Re: REST Questions
Message:

--- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote:

> I'd like to hear what Walter said - but a 'template' approach might 
> be interesting.

I was paraphrasing Walter's general approach to XML processing. I 
gave my own personal interpretation in the example, I think it 
deviates from Walter's intention. I found this piece written by him 
that you might find interesting:
<http://ibiblio.org/bosak/conf/xmldev99/perry.htm>

> Let's say we did that - how would the (automated) client know what 
> parts of the template to modify?
> If we had XML, we could use XPath or something. Then the XML could 
> change as long as the XPath used didn't need to change.

Yes, that's one way of doing it. Let's say I set the part id at XPath:
/order/orderline[i]/part-ref
and the quantity at:
/order/orderline[i]/quantity

Or just walk the tree until I find 'part-ref' or 'part-id' or 'part*' 
and keep a record of the nodes traversed and then make the XPath on 
the fly and set the part id there. I think in Walter's approach the 
server side would do such piecing the data together from the input it 
receives.

> I'd like to hear more of how this would work... I'm somewhat 
> tangled up in
> the world of PO/PO-ACK/etc. right now, so this is interesting to me.

I just threw the idea out to see what people thought. I'm not really 
sure on implementation details, or if what I described is really 
feasible.

Regards,
Robert McKinnon








-----------------------------------------------------------------------------------
Post ID:1326
Sender:"scarhill" <jim@...>
Post Date/Time:2002-05-23 21:06:43
Subject:Hyperlinks Matter
Message:

A colleague pointed out Jon Udell's InfoWorld article on REST:

http://www.infoworld.com/articles/pl/xml/02/05/20/020520pllinks.xml

IW also covered the TAG debate on SOAP last week:

http://www.infoworld.com/articles/hn/xml/02/05/10/020510hnsoapdebate.xml

I've been trying to do some REST evangelization, so it's nice to be
able to point to articles like these two and Paul's at xml.com when
making my case. It's even better when the people I'm trying to
evangelize point out the articles to me!

Jim

(I tried posting this yesterday, but never saw the message come
through. If anyone else did, I apologize.)







-----------------------------------------------------------------------------------
Post ID:1327
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-05-24 01:42:42
Subject:The evolution of REST
Message:

Pauls' comment in 'REST/SOAP ideas summary' 
(http://groups.yahoo.com/group/rest-discuss/message/1301) where he said 
"The term REST has evolved (for better or worse) from what Roy Fielding 
used it to mean..." prompted me to go back to the source and contrast it 
with what is written at the front page of the REST wiki where it says "In 
particular, REST suggests that what the Web got right is having a small, 
global set of verbs (HttpMethods: GET, POST, PUT, DELETE, etc) applied to a 
potentially infinite set of nouns..." Nowhere in either of the standard 
references to REST by Fielding does it suggest this at all, there is no 
mention of nouns, verbs, coordination languages or even Unix pipelines for 
that matter.

It appears that the entire front page at REST wiki bears little if any 
correlation to the term REST as defined by Fielding and at the very least 
it should say this and describe the process by which the term evolved or 
was co-opted to take on the meaning/s detailed on the wiki.

Does this strike anyone else as confusing or misleading?

Robert







-----------------------------------------------------------------------------------
Post ID:1328
Sender:"bouncybabbage" <jdougan@...>
Post Date/Time:2002-05-24 05:51:40
Subject:Re: REST/SOAP ideas summary
Message:

Interesting, but I have a suggestion.

Either scratch the OSI protocol layers discussion or try comparing
against the Arpanet/Internet Reference Model instead. As is, I think
it weakens your argument.

Most of the existing protocols on the Internet don't follow the OSI
model either, so another protocol behaving in a non OSI way is no big
deal. Specifically if you look at RFC-871, it observes that the
Internet design is not a rigid 7 layer stack, but a hierarchy where
you can do the sorts of protocol nesting that SOAP is doing. Without
that sort of nesting tunneling and gatewaying are impossible.

For that matter, the OSI official position on their 7-layer cake is
that it is supposed to be descriptive and not prescriptive, offering a
language to talk about protocols and not an absolute dictum as to
protocol design. If the OSI committees had realized this we'd have
been spared much hassle.

http://www.faqs.org/rfcs/rfc871.html
http://www.med.utah.edu/medinfo/horthner/webclass/sld018.htm

Hmmmm...thinking about it, this whole deal with SOAP and REST reminds
me of the OSI/ARPANet wars of years gone by. They had a nice looking
model with a gawd-awful committee process pushing it, we had a simple
model and the no standardization without implementation policy.

--john

[B]eware of the panacea peddlers: just because you wind up naked
doesn't make you an emperor. -- Michael A Padlipsky

--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
> 	== REST From a Protocols Point of View ==
> 
> There is another way to come to the REST position without any
interest
> in Web architecture. One can look at SOAP purely as a protocol
without
> even considering the problems it is supposed to solve. It bends or
> breaks all of the rules common among Internet protocols. For
instance,
> if one reads a book on the roles of networking protocols, it is
clear
> that SOAP is a layer 6 (presentation layer) protocol but SOAP
actually
> runs on top of HTTP and SMTP, which are both layer 7 protocols. That
> makes SOAP a layer 8 protocol. Unfortunately the standard network
stack
> diagrams max out at 7! By definition the 7th layer, the application
> layer, is the top layer. SOAP treats layer 7 protocols as
"transport"
> protocols. It pretends that they are layer 4 protocols. This causes
> various sorts of discomfort for system administrators, security
> analysts and protocol purists.
> 







-----------------------------------------------------------------------------------
Post ID:1329
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-05-24 06:16:08
Subject:Re: [rest-discuss] The evolution of REST
Message:

At 12:15 PM 24/05/2002, Jeff Bone wrote:

>> Does this strike anyone else as confusing or misleading?
>
>It may be confusing, but it's far from misleading.  The front page of that
>wiki --- indeed, part of the motivation for wiki, the list, etc. --- was to
>attempt to communicate the understanding several of us garnered from long
>and sometimes heated discussions with Roy.  So it's not surprising that
>different language is used to describe the same concepts in different
>contexts:  small connector set -> generic interfaces -> coordination
>languages, etc.
>
>I don't think this is what Paul is talking about when he says that the term
>has evolved, but then I'm not really sure what he's talking about in that
>context.  IMHO, REST has a very specific, literal interpretation grounded in
>Roy's work.  (To the extent that I might've inadvertently "diluted" that
>meaning with some of the things I've hucked out there discussing this stuff,
>my deep apologies.)

Having re-read your "REST, RPC, mountains, molehills, and a retraction (sort of)" at http://www.xent.com/pipermail/fork/2001-August/002801.html I can see where you are coming from and am now somewhat less confused - although, some might argue differently:-). It appears that for me at least, the wiki fails to communicate the 'steps to REST enlightenment' :-) that you describe in that email. 

Robert









-----------------------------------------------------------------------------------
Post ID:1330
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-24 06:22:29
Subject:Re: [rest-discuss] The evolution of REST
Message:

----- Original Message -----
From: "Robert Leftwich" <robert@...>

>
> It appears that the entire front page at REST wiki bears little if any
> correlation to the term REST as defined by Fielding and at the very least
> it should say this and describe the process by which the term evolved or
> was co-opted to take on the meaning/s detailed on the wiki.
>
> Does this strike anyone else as confusing or misleading?
>

I think early on there was a need to contrast REST with the different RPC
approaches - and the key introduction in that realm was the comparison of
nouns .vs. verbs.

I looked over Roy's dissertation a few days ago also and summarized some
(but not all) points of REST as this:
>
> Can someone enumerate the distinguishing characteristics of a REST
> system?  In other words, how will I recognize a REST service when I see
> one?
 - addressable resources
 - uniform interfaces that apply to all resources
 - stateless messages
 - 'representations' - multiple content types accepted or sent

If you've already moved past the "rpc doesn't scale" arguments, these and
other aspects of Roy's paper have more meat. Perhaps JeffB and MarkB would
like to update the front page to clarify the issues you brought up.








-----------------------------------------------------------------------------------
Post ID:1331
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-24 06:57:14
Subject:Re: [rest-discuss] The evolution of REST
Message:

----- Original Message -----
From: "Robert Leftwich" <robert@...>


> with what is written at the front page of the REST wiki where it says "In
> particular, REST suggests that what the Web got right is having a small,
> global set of verbs (HttpMethods: GET, POST, PUT, DELETE, etc) applied to
a
> potentially infinite set of nouns..." Nowhere in either of the standard
> references to REST by Fielding does it suggest this at all, there is no
> mention of nouns, verbs, coordination languages or even Unix pipelines for
> that matter.

Section 5.1.5 [1] explicitly talks about 'Uniform Interface'. "The central
feature that distinguishes the REST architectural style from other
network-based styles is its emphasis on a uniform interface between
components "
This does not explicitly talk about methods, but the translation for a wider
audience (through the Wiki and this forum) framed it in terms familiar to
the programming community.

In addition to that, there are several mentions of 'generic interface' and
'standard methods'.
[2] "A cache is able to determine the cacheability of a response because the
interface is generic rather than specific to each resource"
There is a section [3] that talks about "...standard methods and media types
are used to indicate semantics and exchange information".
Also there is mention of "...the added constraints of the generic resource
interface..." [4]

The principal aspects of REST are enumerated (section 5.1.5) in a way not
easily digested by the current audience of the REST forums.
Adding clarity and bringing these down to earth is why the this forum and
the Wiki was started.

---

[1]
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#5_1_5
"The central feature that distinguishes the REST architectural style from
other network-based styles is its emphasis on a uniform interface between
components "

[2]
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5
_2_2
"A cache is able to determine the cacheability of a response because the
interface is generic rather than specific to each resource. "

[3]
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5
_3_1
"REST enables intermediate processing by constraining messages to be
self-descriptive: interaction is stateless between requests, standard
methods and media types are used to indicate semantics and exchange
information, and responses explicitly indicate cacheability."

[4]
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5
_4
"REST component interactions are structured in a layered client-server
style, but the added constraints of the generic resource interface create
the opportunity for substitutability and inspection by intermediaries"







-----------------------------------------------------------------------------------
Post ID:1332
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-05-24 08:56:04
Subject:REST-OO?
Message:

Hi,

I recently began reading the discussion on REST vs. SOAP on this dl and on
the RESTwiki and found it to be quite eye-opening.  I especially appreciate
Paul Prescod's excellent articles and posts, and of course Roy Fielding's
seminal thesis.

Of the numerous benefits of the REST model, two things jumped out at me:

1. The benefit of a naming system (URI's) that encourages the explicit
naming of resources so that those resources can become active participants
in the system - thus, become leverageable by other applications and used in
ways that the original resource provide may not have thought of.

2. The importance of using a few universal verbs (GET, PUT, POST, DELETE)
for applications that want to scale to the web level, where it is difficult
to coordinate and enforce changes to every participant.

These two concepts got me to thinking about REST and Object-Oriented
programming.  At first, it would seem clear that they are opposing
architectural approaches, especially when OO is view in the terms of CORBA
or SOAP-RPC.  But, I actually think there is more in common than meets the
eye.  Maybe this has already been discussed, but I would like to explore a
way of looking at REST from an object-oriented viewpoint.  

One of the fundamental concepts behind OO is that everything is an object
and every object has basic methods that it must support.  By using these
basic methods, a whole bunch of interesting  applications can be written
which manipulate objects without knowing anything else about these objects
(for example, containers, sorters, formatters, storage, etc).

Every object is addressable in the namespace of the OO system, in a similar
way that URI's are addressable in the current web system.  And the generic
object manipulators are not unlike how people create new applications from
URI's that may be totally outside of the original intent of the URI
providers.

I think where CORBA and SOAP-RPC deviate from this is in their focus:

1. They don't encourage making all objects addressable, but rather encourage
hiding objects behind a few addressable objects.

2. That they don't focus on just a few universal methods for all objects,
but focus on defining new methods, many of them simply to access the data
hidden per above.

These two factors together vastly diminish the capability to benefit from
the web's network effects and reduce the ability to create interesting
applications from existing "objects".

To take this a little further, it seems that there may be some room for
expanding from the current 4 basic methods (GET, PUT, POST, and DELETE)
which are very much document-centric to include some basic methods for
transaction-centric objects.

As Bob Haugen mentioned in recent email, we would like to model transactions
in REST.  If we think of URI's are objects, a transaction may be like a
thread object.  We may want to add START, STOP, CANCEL, and GETSTATE (maybe
can be overloaded by GET).  With some basic set of extensions, we can write
applications that can control and monitor arbitrary transaction systems.

Anyway, just some late night ramblings.

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1333
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-05-24 11:28:44
Subject:Re: [rest-discuss] The evolution of REST
Message:

At 04:57 PM 24/05/2002, S. Mike Dierken wrote:

>----- Original Message -----
>From: "Robert Leftwich" <robert@...>
>
>
>> with what is written at the front page of the REST wiki where it says "In
>> particular, REST suggests that what the Web got right is having a small,
>> global set of verbs (HttpMethods: GET, POST, PUT, DELETE, etc) applied to
>a
>> potentially infinite set of nouns..." Nowhere in either of the standard
>> references to REST by Fielding does it suggest this at all, there is no
>> mention of nouns, verbs, coordination languages or even Unix pipelines for
>> that matter.
>
>Section 5.1.5 [1] explicitly talks about 'Uniform Interface'. "The central
>feature that distinguishes the REST architectural style from other
>network-based styles is its emphasis on a uniform interface between
>components "

I find it interesting that the feature of REST that is gaining almost all the attention is fourth out of six in the list of  constraints that define the REST architectural style. Note that Fielding says 'the central feature that distinguishes the REST architectural style from other
network-based styles...' , i.e. uniform interfaces are a central distinguishing feature, not THE central feature of the entire architecture.

>This does not explicitly talk about methods, but the translation for a wider
>audience (through the Wiki and this forum) framed it in terms familiar to
>the programming community.....
>
>The principal aspects of REST are enumerated (section 5.1.5) in a way not
>easily digested by the current audience of the REST forums.
>Adding clarity and bringing these down to earth is why the this forum and
>the Wiki was started.

I think I've just identified one of the problems I have been having - I was reading Fieldings' work and thinking along architectural style lines i.e. nothing implementation specific, and then reading the REST wiki where it talks about very implementation specific details, i.e. HTTP methods, and I was not making (and the wiki doesn't make explicit) the connection that HTTP is a feature of the current implementation of the REST architectural style, it just states categorically that  'REST suggests that what the Web got right is having a small, global set of verbs (HttpMethods...'

Would the following be clearer and more importantly, accurate?

'In particular, REST suggests that what the Web got right in its' implementation of the architectural style whose key elements are addressable resources, a uniform interface between components, stateless messages and representations that capture the state of a resource is the use of URI's as the addressable resources, HTTP methods (GET, POST, PUT, DELETE, etc) as the uniform interface, HTTP as the stateless messages and media types as the representations.

The use of HTTP methods can be viewed as a small, global set of verbs that are applied to a potentially infinite set of nouns (URIs - though we're careful to keep in mind that some VerbsCanAlsoBeNouns)...'

Robert











-----------------------------------------------------------------------------------
Post ID:1334
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-24 21:56:15
Subject:Re: [rest-discuss] REST-OO?
Message:

If you transition from 'object' oriented programming to 'interface' oriented
programming and transition from method based access to property based
access, I think you will find many similarities to REST in the micro-cosm of
procedural languages.

By moving to interfaces rather than objects, you tend towards reducing the
total number of interfaces in the system. When you move towards using
properties (getFoo(), setFoo()) you also tend to have these properties
defined in terms of interfaces - often reusing the same interface. In the
end - especially with languages with property-oriented syntax - a lot of
syntactical dirt starts falling away from your code and things become
simpler and cleaner. Without soap. ;)




----- Original Message -----
From: "Joe Hsy" <joe.hsy@...>
To: <rest-discuss@yahoogroups.com>
Sent: Friday, May 24, 2002 1:56 AM
Subject: [rest-discuss] REST-OO?


>
> Hi,
>
> I recently began reading the discussion on REST vs. SOAP on this dl and on
> the RESTwiki and found it to be quite eye-opening.  I especially
appreciate
> Paul Prescod's excellent articles and posts, and of course Roy Fielding's
> seminal thesis.
>
> Of the numerous benefits of the REST model, two things jumped out at me:
>
> 1. The benefit of a naming system (URI's) that encourages the explicit
> naming of resources so that those resources can become active participants
> in the system - thus, become leverageable by other applications and used
in
> ways that the original resource provide may not have thought of.
>
> 2. The importance of using a few universal verbs (GET, PUT, POST, DELETE)
> for applications that want to scale to the web level, where it is
difficult
> to coordinate and enforce changes to every participant.
>
> These two concepts got me to thinking about REST and Object-Oriented
> programming.  At first, it would seem clear that they are opposing
> architectural approaches, especially when OO is view in the terms of CORBA
> or SOAP-RPC.  But, I actually think there is more in common than meets the
> eye.  Maybe this has already been discussed, but I would like to explore a
> way of looking at REST from an object-oriented viewpoint.
>
> One of the fundamental concepts behind OO is that everything is an object
> and every object has basic methods that it must support.  By using these
> basic methods, a whole bunch of interesting  applications can be written
> which manipulate objects without knowing anything else about these objects
> (for example, containers, sorters, formatters, storage, etc).
>
> Every object is addressable in the namespace of the OO system, in a
similar
> way that URI's are addressable in the current web system.  And the generic
> object manipulators are not unlike how people create new applications from
> URI's that may be totally outside of the original intent of the URI
> providers.
>
> I think where CORBA and SOAP-RPC deviate from this is in their focus:
>
> 1. They don't encourage making all objects addressable, but rather
encourage
> hiding objects behind a few addressable objects.
>
> 2. That they don't focus on just a few universal methods for all objects,
> but focus on defining new methods, many of them simply to access the data
> hidden per above.
>
> These two factors together vastly diminish the capability to benefit from
> the web's network effects and reduce the ability to create interesting
> applications from existing "objects".
>
> To take this a little further, it seems that there may be some room for
> expanding from the current 4 basic methods (GET, PUT, POST, and DELETE)
> which are very much document-centric to include some basic methods for
> transaction-centric objects.
>
> As Bob Haugen mentioned in recent email, we would like to model
transactions
> in REST.  If we think of URI's are objects, a transaction may be like a
> thread object.  We may want to add START, STOP, CANCEL, and GETSTATE
(maybe
> can be overloaded by GET).  With some basic set of extensions, we can
write
> applications that can control and monitor arbitrary transaction systems.
>
> Anyway, just some late night ramblings.
>
> //Joe
>
> This email message, and any attachments to it, are for the sole use of the
> intended recipients, and may contain confidential and privileged
> information.  Any unauthorized review, use, disclosure or distribution of
> this email message or its attachments is prohibited.  If you are not the
> intended recipient, please contact the sender by reply email and destroy
all
> copies of the original message.
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:1335
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-05-24 22:27:32
Subject:Re: [rest-discuss] The evolution of REST
Message:

Robert Leftwich wrote:
> 
> Pauls' comment in 'REST/SOAP ideas summary'
> (http://groups.yahoo.com/group/rest-discuss/message/1301) where he said
> "The term REST has evolved (for better or worse) from what Roy Fielding
> used it to mean..." prompted me to go back to the source and contrast it
> with what is written at the front page of the REST wiki where it says "In
> particular, REST suggests that what the Web got right is having a small,
> global set of verbs (HttpMethods: GET, POST, PUT, DELETE, etc) applied to a
> potentially infinite set of nouns..." Nowhere in either of the standard
> references to REST by Fielding does it suggest this at all, there is no
> mention of nouns, verbs, coordination languages or even Unix pipelines for
> that matter.

I strongly agree that the front page of the Wiki emphasizes certain
aspects that were central to a particular conversation at a particular
time. I personally have found the "addressing" argument much more
persuasive and easy to understand, so that is MY focus, even though it
is not, er, addressed on the front of the Wiki.

Also, I have long been concerned that the focus on a "small set of
verbs" misses the point that it is not the small set that is central but
rather their generality and commonality. Four, six, ten, fifty. It
doesn't matter much as long as they are general.

I've also come over time to see this argument as incomplete:

"Another way of saying this is that REST works because it keeps
interface complexity from scaling with N^2. In an infinite world of
uncoordinated (i.e., independently developed) objects that interact with
one another using specialized interfaces, the interface "connection"
complexity is order N^2, because each object can have a unique interface
to each other object. An infinite world of uncoordinated objects that
share a common, generic interface, on the other hand, has only a
complexity of order N, because no matter how many objects there are,
they will all be able to act on one another in predictable ways."

Let's be more explicit, we are pushing complexity around and hopefully
reducing it but not competely changing its order notation. We are not
going to take a purchase order client system and plug it into a content
management system and expect them to just understand each other anytime
soon. My sense is that REST helps by *centralizing* the
incompatibilities in the vocabulary and stanardizating *as much as can
be standradized* (which is certainly addressing and secondarily method
names).

And what I really meant when I said that the term REST had evolved
included this noun/verb stuff but also 

 a) the emphasis on addressing which is more implicit in Roy's writing, 

 b) the sense that it is a competitor to web services

 c) the sense that it should even be used for web-service-like stuff
(Roy has never said that to me...maybe he doesn't agree or maybe he just
doesn't care)

 d) many of the best practices we send around which really are about
"how to build applications on a REST framework" as opposed to "what is
REST" (the difference between OO languages and OO design).

BTW, in case anyone cares, ;), I am about to run off for the weekend but
I'm downloading REST-related pages to do some writing and thinking about
session handling, OO+REST etc.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1336
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-05-25 00:49:16
Subject:RE: [rest-discuss] The evolution of REST
Message:

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> -----Original Message-----
> From: Paul Prescod [mailto:paul@...] 
> 
> Also, I have long been concerned that the focus on a "small 
> set of verbs" misses the point that it is not the small set 
> that is central but rather their generality and commonality. 

Shared understanding. A GET has shared meaning across the web
(what's maybe not shared is when to prefer it). Anyone can
implement it, any node can understand it. Speech acts for the
masses.

Bill de hra



-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPO7fiuaWiFwg2CH4EQIQgACg3eUSMCAf6RKmPhYXMZgtKfLH9IIAn3gH
2JTUm+fgU2x3m5oBKp0TR6pC
=aMA5
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:1337
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-05-26 19:21:56
Subject:Enabling the evolution of the Web using REST
Message:

I gave a talk on REST on Friday.  A woman in the audience made an
excellent point:

"In order to counteract all the hype around SOAP, you need to point out
not only the differences in REST versus SOAP for today's Web services,
but also the differences in enabling capability in tomorrow's
environment [e.g., semantic Web].  It would be an easy step from your
REST examples to RDF and ontology enabling, whereas with SOAP I'm not
sure what would happen - like with firewalls, how could an inferencer do
it's thing if the data is all buried inside?"

She noted that DAML-S is REST-ful.  This week I will talk to her more
about this.

/Roger

P.S. I have added a lot more material to my REST tutorial (including the
above comments).  As always, feedback is much appreciate.







-----------------------------------------------------------------------------------
Post ID:1338
Sender:Dan Brickley <danbri@...>
Post Date/Time:2002-05-26 19:51:14
Subject:Re: [rest-discuss] Enabling the evolution of the Web using REST
Message:

+cc: maxf@...

On Sun, 26 May 2002, Roger L. Costello wrote:

> I gave a talk on REST on Friday.  A woman in the audience made an
> excellent point:
>
> "In order to counteract all the hype around SOAP, you need to point out
> not only the differences in REST versus SOAP for today's Web services,
> but also the differences in enabling capability in tomorrow's
> environment [e.g., semantic Web].  It would be an easy step from your
> REST examples to RDF and ontology enabling

This is interesting. I'm working w/ Max (cc:'d) on showing SOAP Encoding
XSLT'd into RDF, and queried and stored using RDF tools. And *merged*,
which is imho the interesting thing. Taking SOAP Encoded msgs from
multiple sources and merging them into a single store, so that queries
that need both info-sources to be answered can be serviced.

The two worlds aren't as far apart as people suppose...

More on this soon I hope, using the Ruby/RAA stuff as a testbed (see prev
thread here on this...).

cheers,

Dan


-- 
mailto:danbri@...
http://www.w3.org/People/DanBri/







-----------------------------------------------------------------------------------
Post ID:1339
Sender:Allan Doyle <adoyle@...>
Post Date/Time:2002-05-26 22:08:00
Subject:Re: [rest-discuss] Enabling the evolution of the Web using REST
Message:

On Sunday 2002-05-26 at 15:51:14(-0400) Dan Brickley wrote:
 > 
 > +cc: maxf@...
 > 
 > On Sun, 26 May 2002, Roger L. Costello wrote:
 > 
 > > I gave a talk on REST on Friday.  A woman in the audience made an
 > > excellent point:
 > >
 > > "In order to counteract all the hype around SOAP, you need to point out
 > > not only the differences in REST versus SOAP for today's Web services,
 > > but also the differences in enabling capability in tomorrow's
 > > environment [e.g., semantic Web].  It would be an easy step from your
 > > REST examples to RDF and ontology enabling

Interesting. I was watching a presentation on RDF a couple of weeks
ago and came to the realization that for RDF to work properly it seems
you have to have REST. RDF is all about links and you can't link to a
SOAP endpoint because the SOAP endpoints are just conduits that listen
for and dispatch SOAP messages.

 > 
 > This is interesting. I'm working w/ Max (cc:'d) on showing SOAP Encoding
 > XSLT'd into RDF, and queried and stored using RDF tools. And *merged*,
 > which is imho the interesting thing. Taking SOAP Encoded msgs from
 > multiple sources and merging them into a single store, so that queries
 > that need both info-sources to be answered can be serviced.

Yes, this makes sense. SOAP messages themselves are documents. But
most people would ship those messages to SOAP listeners. They would
not just put the messages at the end of a URI.

 > 
 > The two worlds aren't as far apart as people suppose...

This statement is true as far as SOAP messages are concerned. It's the
SOAP RPC side of the coin that poses a challenge.

 > 
 > More on this soon I hope, using the Ruby/RAA stuff as a testbed (see prev
 > thread here on this...).
 > 
 > cheers,
 > 
 > Dan
 > 
 > 
 > -- 
 > mailto:danbri@...
 > http://www.w3.org/People/DanBri/
 > 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle                         http://www.intl-interfaces.com
adoyle@...







-----------------------------------------------------------------------------------
Post ID:1340
Sender:Dan Brickley <danbri@...>
Post Date/Time:2002-05-26 22:53:48
Subject:Re: [rest-discuss] Enabling the evolution of the Web using REST
Message:

On Sun, 26 May 2002, Allan Doyle wrote:

> On Sunday 2002-05-26 at 15:51:14(-0400) Dan Brickley wrote:
>  >
>  > +cc: maxf@...
>  >
>  > On Sun, 26 May 2002, Roger L. Costello wrote:
>  >
>  > > I gave a talk on REST on Friday.  A woman in the audience made an
>  > > excellent point:
>  > >
>  > > "In order to counteract all the hype around SOAP, you need to point out
>  > > not only the differences in REST versus SOAP for today's Web services,
>  > > but also the differences in enabling capability in tomorrow's
>  > > environment [e.g., semantic Web].  It would be an easy step from your
>  > > REST examples to RDF and ontology enabling
>
> Interesting. I was watching a presentation on RDF a couple of weeks
> ago and came to the realization that for RDF to work properly it seems
> you have to have REST. RDF is all about links and you can't link to a
> SOAP endpoint because the SOAP endpoints are just conduits that listen
> for and dispatch SOAP messages.

Yep. Using GET would fix a lot of this. I hear something like that is in
the works. A large % of (public) SOAP services seem to basically be database
lookups, so GETable data would be very useful.

>
>  >
>  > This is interesting. I'm working w/ Max (cc:'d) on showing SOAP Encoding
>  > XSLT'd into RDF, and queried and stored using RDF tools. And *merged*,
>  > which is imho the interesting thing. Taking SOAP Encoded msgs from
>  > multiple sources and merging them into a single store, so that queries
>  > that need both info-sources to be answered can be serviced.
>
> Yes, this makes sense. SOAP messages themselves are documents. But
> most people would ship those messages to SOAP listeners. They would
> not just put the messages at the end of a URI.

There are lots of unexpected uses for things in the Web. SOAP Encoding
files could reasonable turn up in tar.gz files, on CDROMs, attached to
mail messages, embedded in media objects. To the extent that it's a useful
data format, it should be usable outside of protocol transactions. Maybe
it deserves an application/??? content type?


>  > The two worlds aren't as far apart as people suppose...
>
> This statement is true as far as SOAP messages are concerned. It's the
> SOAP RPC side of the coin that poses a challenge.

Oddly enough, I seem to be the only person who sees RDF as being
(technically) closer to the SOAP Encoding format, which in turn seems
mostly used for RPC interaction with SOAP services. Both variants pose a
challenge, that's for sure :)



Let me try to elaborate on the RDF <-> SOAP Encoding thing by example
(thanks to Max Foumentin and Holden Glova for help putting this together):

First a chunk of SOAP Enc XML, then the RDF, then the triples of the graph
that the latter encodes. If you can't read both SOAP Encoding and RDF
syntax, you'll have to take some of this on faith. Main message: the two
are pretty close, different XML encodings of a very similar data model.



So...

Here is some software description metadata, in SOAP Encoding format:

(here is your brain...)

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<env:Body>
<RAA_Info xmlns:n1="http://schemas.xmlsoap.org/soap/encoding/" xmlns:n2="http://www.ruby-lang.org/xmlns/ruby/type/custom" xsi:type="n2:RAA_Info" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<category xsi:type="n2:RAA_Category">
<minor xsi:type="xsd:string">devel</minor>
<major xsi:type="xsd:string">Library</major>
</category>
<update xsi:type="xsd:dateTime">2000-10-12T19:10:26Z</update>
<owner xsi:type="n2:RAA_Owner">
<email xsi:type="xsd:string">gotoken@...</email>
<name xsi:type="xsd:string">gotoken</name>
<id xsi:type="xsd:string">gotoken@...-gotoken</id>
</owner>
<product xmlns:n3="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1" xsi:type="n3:Product">
<description xsi:type="xsd:string">xmp is an example printer, which is helpful to show example code.</description>
<version xsi:type="xsd:string">2000-10-12</version>
<license xsi:type="xsd:string">Ruby's</license>
<download xsi:type="xsd:string">http://www.notwork.org/~gotoken/ruby/p/xmp/xmp-000207.tar.gz</download>
<status xsi:type="xsd:string">stable</status>
<homepage xsi:type="xsd:string">http://www.notwork.org/~gotoken/ruby/p/xmp/</homepage>
<name xsi:type="xsd:string">xmp</name>
</product>
</RAA_Info>
</env:Body>
</env:Envelope>


Here is some software description metadata, in an RDF/XML encoded format:

(here is your brain on drugs... ;-)

(thanks to an XSLT from Max; URL to follow another time)

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#" xmlns:raa="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <RAA_Info xmlns:n2="http://www.ruby-lang.org/xmlns/ruby/type/custom" xmlns:n1="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<category rdf:parseType="Resource">
      <rdf:type rdf:resource="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#RAA_Category"/>
<minor>devel</minor>
<major>Library</major>
</category>
<update>2000-10-12T19:10:26Z</update>
<owner rdf:parseType="Resource">
      <rdf:type rdf:resource="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#RAA_Owner"/>
<email>gotoken@...</email>
<name>gotoken</name>
<id>gotoken@...-gotoken</id>
</owner>
<product xmlns:n3="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1" rdf:parseType="Resource">
      <rdf:type rdf:resource="http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#Product"/>
<description>xmp is an example printer, which is helpful to show example code.</description>
<version>2000-10-12</version>
<license>Ruby's</license>
<download>http://www.notwork.org/~gotoken/ruby/p/xmp/xmp-000207.tar.gz</download>
<status>stable</status>
<homepage>http://www.notwork.org/~gotoken/ruby/p/xmp/</homepage>
<name>xmp</name>
</product>
</RAA_Info>
</rdf:RDF>


Here is the result of feeding this to an RDF parser:

(a couple of parser bugs in this, which I won't bother fixing. the
product and update lines are wrong. ignore those please!)

this is a textual representation of the abstract graph structure, encoded
in the RDF and (indirectly) in the SOAP Encoding too.

first column is source object ID, second is URI of the relationship
that connects them, 3rd is target object ID or literal value. This format
is N-Triples, which the RDF Working Group use for test cases,
see http://www.w3.org/TR/rdf-testcases/ for more on format and its use in
testing and QA for RDF.

_:genid1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#RAA_Info> .
_:genid2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#RAA_Category> .
_:genid2 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#minor> "devel" .
_:genid2 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#major> "Library" .
_:genid1 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#category> _:genid2 .
_:genid1 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#update> _:genid3 .
_:genid4 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#RAA_Owner> .
_:genid4 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#email> "gotoken@..." .
_:genid4 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#name> "gotoken" .
_:genid4 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#id> "gotoken@...-gotoken" .
_:genid1 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#owner> _:genid4 .
_:genid5 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#Product> .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#description> "xmp is an example printer, which is helpful to show example code." .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#version> "2000-10-12" .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#license> "Ruby's" .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#download> "http://www.notwork.org/~gotoken/ruby/p/xmp/xmp-000207.tar.gz" .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#status> "stable" .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#homepage> "http://www.notwork.org/~gotoken/ruby/p/xmp/" .
_:genid5 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#name> "xmp" .
_:genid1 <http://www.ruby-lang.org/xmlns/soap/interface/RAA/0.0.1#product> _:genid5 .

The mapping (via Max's XSLT) had to make a few assumptions (eg. re
namespaces). But the basic graph structure is imho much the same. Mapping
SOAP Encoding with arrays etc might be fiddlier, or even impossible.
Nobody knows yet. Note also the current demo is w/ version 1.1 SOAP not
the 1.2 under development at W3C.

Why do I find this interesting?

The former format has a load of RPC-ish tools. They make it easy to map
the data into programmatic objects.

The latter format has a load of RPC-ish tools. They make it easy to merge
the data into RDF stores and query it with other URI-oriented data loaded
from other sources.

It'd be nice to use both sets of tools on the same data. Really nice...

Is this making any sense?

Dan


-- 
mailto:danbri@...
http://www.w3.org/People/DanBri/







-----------------------------------------------------------------------------------
Post ID:1341
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-27 03:17:25
Subject:Re: [rest-discuss] REST-OO?
Message:

Wow, awesome post.  I too agree that the OO nature of REST is quite
interesting.  A REST component basically does all the things you'd
expect of an object; has identity, encapsulated behaviour, supports
inheritance through a type system such as RDF.  Generic interfaces
are also a feature of component based OO systems, such as Java Beans.
The only thing REST doesn't do from an OO POV is hide data.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1342
Sender:Chris Croome <chris@...>
Post Date/Time:2002-05-27 14:09:08
Subject:Open Archives Initiative
Message:

Hi

Has anyone on this list taken a look at the OAI stuff?

  http://www.openarchives.org/

My impression is that the first version of their spec:

 http://www.openarchives.org/OAI/openarchivesprotocol.html

Is quite RESTful but the new one is more SOAP like and not so RESTful:

  http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm

However I must admit that I haven't fully got my head around their
specifications... 

Any thoughts anyone?

Chris

-- 
Chris Croome                               <chris@...>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   
everything else                               http://chris.croome.net/  






-----------------------------------------------------------------------------------
Post ID:1343
Sender:Dan Brickley <danbri@...>
Post Date/Time:2002-05-27 14:13:57
Subject:Re: [rest-discuss] Open Archives Initiative
Message:

On Mon, 27 May 2002, Chris Croome wrote:

> Hi
>
> Has anyone on this list taken a look at the OAI stuff?
>
>   http://www.openarchives.org/

Last I looked, and last I talked to Carl Lagoze about this, they weren't
using HTTP content-negotiation where they probably could/should've.

imho etc :)

Dan


-- 
mailto:danbri@...
http://www.w3.org/People/DanBri/







-----------------------------------------------------------------------------------
Post ID:1344
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-27 15:47:35
Subject:Re: [rest-discuss] Open Archives Initiative
Message:

On Mon, May 27, 2002 at 10:09:08AM -0400, Chris Croome wrote:
> Hi
> 
> Has anyone on this list taken a look at the OAI stuff?
> 
>   http://www.openarchives.org/

A quick look shows a "verb" attribute used in their URI, intended to
perform some operation.  Not a good sign.  The verbs there seem
safe, but they'll likely have problems in the future with URI
evolution, if they continue to think of a URI parameter as an API.
Also, what about when they make that information mutable, and
instead of GetRecord, they want to SetRecord?  Presumably a new URI
would be required, rather than using PUT.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1345
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-05-28 02:46:24
Subject:FW: [rest-discuss] The evolution of REST
Message:

------ Forwarded Message
From: Jeff Bone <jbone@...>
Date: Mon, 27 May 2002 21:30:33 -0500
To: Paul Prescod <paul@...>
Subject: Re: [rest-discuss] The evolution of REST

On 5/24/02 5:27 PM, "Paul Prescod" <paul@...> wrote:

> I personally have found the "addressing" argument much more
> persuasive and easy to understand, so that is MY focus, even though it
> is not, er, addressed on the front of the Wiki.

Everybody does, er, realize that the front page of the Wiki is open to
change to reflect current consensus (or even personal opinion) at any time,
by any person, without previous authorization or even discussion?  That's
the point of Wiki!  Out of courtesy, it's probably not a good idea to enact
gross changes without some discussion, but otherwise...

I'm amenable to a change to reflect primary emphasis on addressability.  I
would simply ask that the rather stellar (ahem! ;-) quote that's cited from
THE c2 wiki just be shoved further down page. (Grinz --- love being quoted,
dont want to lose those somewhat-insightful words. :-)

> 
> Also, I have long been concerned that the focus on a "small set of
> verbs" misses the point that it is not the small set that is central but
> rather their generality and commonality. Four, six, ten, fifty. It
> doesn't matter much as long as they are general.

Actually, I *do* believe this number is critically important.  That number
is an exponential factor, not a multiplicative constant, in determining the
compositional complexity of any software system.  At some point --- maybe,
modulo more commercial concerns --- I may trot out the mathematical argument
here.  But I think this is the under-recognized and supremely important
aspect of the meta-theory behind REST:  the "width" and variety of
interfaces has a direct and geometric impact on the overall complexity of
systems that use those interfaces...

> Let's be more explicit, we are pushing complexity around and hopefully
> reducing it but not competely changing its order notation.

This argument is no more and no less compelling and authoritative than its
contrary --- it relies on an intuitive, unsupported, and potentially
"superstitious" notion that there is some canonically meaningful notion of
complexity that is static across all formulations.  An even simpler notion
of complexity --- lines of code --- may in fact be canonically meaningful
but is *certainly* not static across all formulations; and the argument for
reduction of compositional complexity via interface minimization relies on
just that notion.

Jb



------ End of Forwarded Message







-----------------------------------------------------------------------------------
Post ID:1346
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-05-28 02:47:16
Subject:Re: [rest-discuss] REST-OO?
Message:

On 5/26/02 10:17 PM, "Mark Baker" <distobj@...> wrote:

> Wow, awesome post.  I too agree that the OO nature of REST is quite
> interesting.  A REST component basically does all the things you'd
> expect of an object; has identity, encapsulated behaviour, supports
> inheritance through a type system such as RDF.  Generic interfaces
> are also a feature of component based OO systems, such as Java Beans.
> The only thing REST doesn't do from an OO POV is hide data.

IMO, the problem -w- REST v. OOP is identical to the problem which has long
plagued me [1] -w- OOP v. generative communication ala Linda.  This is not
to say that REST and generative communication are identical or directly
analogous, but IMO they bear many interesting similarities...

Jb

[1] 
http://groups.google.com/groups?q=linda+oop+jguy&hl=en&lr=&selm=1220%40jethr
o.Corp.Sun.COM&rnum=1








-----------------------------------------------------------------------------------
Post ID:1347
Sender:Dan Brickley <danbri@...>
Post Date/Time:2002-05-28 04:58:29
Subject:Re: [rest-discuss] REST-OO?
Message:

On Mon, 27 May 2002, Jeff Bone wrote:

> On 5/26/02 10:17 PM, "Mark Baker" <distobj@...> wrote:
>
> > Wow, awesome post.  I too agree that the OO nature of REST is quite
> > interesting.  A REST component basically does all the things you'd
> > expect of an object; has identity, encapsulated behaviour, supports
> > inheritance through a type system such as RDF.  Generic interfaces
> > are also a feature of component based OO systems, such as Java Beans.
> > The only thing REST doesn't do from an OO POV is hide data.
>
> IMO, the problem -w- REST v. OOP is identical to the problem which has long
> plagued me [1] -w- OOP v. generative communication ala Linda.  This is not
> to say that REST and generative communication are identical or directly
> analogous, but IMO they bear many interesting similarities...

Yes, I came to this view too... various links hoarded in...

http://lists.w3.org/Archives/Public/xml-dist-app/2000Mar/0055.html

BTW I ran into an old WWW4 paper on WWW Meets Linda that was quite
interesting, http://www.w3.org/Conferences/WWW4/Papers/174/ and based
around actual implementation (a Perl Linda).

Dan

>
> Jb
>
> [1]
> http://groups.google.com/groups?q=linda+oop+jguy&hl=en&lr=&selm=1220%40jethr
> o.Corp.Sun.COM&rnum=1







-----------------------------------------------------------------------------------
Post ID:1348
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-05-28 08:39:59
Subject:RE: [rest-discuss] REST-OO? (URIs as passing by reference)
Message:

Mark, I hadn't thought of RDF as a type of inheritance, but that is a neat
idea.  In essence, it is a bit like defining a base class or a virtual
class.  Regarding the hiding of data in OOP, I actually think even that has
similarities, per below.

Dan, Jeff, I can definitely see the similarities in the discussion between
OOP vs. REST and OOP vs. generative communication ala Linda.  However, let
me try to reframe this discussion.

I've always viewed objects in OOP as both data and active agent.  That is
why I really see such commonality between URIs and objects.  URI's are
resources, not necessarily data.  Treating all URIs as data is certainly
useful, but so is treating them as active agents.

Thus, I don't actually think OOP itself encourages hiding of data per se,
rather that is an artifact of distributed object systems like CORBA or
SOAP-RPC.  In OOP systems such as C++, the result of a call returns objects
which are fully addressable.  This is not so in CORBA or SOAP-RPC since the
results are not addressable objects, but pure data that fall completely
outside of the namespace.

Historically, one of the biggest issues of distributed programming is that
it is difficult to pass by reference.  Thus, you have to pass the entire
data from one addressing space to another (thus RPCs).  If we think of the
URI naming system as an universal addressing space - we are in essence
creating the ability to pass by reference - isn't that what a link is, after
all?

It should be possible to build a full-blown distributed OOP system that is
based on the internet URI addressing space.  Issues like object persistence
and cost of access will need to be resolved, but I don't think there are
insurmountable obstacles.  I believe the resulting system would be not only
RESTful, but present a more familiar model of programming for developers.

//Joe

-----Original Message-----
From: Dan Brickley [mailto:danbri@...]
Sent: Monday, May 27, 2002 9:58 PM
To: Jeff Bone
Cc: Mark Baker; rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] REST-OO?


On Mon, 27 May 2002, Jeff Bone wrote:

> On 5/26/02 10:17 PM, "Mark Baker" <distobj@...> wrote:
>
> > Wow, awesome post.  I too agree that the OO nature of REST is quite
> > interesting.  A REST component basically does all the things you'd
> > expect of an object; has identity, encapsulated behaviour, supports
> > inheritance through a type system such as RDF.  Generic interfaces
> > are also a feature of component based OO systems, such as Java Beans.
> > The only thing REST doesn't do from an OO POV is hide data.
>
> IMO, the problem -w- REST v. OOP is identical to the problem which has
long
> plagued me [1] -w- OOP v. generative communication ala Linda.  This is not
> to say that REST and generative communication are identical or directly
> analogous, but IMO they bear many interesting similarities...

Yes, I came to this view too... various links hoarded in...

http://lists.w3.org/Archives/Public/xml-dist-app/2000Mar/0055.html

BTW I ran into an old WWW4 paper on WWW Meets Linda that was quite
interesting, http://www.w3.org/Conferences/WWW4/Papers/174/ and based
around actual implementation (a Perl Linda).

Dan

>
> Jb
>
> [1]
>
http://groups.google.com/groups?q=linda+oop+jguy&hl=en&lr=&selm=1220%40jethr
> o.Corp.Sun.COM&rnum=1


Yahoo! Groups Sponsor
ADVERTISEMENT




To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1349
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-28 12:05:59
Subject:Re: [PMX:#] [rest-discuss] State Machine As Hypertext
Message:

I worked on a set of related Rest-Wiki pages over the weekend:
http://internet.conveyor.com/RESTwiki/moin.cgi/StateMachineAsHypertext
http://internet.conveyor.com/RESTwiki/moin.cgi/RestifiedPurchasing
http://internet.conveyor.com/RESTwiki/moin.cgi/PurchasingBusinessRequi
rements

Topics include the subject of this message, plus:
* Sessions
* Transactions
* Purchasing
* Travel arrangements

We've discussed all of these topics several times on this list, but 
the advantage of the Wiki is to give the topics an identity and 
converge all the ideas into one set of resources.  So for example 
when "purchase orders" come up again, as they did last week, there is 
a reference available.

The pages are by no means complete. Purchasing is fleshed out a lot 
more than any of the others.  Paul indicated he was working on 
sessions, so I left that part completely blank.

But I am personally going to give it a rest for a while and see if 
anybody else think it's useful enough to contribute.

It's a wiki, so feel free to edit.  I'm sure I missed something and 
screwed up something else.

Have fun,
Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1350
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-05-28 13:00:33
Subject:RE: [rest-discuss] The evolution of REST
Message:

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> -----Original Message-----
> From: Jeff Bone [mailto:jbone@...] 
>
> On 5/24/02 5:27 PM, "Paul Prescod" <paul@...> wrote:
>
> > 
> > Also, I have long been concerned that the focus on a "small set
> > of  verbs" misses the point that it is not the small set that 
> is central 
> > but rather their generality and commonality. Four, six, 
> ten, fifty. It 
> > doesn't matter much as long as they are general.
> 
> Actually, I *do* believe this number is critically important. 
>  That number is an exponential factor, not a multiplicative 
> constant, in determining the compositional complexity of any 
> software system.  At some point --- maybe, modulo more 
> commercial concerns --- I may trot out the mathematical 
> argument here.  But I think this is the under-recognized and 
> supremely important aspect of the meta-theory behind REST:  
> the "width" and variety of interfaces has a direct and 
> geometric impact on the overall complexity of systems that 
> use those interfaces...

All this assumes that verb count at least correlates with managing
complexity if not actually reducing it.

In the not unrelated world of speech act theory, the prevalent view
seems to be that there is no natural restriction on performatives
(verb) count; as soon as we've written down all the ones we think
we need, we're done. The main thing is to clearly define what those
verbs mean. I haven't seem arguments against extending the verb set
over time. The original KQML took some flack, not dissimilar to
that of RDF's by logicians, for having imprecisely defined verbs.
FIPA-ACL attempts to address this by having clear semantics for its
verbs (and one assumes then, shared behaviours). There are quite a
few verbs in KQML and FIPA-ACL. I imagine there is an assumption
that if the verb set is well grounded, the meaning and intention of
new verbs can be inferred, not unlike the assumptions surrounding
RDF and semantic web entities. That's a different kind of software
than is written in the middleware trenches today. Contrast this
with the RPC extension mechanism, the procedure, which is the
ad-hoc addition of new verbs. 

Bill de hra

 

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPPN/W+aWiFwg2CH4EQLcEgCg6XlQrMltwf2Ar3+H4qyEUbr3uP4AoJFc
kFoKLnH1kVNpl5Iaz9SHBFRe
=IZVq
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:1351
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-05-28 14:18:08
Subject:Re: [rest-discuss] Enabling the evolution of the Web using REST
Message:

Dan Brickley wrote:

> This is interesting. I'm working w/ Max (cc:'d) on showing SOAP Encoding
> XSLT'd into RDF, and queried and stored using RDF tools. And *merged*,
> which is imho the interesting thing. Taking SOAP Encoded msgs from
> multiple sources and merging them into a single store, so that queries
> that need both info-sources to be answered can be serviced.
>

I forwarded Dan's message to the woman whom I quoted earlier.  Here's her
response:

"Yeah, you can turn soap into rdf and do the merging thing, but I guess what
I don't see is how soap is better than daml-s for describing and manipulating
complex services.   Maybe I haven't looked at soap closely enough, but I've
never seen examples with it that can express conditional inputs and outputs,
ordering and dependencies of subprocesses, etc that you can do in daml-s.
And if it's just a straight, simple  information producing service, then you
don't necessarily need either one [if you're not concerned with being
automatically brokered]"

/Roger








-----------------------------------------------------------------------------------
Post ID:1352
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-05-28 17:42:31
Subject:REST/SOAP Web Service for Astronomical Data
Message:

FYI:  A web site illustrating the SOAP and REST styles for querying
astronomical data.

http://www.orbitarium.com/soap.html
http://www.orbitarium.com/rest.html

Example REST URL to get geocentruc position information about Mars::

http://www.orbitarium.com/orbitarium/servlet/ows/?method=getGeocentricPosition&planet=Mars

/Roger









-----------------------------------------------------------------------------------
Post ID:1353
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-28 18:06:08
Subject:Re: [rest-discuss] REST/SOAP Web Service for Astronomical Data
Message:

On Tue, May 28, 2002 at 01:42:31PM -0400, Roger L. Costello wrote:
> FYI:  A web site illustrating the SOAP and REST styles for querying
> astronomical data.
> 
> http://www.orbitarium.com/soap.html
> http://www.orbitarium.com/rest.html
> 
> Example REST URL to get geocentruc position information about Mars::
> 
> http://www.orbitarium.com/orbitarium/servlet/ows/?method=getGeocentricPo
> sition&planet=Mars

Interesting.  That URI structure has problems though; try building an
HTML form to use the REST/GET based service.  You can't, cleanly;
you'd have to use a hidden form field called "method".

Best just to have a URI like this;

http://www.orbitarium.com/geocentricPosition?planet=Mars

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1354
Sender:Allan Doyle <adoyle@...>
Post Date/Time:2002-05-28 18:24:41
Subject:Re: [rest-discuss] REST/SOAP Web Service for Astronomical Data
Message:

On Tuesday 2002-05-28 at 14:06:08(-0400) Mark Baker wrote:
 > On Tue, May 28, 2002 at 01:42:31PM -0400, Roger L. Costello wrote:
 > > FYI:  A web site illustrating the SOAP and REST styles for querying
 > > astronomical data.
 > > 
 > > http://www.orbitarium.com/soap.html
 > > http://www.orbitarium.com/rest.html
 > > 
 > > Example REST URL to get geocentruc position information about Mars::
 > > 
 > > http://www.orbitarium.com/orbitarium/servlet/ows/?method=getGeocentricPo
 > > sition&planet=Mars
 > 
 > Interesting.  That URI structure has problems though; try building an
 > HTML form to use the REST/GET based service.  You can't, cleanly;
 > you'd have to use a hidden form field called "method".
 > 
 > Best just to have a URI like this;
 > 
 > http://www.orbitarium.com/geocentricPosition?planet=Mars

Or how about
  http://www.orbitarium.com/mars/geocentricPosition
  http://www.orbitarium.com/mars/heliocentricPosition
     ...
  http://www.orbitarium.com/mercury/geocentricPosition
  http://www.orbitarium.com/mercury/heliocentricPosition

with 
  http://www.orbitarium.com/mars/geocentricPosition/julianDate?2452321.0
  http://www.orbitarium.com/mars/heliocentricPosition/julianDate?2452321.0
     ...

and having all these linked from a top level page:
  http://www.orbitarium.com
    Mercury: Geocentric Position, Heliocentric Position...
    Venus  : Geocentric Position, Heliocentric Position...
    Earth  :                      Heliocentric Position...
    Mars   : Geocentric Position, Heliocentric Position...
     ...

Much of the benefit of REST is that resource documents are
findable via link traversal, meaning that there's an entry point that
provides a way to navigate to the greatest level of detail/information
possible. If Google picks up the top level, you will be able to do a
search on "mars geocentric position" and find the document with the
current position instantly.

Furthermore, if you include decent documentation in the XML responses,
then you increase your chances of it being found in a search.

Also, to complete the job, you probably want to indicate to the http
servers (httpd, squid, akamai, etc.) that the pages with "current"
position are not to be cached, but pages with an absolute time can be
cached.

Content negotiation can be used to provide the same info in various
languages or return formats.

I think the way to approach a REST design is to decide how to set up a
document hierarchy that conveys the most information without having to
resort to parameters to pass arguments.

  Allan


 > 
 > MB
 > -- 
 > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
 > Ottawa, Ontario, CANADA.               distobj@...
 > http://www.markbaker.ca        http://www.idokorro.com
 > 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle                         http://www.intl-interfaces.com
adoyle@...







-----------------------------------------------------------------------------------
Post ID:1355
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-05-28 19:34:38
Subject:Re: [rest-discuss] REST-OO? (URIs as passing by reference)
Message:

On Tue, May 28, 2002 at 04:39:59AM -0400, Joe Hsy wrote:
> It should be possible to build a full-blown distributed OOP system that
> is
> based on the internet URI addressing space.

How do you see this being any different than the Web?

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1356
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-05-28 23:52:21
Subject:RE: [rest-discuss] REST-OO for the Orbitarium
Message:

Hi Mark,

I was not thinking different from the web, but building on the web.  As we
talked about, there are already many attributes the current web and the REST
architecture that can be seen as object-oriented.  But much of it is not
explicitly laid out and there are also some OO concepts that could use some
additional support tools.

I guess by full-blown, I meant fleshing it out from the current base set and
to create tools for current OOP programmers to be able to program for the
web using a familiar development environment.

Let me use the recently discussed orbitarium example (with the URI
variations suggested by you and Allan Doyle) and see how a standard java
programmer may want to access and manipulate such a resource:

Assuming there is an RDF description of the orbitarium which describes the
orbitarium:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:o="http://www.orbitarium.com/planets/vocab#">

   <rdf:Description rdf:about="http://www.orbitarium.com/about">
      <o:planets>
         <rdf:Seq>
            <rdf:li
rdf:resource="http://www.orbitarium.com/planets/Mercury"/>
            <rdf:li rdf:resource="http://www.orbitarium.com/planets/Venus"/>
            <rdf:li rdf:resource="http://www.orbitarium.com/planets/Mars"/>
         </rdf:Seq>
      </o:planets>
   </rdf:Description>
</rdf:RDF>

Ignoring that earth is the 3rd planet, it would nice to have a tool that
reads the RDF and instantiates an orbitarium object and the 3 planets
objects which map directly to these resources.  As an example, the class
definition generated for the orbitarium could be something like this:

class Orbitarium {
  String about;
  Vector planets;
}

class Planet {
  String resource;

  Float GetGeocentricPosition() {
    return GET(resource+"/GeocentricPosition");
  }

  Float GetHeliocentricPosition() {
    return GET(resource+"/HeliocentricPosition");
  }
}

Note that these objects are in essence "references" to the source objects.
There are probably some way to make these types of URI references a real
reference type in the program's addressing space, but that isn't necessary
to make this work.

I can now write a display program that can plot the planet orbits over time
using the existing programming methodologies, despite the fact that the
source of the data is sitting somewhere else on the web.

And if I create the charts in SVG, it would be great if I have a tool that
takes my planet chart object and publish it by generating an RDF file.  And
in fact I can include in my publishing call the original planet objects
(assuming proper publishing rights are observed):

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:j="http://www.joesorbitarium.com/planets/vocab#"
         xmlns:o="http://www.orbitarium.com/planets/vocab#">

   <rdf:Description rdf:about="http://www.joesorbitarium.com/about">
      <j:planetcharts>
         <rdf:Seq>
            <rdf:li
rdf:resource="http://www.joesorbitarium.com/planetscharts/Mercury"/>
            <rdf:li
rdf:resource="http://www.joesorbitarium.com/planetscharts/Venus"/>
            <rdf:li
rdf:resource="http://www.joesorbitarium.com/planetscharts/Mars"/>
         </rdf:Seq>
      </j:planetcharts>
      <o:planets>
         <rdf:Seq>
            <rdf:li
rdf:resource="http://www.orbitarium.com/planets/Mercury"/>
            <rdf:li rdf:resource="http://www.orbitarium.com/planets/Venus"/>
            <rdf:li rdf:resource="http://www.orbitarium.com/planets/Mars"/>
         </rdf:Seq>
      </o:planets>
   </rdf:Description>
</rdf:RDF>


I'm not an RDF expert, so forgive me if some of this is not proper usage.
But, my main point is that one of the reasons SOAP was getting momentum is
that it presents a familiar programming model.  I think we can do the same
with REST by presenting not an RPC model, but a OOP model for building
RESTful applications.

//Joe

-----Original Message-----
From: Mark Baker [mailto:distobj@...]
Sent: Tuesday, May 28, 2002 12:35 PM
To: Joe Hsy
Cc: rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] REST-OO? (URIs as passing by reference)


On Tue, May 28, 2002 at 04:39:59AM -0400, Joe Hsy wrote:
> It should be possible to build a full-blown distributed OOP system that
> is
> based on the internet URI addressing space.

How do you see this being any different than the Web?

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1357
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-29 05:44:53
Subject:Re: [rest-discuss] The evolution of REST
Message:

> ----- Original Message -----
> From: "Jeff Bone" <jbone@...>

> Everybody does, er, realize that the front page of the Wiki is open to
> change to reflect current consensus (or even personal opinion) at any
time,
> by any person, without previous authorization or even discussion?

I've been thinking that the front page needs a more direct summary of REST
as well as a clarification of REST .vs. resource modeling. I see the term
REST used where a more narrow term would be better - I like 'resource
modeling' for that.

Here is my suggestion of a direct summary of REST and an explanation that
the 'information architecture' aspect is mainly what people are talking
about.

Comments welcome...

-- mike's summary --
REST is an architectural style for building large-scale networked
applications. It is a description of the facets of the WWW that made the Web
so successful.
REST describes a networked system in terms of
 - data elements (resource, resource identifier, representation)
 - connectors (client, server, cache, resolver, tunnel)
 - components (server, gateway, proxy, user agent)

Data elements are accessed through a standardized interface. Components
communicate by transferring representations of resources through this
interface rather than operating directly upon the resource itself.
Connectors present an abstract interface for component communication, hiding
the implementation details of communication mechanisms.
Components use connectors to access, provide access or mediate access to
resources.
It is important that intermediaries are an explicit aspect of the
architecture.

Since REST is an extracted description of the WWW, it is no suprise that the
protocol that exhibits the most number of these aspects is HTTP. However,
REST and HTTP are separate concepts - it is entirely possible to apply REST
concepts to other protocols and systems.

Since most people see the immediate value of components and connectors, most
discussion has been focused on the 'information architecture' aspects of
REST - resources, representations, URIs, standardized interfaces, etc. This
area is informally known as 'resource modeling'. Most examples are framed in
HTTP messages and URI addressable resources. The theory is that many complex
systems can be fully described and implemented with just pure HTTP.

--








-----------------------------------------------------------------------------------
Post ID:1358
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-05-29 12:46:27
Subject:REST and travel agents revisited
Message:

Bob's adding of the travel agent scenario to the 'State machine as hypertext' wiki page along with the comment 'No attempts to RESTify this example have been reported' prompted me to try out my REST skills - be warned, the training wheels are still on:-)

The resources modelled are similar to those identified in the original document:

TripIdentifier
    Participants
        Participant1
        Participant2
        ....
        ParticipantN
    Journey
        Stage1
        Stage2
        ....
        StageN

A full uri could be http://www.mytravel.com/person_identifier/trips/planned/JulyHoliday for a planned but not yet requested (i.e. a sandbox) and http://www.mytravel.com/person_identifier/trips/requested/XML2002 for a started but not yet fully authorized trip (i.e. tickets issued) and http://www.mytravel.com/person_identifier/trips/issued/XML2001 for a trip whose tickets have been issued. 

The traveller could play in his sandbox to his hearts content, adding participants in the REST manner (i.e. doing a POST to /JulyHoliday/Particpants to get a uri for a new participant - /JulyHoliday/Particpants/ParticipantN and then performing a PUT to that uri using the appropriate participant representation [an XML structure containing first-name, last-name, address and birthdate, where an address consists of a street, city, state, zip, email and phone]) and deleting participants by using an http DELETE. Similarly, the requisite stages could be added as required.

Once completed, the traveller could request the trip be organized , which could be done by the a POST/PUT combination to /requested/HulyHoliday/ using the composite xml structure obtained from a GET to /planned/JulyHoliday/ (note that optionally the planned version could be preserved, otherwise it is deleted via http DELETE - what about integrity issues here, i.e. the DELETE failing?)

Now it gets interesting - how does the travel agent know that a new trip has been requested and start the ball rolling? One way would be to have a resource /trips/requested/new which the individual travel agents subscribe to using the techniques described in HttpEvents. When a new trip is requested a notification containing the new trip uri  is sent to all the subscribers. The difficulty with this approach is that in the case of multiple travel agents, how is the new trip assigned to one and only one agent and how are all the other agents notified that the trip is now assigned to an agent and is no longer available?

Once an agent accepts responsibility for a trip, they will add the requisite legs to the trip using POST/PUT to the uri /requested/JulyHoliday/legs/planned/ ending up with a uri /requested/JulyHoliday/legs/planned/leg1..n and once this is completed the agent could request the specified legs by moving them to the /requested/JulyHoliday/legs/requested/ uri. The airline could be notified of the requested legs (HttpEvents via email?) and it could POST to /requested/JulyHoliday/legs/confirmed/leg1...n with the relevant seat information, etc as each leg is confirmed. (Hmm... what happens to /legs/requested/...?).

It's getting late and my brain is shutting down. I hope this makes sense to someone else and can be used as the basis for a discussion.

Robert







-----------------------------------------------------------------------------------
Post ID:1359
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-29 15:17:07
Subject:Re: REST and travel agents revisited
Message:

Robert, 

I'm swamped today, but will study your article and follow the 
feedback as I get time.

But when you think it a coherent story has emerged, please consider 
publishing it on the Wiki.  Maybe spin a new page off the section 
that is sort of begging for a RESTification?

Or even before it's coherent.  Wikis are good for group-annealing of 
documents.  Maybe the mailing list is better for discussion, I don't 
know.

And maybe if the Wiki pages get really good, some of us can put 
together an article for one of the Web mags, cleaning up the best of 
the Wiki content.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1360
Sender:"Gary Michaels" <panasync32@...>
Post Date/Time:2002-05-29 22:55:19
Subject:Targeted Sales Leads
Message:

I noticed your email address on a list serve related to technology and web development. Our company has developed a simple, risk-free and cost effective method of generating leads and creating awareness for your Company through targeted email marketing. Please read on to find out more about this awesome service.


The process:  

 

You provide us with keywords pertaining to your company's target market. 
Using our proprietary spider software, we spider the Internet searching for email addresses that are on pages that match those keywords.
We setup a database driven form, which allows the prospect to input their contact, company, and any other relative information that you may require. 
We send emails to the addresses collected. These emails do not contain your companys name, so that your company is protected. 
Once the prospect has filled out and submitted their information, the data is automatically written to a database. 
You may then login to our web driven application and view the current leads that have been submitted. 

Results:

 

We typically provide our clients with anywhere from 30  200 leads per week with our standard package depending on: 

Target market
Keywords used 
Product pricing 

We will help develop a customized system for your company that will ensure maximum return.

 

Pricing:

 

Our standard package includes the following:

 

HTML email design and implementation 
Form and database setup 
Over 100,000 emails distributed per month (done on a weekly basis)
Email address collection and filtering 

Cost: $775 per Month - Our standard pricing is $1500 per month, but if you order before June 6th 2002 we will do it for this low price as long as you are our customer.

 

The above price is all-inclusive, and no other charges will be incurred. We can also provide higher quantities of distribution if required. Please contact us for details.

 

If you would like more information on our services or would like to get started please click here


Cordially,

Gary Michaels





-----------------------------------------------------------------------------------
Post ID:1361
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-05-29 21:15:28
Subject:Re: [rest-discuss] Re: REST and travel agents revisited
Message:

At 01:17 AM 30/05/2002, bhaugen32 wrote:

>But when you think it a coherent story has emerged, please consider 
>publishing it on the Wiki.  Maybe spin a new page off the section 
>that is sort of begging for a RESTification?

That was the plan.


>Or even before it's coherent.  Wikis are good for group-annealing of 
>documents.  Maybe the mailing list is better for discussion, I don't 
>know.

I feel that the mailing list is better for discussion and I wanted to make sure it is a valid starting point/direction before putting it on the wiki. If we can knock off the really rough edges (or, to continue the analogy,  start with a new piece of wood if it is not the right colour/size/quality/etc) then the wiki can/may help finish it off.


>And maybe if the Wiki pages get really good, some of us can put 
>together an article for one of the Web mags, cleaning up the best of 
>the Wiki content.

Sounds like an excellent idea.

Robert







-----------------------------------------------------------------------------------
Post ID:1362
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-30 05:58:01
Subject:Fw: [rest-discuss] The evolution of REST
Message:

I added some new pages to the Wiki.

http://internet.conveyor.com/RESTwiki/moin.cgi/ShortSummaryOfRest
http://internet.conveyor.com/RESTwiki/moin.cgi/AccessThroughRepresentations

Comments and corrections welcome.






-----------------------------------------------------------------------------------
Post ID:1363
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-30 11:53:06
Subject:Re: Fw: [rest-discuss] The evolution of REST
Message:

"S. Mike Dierken" wrote:
> I added some new pages to the Wiki.
> 
> http://internet.conveyor.com/RESTwiki/moin.cgi/ShortSummaryOfRest
> 
http://internet.conveyor.com/RESTwiki/moin.cgi/AccessThroughRepresenta
tions
> 
> Comments and corrections welcome.

Mike, thank you very much! Both of the above are necessary and 
important.

Assuming you want to use rest-discuss for quibbles, here's one:
>REST describes a networked system in terms of 
>   data elements (resource, resource identifier, representation) 

I don't think "data element" is an accurate description of a 
resource. I think resources are much more like large-grained very 
generic objects in that they have methods and identity.  Even the 
representation does not need to be limited to "just data" (unless we 
consider everything to be "just data").

Maybe "object" is not the correct word, either, but it's closer 
than "data element".

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1364
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-30 17:51:46
Subject:Re: Fw: [rest-discuss] The evolution of REST
Message:

> ----- Original Message -----
> From: "bhaugen32" <bhaugen32@...>

> Assuming you want to use rest-discuss for quibbles, here's one:
> >REST describes a networked system in terms of
> >   data elements (resource, resource identifier, representation)

> I don't think "data element" is an accurate description of a
> resource. I think resources are much more like large-grained very
> generic objects in that they have methods and identity.  Even the
> representation does not need to be limited to "just data" (unless we
> consider everything to be "just data").

I used 'data element' because that was the term from Roy's dissertation.
I think 'data element' is a category of features of a networked
architecture - as compared with message flow or processing units/components
or whatever.
I would like to clear up the ambiguity though - how about:

"The REST documents describe networked systems in terms of three
architectural concepts: data elements, components and connectors.
Specifically, REST uses these instances of the concepts:
 data elements : resource, resource identifier, representation
 (etc...)
"







-----------------------------------------------------------------------------------
Post ID:1365
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-30 18:26:01
Subject:Re: Fw: [rest-discuss] The evolution of REST
Message:

"S. Mike Dierken" wrote:
> 
> > ----- Original Message -----
> > From: "bhaugen32" <bhaugen32@y...>
> 
> > Assuming you want to use rest-discuss for quibbles, here's one:
> > >REST describes a networked system in terms of
> > >   data elements (resource, resource identifier, representation)
> 
> > I don't think "data element" is an accurate description of a
> > resource. I think resources are much more like large-grained very
> > generic objects in that they have methods and identity.  Even the
> > representation does not need to be limited to "just data" (unless 
we
> > consider everything to be "just data").
> 
> I used 'data element' because that was the term from Roy's 
dissertation.
> I think 'data element' is a category of features of a networked
> architecture - as compared with message flow or processing 
units/components
> or whatever.

Ok, I re-examined the dissertation and see where you got "resource = 
data element".  Table 5-1, right?

So who am I to say different?  Still don't make any sense to me, 
especially if I read the next paragraph of the dissertation:

"5.2.1.1 Resources and Resource Identifiers
The key abstraction of information in REST is a resource. Any 
information that can be named can be a resource: a document or image, 
a temporal service (e.g. "today's weather in Los Angeles"), a 
collection of other resources, a non-virtual object (e.g. a person), 
and so on. In other words, any concept that might be the target of an 
author's hypertext reference must fit within the definition of a 
resource. A resource is a conceptual mapping to a set of entities, 
not the entity that corresponds to the mapping at any particular 
point in time.

More precisely, a resource R is a temporally varying membership 
function MR(t), which for time t maps to a set of entities, or 
values, which are equivalent."

Doesn't smell like a data element to me.  But I suppose the cat is 
out of the bag, huh?

> I would like to clear up the ambiguity though - how about:
> 
> "The REST documents describe networked systems in terms of three
> architectural concepts: data elements, components and connectors.
> Specifically, REST uses these instances of the concepts:
>  data elements : resource, resource identifier, representation
>  (etc...)

Doesn't resolve the problem in my mind, which is that resources are 
different kinds of things from representations.

I'll withdraw my objection, though, since I am but a pup amongst the 
big dogs on this corner...







-----------------------------------------------------------------------------------
Post ID:1366
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-05-31 04:17:07
Subject:Re: Fw: [rest-discuss] The evolution of REST
Message:

----- Original Message -----
From: "bhaugen32" <bhaugen32@...>

> Doesn't resolve the problem in my mind, which is that resources are
> different kinds of things from representations.
They are different - but they are 'data' concepts, as opposed to 'procedural
coding library' concept.
You can look at REST in different ways - in terms of its static data
aspects, in terms of layers and APIs, in terms of logic elements, etc.

> I'll withdraw my objection, though, since I am but a pup amongst the
> big dogs on this corner...
Don't do that... we need fresh meat all the time ;)








-----------------------------------------------------------------------------------
Post ID:1367
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-05-31 12:03:21
Subject:HYPERMEDIA SYSTEMS SERVE AS MODEL FOR SEMANTIC WEB
Message:

Seems to me that REST fits right in with evolving the Web into a
Semantic Web.  /Roger

FYI, As seen in ShelfLife:
http://lists2.rlg.org/cgi-bin/lyris.pl?visit=shelflife-from-rlg&id=181277488
 > HYPERMEDIA SYSTEMS SERVE AS MODEL FOR SEMANTIC WEB

 > The evolution of the Semantic Web -- the ongoing project of
 > developing computer languages that depict information in a form that
 > both humans and machines can process -- could benefit from the
 > models, systems and lessons learned within the hypermedia community,
 > according to a trio of Dutch hypermedia researchers. In fact, say
 > Jacco van Ossenbruggen, Lynda Hardman and Lloyd Rutledge, the
 > primary model for many hypermedia systems is directly applicable to
 > the Semantic Web. Hypermedia systems are, basically, structured
 > databases (in various media -- audio, video, etc.) with pieces of
 > information (called nodes) and links to related pieces of
 > information.  These systems typically denote link access points or
 > link "anchors" in some manner within a node when it's displayed on a
 > computer screen, such as underlined text displayed within documents
 > on the Web. In order to annotate a specific portion of a Web
 > resource, it needs an anchoring mechanism, and to establish a
 > relationship between the annotation and the target resource, a
 > linking model is necessary. Such elements will be paramount in the
 > development of the Semantic Web, say the researchers. (Journal of
 > Digital Information 17 May 2002)
http://jodi.ecs.soton.ac.uk/Articles/v03/i01/VanOssenbruggen/







-----------------------------------------------------------------------------------
Post ID:1368
Sender:Dan Brickley <danbri@...>
Post Date/Time:2002-05-31 12:55:44
Subject:Re: [rest-discuss] HYPERMEDIA SYSTEMS SERVE AS MODEL FOR SEMANTIC WEB
Message:

On Fri, 31 May 2002, Roger L. Costello wrote:

> Seems to me that REST fits right in with evolving the Web into a
> Semantic Web.  /Roger

Absolutely!

BTW that URL doesn't work for me. Aha, you meant
http://jodi.ecs.soton.ac.uk/Articles/v03/i01/VanOssenbruggen/
not the rlg.org one.

The RDF model is a natural extension of the typed links approach in
hypermedia. This was clear right from TimBL's original proposal for the
creation of the Web (wonder why it's taken us so long...).

I've a half-finished bunch of notes on this at
http://www.w3.org/1999/11/11-WWWProposal/thenandnow (2.5 yrs old!), or go
straight to the original...
			http://www.w3.org/History/1989/proposal.html

Dan

> FYI, As seen in ShelfLife:
> http://lists2.rlg.org/cgi-bin/lyris.pl?visit=shelflife-from-rlg&id=181277488
>  > HYPERMEDIA SYSTEMS SERVE AS MODEL FOR SEMANTIC WEB
>
>  > The evolution of the Semantic Web -- the ongoing project of
>  > developing computer languages that depict information in a form that
>  > both humans and machines can process -- could benefit from the
>  > models, systems and lessons learned within the hypermedia community,
>  > according to a trio of Dutch hypermedia researchers. In fact, say
>  > Jacco van Ossenbruggen, Lynda Hardman and Lloyd Rutledge, the
>  > primary model for many hypermedia systems is directly applicable to
>  > the Semantic Web. Hypermedia systems are, basically, structured
>  > databases (in various media -- audio, video, etc.) with pieces of
>  > information (called nodes) and links to related pieces of
>  > information.  These systems typically denote link access points or
>  > link "anchors" in some manner within a node when it's displayed on a
>  > computer screen, such as underlined text displayed within documents
>  > on the Web. In order to annotate a specific portion of a Web
>  > resource, it needs an anchoring mechanism, and to establish a
>  > relationship between the annotation and the target resource, a
>  > linking model is necessary. Such elements will be paramount in the
>  > development of the Semantic Web, say the researchers. (Journal of
>  > Digital Information 17 May 2002)
> http://jodi.ecs.soton.ac.uk/Articles/v03/i01/VanOssenbruggen/
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:1369
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-05-31 15:35:24
Subject:Re: REST and travel agents revisited
Message:

I'm ready to try to take one more baby step in this conversation.
This baby step focuses on URI-per-entity vs URI-per-state.

Robert Leftwich wrote:
> The resources modelled are similar to those identified in the 
original document:
> 
> TripIdentifier
>     Participants
>         Participant1
>         Participant2
>         ....
>         ParticipantN
>     Journey
>         Stage1
>         Stage2
>         ....
>         StageN
> 
> A full uri could be 
> http://www.mytravel.com/person_identifier/trips/planned/JulyHoliday 
> for a planned but not yet requested (i.e. a sandbox) and 
> http://www.mytravel.com/person_identifier/trips/requested/XML2002 
> for a started but not yet fully authorized trip 
> (i.e. tickets issued) and 
> http://www.mytravel.com/person_identifier/trips/issued/XML2001 
> for a trip whose tickets have been issued. 

I'm very skeptical of changing the URI of a business entity whenever 
it changes state.

I think the URI should be the permanent identity of the business 
entity and its state should be represented either by data elements or 
hyperlinks.

Paul Prescod and I have discussed this before; Paul may like having 
the URI change per state.  So don't necessarily take my word for this.

But I think increasingly business entities will be hyperlinked 
together.  The states of the business entities will be very 
important, but so are the hyperlinks.  What happens to the hyperlinks 
if the URIs change?

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:1370
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-06-01 00:23:25
Subject:Re: [rest-discuss] Re: REST and travel agents revisited
Message:

At 01:35 AM 1/06/2002, bhaugen32 wrote:

>Robert Leftwich wrote:
>> A full uri could be 
>> http://www.mytravel.com/person_identifier/trips/planned/JulyHoliday 
>> for a planned but not yet requested (i.e. a sandbox) and 
>> http://www.mytravel.com/person_identifier/trips/requested/XML2002 
>> for a started but not yet fully authorized trip 
>> (i.e. tickets issued) and 
>> http://www.mytravel.com/person_identifier/trips/issued/XML2001 
>> for a trip whose tickets have been issued. 
>
>I'm very skeptical of changing the URI of a business entity whenever 
>it changes state.

Could you perhaps use the concept of permalink (from the blogging world?) where there is a permanent link for the resource, but also alternative 'views' on the resources that are state-based? Something like:

permalinks - 

http://www.mytravel.com/person_identifier/trips/XML2001/
http://www.mytravel.com/person_identifier/trips/JulyHoliday/
...

alternative state-based 'views'

http://www.mytravel.com/person_identifier/trips/planned/
http://www.mytravel.com/person_identifier/trips/issued/
...

alternative views would return collections of resources that match the view, using the permalinks i.e. http://www.mytravel.com/person_identifier/trips/planned/ would return :

<trips>
    <trip permalink='http://www.mytravel.com/person_identifier/trips/Xmas2002/' 
             link='http://www.mytravel.com/person_identifier/trips/panned/Xmas2002/' />
    <trip permalink='http://www.mytravel.com/person_identifier/trips/Easter2003/' 
             link='http://www.mytravel.com/person_identifier/trips/panned/Easter2003/' />
    ....
</trips>

Anyone using a state-based link to a trip that is no longer in that state would receive a 301 moved status code with the link to the current state.

You could still use the state-based uri to manipulate the state as mentioned in the OP.

Still, I feel a little uneasy about the existence of more than 1 URI for the same resource, but this happens all the time on the web and the 3xx status codes show that this behavior was identified and catered for.


>I think the URI should be the permanent identity of the business 
>entity and its state should be represented either by data elements or 
>hyperlinks.

Can you give an example of state being represented by hyperlinks?

Robert

PS Anyone else feel that email is definitely NOT the best medium for brainstorming ideas. It's hard to beat a bunch of people locked in a room to sort out a few things :-(







-----------------------------------------------------------------------------------
Post ID:1371
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-01 07:45:32
Subject:Re: [rest-discuss] REST and travel agents revisited
Message:

----- Original Message -----
From: "Robert Leftwich" <robert@...>


> Bob's adding of the travel agent scenario to the 'State machine as
hypertext' wiki page along with the comment 'No attempts to RESTify this
example have been reported' prompted me to try out my REST skills - be
warned, the training wheels are still on:-)
>
> The resources modelled are similar to those identified in the original
document:
>
> TripIdentifier
>     Participants
>         Participant1
>         Participant2
>         ....
>         ParticipantN
>     Journey
>         Stage1
>         Stage2
>         ....
>         StageN
>
If I'm reading this right, it sounds like you are making each item a full
resource.
To me, the data called out in the original document (appended at the end of
the message) don't necessarily need to be full URI resources.
I don't see the URIs, their structure or nesting as all that important.
In the nested text shown above, the Participant1 could be an independent
entity that is merely referenced by the trip, rather than being
'subordinate' to the trip resource.

Here's how I would do it:
The information types seem to be 'traveler', 'trip', 'stage', 'participant',
etc.
I'd start with a coarse-grained resource like 'trip' and expand out into
'traveler' or 'participant' if necessary.
Within, I'd have an XML blob with details and any useful links.

The resources I generated in walking through this are:
-- submit a new trip --
http://services.travelagents.com/trips/
-- new trip that was created --
http://services.travelagents.com/trips/0173/
-- callbacks for airline to confirm reservations --
http://services.travelagents.com/trips/0173/airline/ack/
http://services.travelagents.com/trips/0173/airline/status/
-- submit new reservations --
http://services.airliner.com/reservations/
-- new reservation that was created --
http://reservations.airliner.com/agents/travelagents.com/res-0029/

Note - the URIs do /not/ have to be related textually - the URI of the new
reservation at the airline is even on a different host for example. The
connection between all these is through HTTP headers, or they could also be
done via href's inside some XML.


-- step one --
The overall flow of this example is as follows: A traveler will plan her
trip
by specifying the various stages of his overall journey and all of its
participants. For each of the stages, the traveler specifies the location
that
she wants to visit as well as the date when she wants to begin and the date
when she wants to end the particular stay. When the traveler is finished
with
this, she sends this information together with the list of all participants
of
the trip as well as the information about the credit card to be charged for
the
ordered tickets to the travel agent.

== Create a new trip ===
POST http://services.travelagents.com/trips/ HTTP/1.1
Content-Type: text/xml
Content-Model: TripSpecification

<trip>
<stage>
 <location>maui</location>
 <start>immediately</start>
 <finish>never</finish>
</stage>
<participant>
 <name>Mike</name>
</participant>
<payment>VISA</payment>
<recipient>mdierken@...</recipient>
</trip>

== Acknowledgement of submission (with location of trip) ==
HTTP/1.1 202 Accepted
Location: http://services.travelagents.com/trips/0173/


-- step two --
The credit card information has been passed when the business process was
instantiated.
Next, the traveler will await the submission of the electronic tickets as
well as the final itinerary
for the trip.

-- step three --
When the agent receives the traveler's trip order, he will
determine the legs for each of the stages, which includes an initial seat
reservation for each of the participants as well as the rate chosen.
To actually make the corresponding ticket orders the agent submits these
legs together with the information about the credit card to be charged to
the
airline company.

== Create new reservations at airline ===
POST http://services.airliner.com/reservations/ HTTP/1.1
Reply-To: http://services.travelagents.com/trips/0173/airline/ack/
Status-To: http://services.travelagents.com/trips/0173/airline/status/
Content-Type: text/xml
Content-Model: ReservationRequest
Authenticiation: Basic [travelagents:password]

<reservation>
 <!-- URI of secure payment verification callback - the airlines have to
auth to get in -->

<payment>http://services.travelagents.com/payment/verification/xyz/</payment
>
 <recipient>mdierken@...</recipient>
<leg>
 <flight>UA-1024</flight>
 <seat>33A</seat>
 <rate>$12.00</rate>
</leg>
<leg>
 <flight>NW-832</flight>
 <seat>22B</seat>
 <rate>$12.00</rate>
</leg>
</reservation>

== Acknowledgement of submission (with location of reservation) ==
HTTP/1.1 202 Accepted
Location: http://reservations.airliner.com/agents/travelagents.com/res-0029/

-- step four --
When the airline receives the ticket order submitted by the agent, the
requested seats will be checked and if available assigned to the
corresponding
participants. After that, the credit card will be charged, and the updated
leg
information is sent back to the agent as confirmation of the flights.

-- step five --
After that, the airline sends the electronic tickets by e-mail to the
traveler.
Information about the recipient of the tickets has been specified by the
traveler when instantiating the trip order process and this information is
passed to the agent as well as to the airline.

-- step six --
Then, the agent will wait for the confirmation of the flights, which
especially includes the actual seats reserved for each of the participants.
This information is completed into an itinerary, which is then sent to the
traveler.

== Acknowledge new reservation at airline ===
POST http://services.travelagents.com/trips/0173/airline/ack/ HTTP/1.1
Content-Type: text/xml
Content-Model: ReservationConfirmation
Authenticiation: Basic [airliner:password]

<reservation>
<leg>
 <flight>UA-1024</flight>
 <seat>33A</seat>
 <rate>$923.00</rate>
</leg>
<leg>
 <flight>NW-832</flight>
 <seat>22B</seat>
 <rate>$923.00</rate>
</leg>
</reservation>

== Confirm receipt of reservation info ==
HTTP/1.1 200 OK


--- scenario from IBM's WS Flow Language document ---
"The overall flow of this example is as follows: A traveler will plan her
trip
by specifying the various stages of his overall journey and all of its
participants. For each of the stages, the traveler specifies the location
that
she wants to visit as well as the date when she wants to begin and the date
when she wants to end the particular stay. When the traveler is finished
with
this, she sends this information together with the list of all participants
of
the trip as well as the information about the credit card to be charged for
the
ordered tickets to the travel agent. The credit card information has been
passed when the business process was instantiated. Next, the traveler will
await the submission of the electronic tickets as well as the final
itinerary
for the trip. When the agent receives the traveler's trip order, he will
determine the legs for each of the stages, which includes an initial seat
reservation for each of the participants as well as the rate chosen. To
actuall
y make the corresponding ticket orders the agent submits these legs together
with the information about the credit card to be charged to the airline
company. Then, the agent will wait for the confirmation of the flights,
which
especially includes the actual seats reserved for each of the participants.
This information is completed into an itinerary, which is then sent to the
traveler.

When the airline receives the ticket order submitted by the agent, the
requested seats will be checked and if available assigned to the
corresponding
participants. After that, the credit card will be charged, and the updated
leg
information is sent back to the agent as confirmation of the flights. After
that, the airline sends the electronic tickets by e-mail to the traveler.
Information about the recipient of the tickets has been specified by the
traveler when instantiating the trip order process and this information is
passed to the agent as well as to the airline."








-----------------------------------------------------------------------------------
Post ID:1372
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-01 08:05:33
Subject:Re: [rest-discuss] REST and travel agents revisited
Message:

I've posted it to the Wiki as well:

http://internet.conveyor.com/RESTwiki/moin.cgi/RestGoesToMaui

(say g'night gracie...)

----- Original Message -----
From: "S. Mike Dierken" <mdierken@...>
To: <rest-discuss@yahoogroups.com>; "Robert Leftwich" <robert@...>
Sent: Saturday, June 01, 2002 12:45 AM
Subject: Re: [rest-discuss] REST and travel agents revisited


>
> ----- Original Message -----
> From: "Robert Leftwich" <robert@...>
>
>
> > Bob's adding of the travel agent scenario to the 'State machine as
> hypertext' wiki page along with the comment 'No attempts to RESTify this
> example have been reported' prompted me to try out my REST skills - be
> warned, the training wheels are still on:-)
> >
> > The resources modelled are similar to those identified in the original
> document:
> >
> > TripIdentifier
> >     Participants
> >         Participant1
> >         Participant2
> >         ....
> >         ParticipantN
> >     Journey
> >         Stage1
> >         Stage2
> >         ....
> >         StageN
> >
> If I'm reading this right, it sounds like you are making each item a full
> resource.
> To me, the data called out in the original document (appended at the end
of
> the message) don't necessarily need to be full URI resources.
> I don't see the URIs, their structure or nesting as all that important.
> In the nested text shown above, the Participant1 could be an independent
> entity that is merely referenced by the trip, rather than being
> 'subordinate' to the trip resource.
>
> Here's how I would do it:
> The information types seem to be 'traveler', 'trip', 'stage',
'participant',
> etc.
> I'd start with a coarse-grained resource like 'trip' and expand out into
> 'traveler' or 'participant' if necessary.
> Within, I'd have an XML blob with details and any useful links.
>
> The resources I generated in walking through this are:
> -- submit a new trip --
> http://services.travelagents.com/trips/
> -- new trip that was created --
> http://services.travelagents.com/trips/0173/
> -- callbacks for airline to confirm reservations --
> http://services.travelagents.com/trips/0173/airline/ack/
> http://services.travelagents.com/trips/0173/airline/status/
> -- submit new reservations --
> http://services.airliner.com/reservations/
> -- new reservation that was created --
> http://reservations.airliner.com/agents/travelagents.com/res-0029/
>
> Note - the URIs do /not/ have to be related textually - the URI of the new
> reservation at the airline is even on a different host for example. The
> connection between all these is through HTTP headers, or they could also
be
> done via href's inside some XML.
>
>
> -- step one --
> The overall flow of this example is as follows: A traveler will plan her
> trip
> by specifying the various stages of his overall journey and all of its
> participants. For each of the stages, the traveler specifies the location
> that
> she wants to visit as well as the date when she wants to begin and the
date
> when she wants to end the particular stay. When the traveler is finished
> with
> this, she sends this information together with the list of all
participants
> of
> the trip as well as the information about the credit card to be charged
for
> the
> ordered tickets to the travel agent.
>
> == Create a new trip ===
> POST http://services.travelagents.com/trips/ HTTP/1.1
> Content-Type: text/xml
> Content-Model: TripSpecification
>
> <trip>
> <stage>
>  <location>maui</location>
>  <start>immediately</start>
>  <finish>never</finish>
> </stage>
> <participant>
>  <name>Mike</name>
> </participant>
> <payment>VISA</payment>
> <recipient>mdierken@...</recipient>
> </trip>
>
> == Acknowledgement of submission (with location of trip) ==
> HTTP/1.1 202 Accepted
> Location: http://services.travelagents.com/trips/0173/
>
>
> -- step two --
> The credit card information has been passed when the business process was
> instantiated.
> Next, the traveler will await the submission of the electronic tickets as
> well as the final itinerary
> for the trip.
>
> -- step three --
> When the agent receives the traveler's trip order, he will
> determine the legs for each of the stages, which includes an initial seat
> reservation for each of the participants as well as the rate chosen.
> To actually make the corresponding ticket orders the agent submits these
> legs together with the information about the credit card to be charged to
> the
> airline company.
>
> == Create new reservations at airline ===
> POST http://services.airliner.com/reservations/ HTTP/1.1
> Reply-To: http://services.travelagents.com/trips/0173/airline/ack/
> Status-To: http://services.travelagents.com/trips/0173/airline/status/
> Content-Type: text/xml
> Content-Model: ReservationRequest
> Authenticiation: Basic [travelagents:password]
>
> <reservation>
>  <!-- URI of secure payment verification callback - the airlines have to
> auth to get in -->
>
>
<payment>http://services.travelagents.com/payment/verification/xyz/</payment
> >
>  <recipient>mdierken@...</recipient>
> <leg>
>  <flight>UA-1024</flight>
>  <seat>33A</seat>
>  <rate>$12.00</rate>
> </leg>
> <leg>
>  <flight>NW-832</flight>
>  <seat>22B</seat>
>  <rate>$12.00</rate>
> </leg>
> </reservation>
>
> == Acknowledgement of submission (with location of reservation) ==
> HTTP/1.1 202 Accepted
> Location:
http://reservations.airliner.com/agents/travelagents.com/res-0029/
>
> -- step four --
> When the airline receives the ticket order submitted by the agent, the
> requested seats will be checked and if available assigned to the
> corresponding
> participants. After that, the credit card will be charged, and the updated
> leg
> information is sent back to the agent as confirmation of the flights.
>
> -- step five --
> After that, the airline sends the electronic tickets by e-mail to the
> traveler.
> Information about the recipient of the tickets has been specified by the
> traveler when instantiating the trip order process and this information is
> passed to the agent as well as to the airline.
>
> -- step six --
> Then, the agent will wait for the confirmation of the flights, which
> especially includes the actual seats reserved for each of the
participants.
> This information is completed into an itinerary, which is then sent to the
> traveler.
>
> == Acknowledge new reservation at airline ===
> POST http://services.travelagents.com/trips/0173/airline/ack/ HTTP/1.1
> Content-Type: text/xml
> Content-Model: ReservationConfirmation
> Authenticiation: Basic [airliner:password]
>
> <reservation>
> <leg>
>  <flight>UA-1024</flight>
>  <seat>33A</seat>
>  <rate>$923.00</rate>
> </leg>
> <leg>
>  <flight>NW-832</flight>
>  <seat>22B</seat>
>  <rate>$923.00</rate>
> </leg>
> </reservation>
>
> == Confirm receipt of reservation info ==
> HTTP/1.1 200 OK
>
>
> --- scenario from IBM's WS Flow Language document ---
> "The overall flow of this example is as follows: A traveler will plan her
> trip
> by specifying the various stages of his overall journey and all of its
> participants. For each of the stages, the traveler specifies the location
> that
> she wants to visit as well as the date when she wants to begin and the
date
> when she wants to end the particular stay. When the traveler is finished
> with
> this, she sends this information together with the list of all
participants
> of
> the trip as well as the information about the credit card to be charged
for
> the
> ordered tickets to the travel agent. The credit card information has been
> passed when the business process was instantiated. Next, the traveler will
> await the submission of the electronic tickets as well as the final
> itinerary
> for the trip. When the agent receives the traveler's trip order, he will
> determine the legs for each of the stages, which includes an initial seat
> reservation for each of the participants as well as the rate chosen. To
> actuall
> y make the corresponding ticket orders the agent submits these legs
together
> with the information about the credit card to be charged to the airline
> company. Then, the agent will wait for the confirmation of the flights,
> which
> especially includes the actual seats reserved for each of the
participants.
> This information is completed into an itinerary, which is then sent to the
> traveler.
>
> When the airline receives the ticket order submitted by the agent, the
> requested seats will be checked and if available assigned to the
> corresponding
> participants. After that, the credit card will be charged, and the updated
> leg
> information is sent back to the agent as confirmation of the flights.
After
> that, the airline sends the electronic tickets by e-mail to the traveler.
> Information about the recipient of the tickets has been specified by the
> traveler when instantiating the trip order process and this information is
> passed to the agent as well as to the airline."
>
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:1373
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-01 11:51:53
Subject:Re: REST and travel agents revisited
Message:

I'm gonna watch Mike Dierken and you roll with the RESTification and 
just respond to one issue here.  Nice title, Mike!

Robert Leftwich wrote:
> Can you give an example of state being represented by hyperlinks?

Here's two:
* A leg of the trip is ticketed.  The "ticketed" state is signified 
by a hyperlink to a Ticket resource on the airline site.  (I'm not 
necessarily suggesting this as a REST model for your scenario, just 
as an example for discussion.)

* A business entity type (e.g. a Trip type or Order type) has a 
public state machine published by a company or standards org.  Each 
state in the state machine is a resource. Every entity that is an 
instance of that type hyperlinks to its current State resource, which 
gives rules, transitions to possible next states, etc. 

For the state-alignment transaction model (which I think will work in 
REST, contrary to some recent statements on the ws-arch list), 
participants do need to agree on states.  One way to do that would be 
to publish the state-transition model for an entity type as 
hypertext, and have each resource that wants to be an instance of the 
type link to the same set of states.

There are other ways to do it, but that's one way.








-----------------------------------------------------------------------------------
Post ID:1374
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-01 12:18:25
Subject:Re: REST and travel agents revisited
Message:

Robert, Mike, anybody,

Do you know if this is a realistic travel-agent scenario? For 
example, I would have thought that the agent would put a temporary 
hold on the seats and ask the traveler to approve the itinerary 
before booking the tickets. Not trying to complicate things, but I've 
seen a lot of these business processes for different 
orchestration "languages" that are not the way anybody would actually 
do business, but instead are designed to match the features of 
the "language" well. 







-----------------------------------------------------------------------------------
Post ID:1375
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-02 06:50:33
Subject:RE: [rest-discuss] REST and travel agents revisited
Message:

Mike wrote:
[snip]
> == Acknowledgement of submission (with location of trip) ==
> HTTP/1.1 202 Accepted
> Location: http://services.travelagents.com/trips/0173/
[snip]

Quick HTTP question: is it standard to include a Location header field with 202
responses?  After looking at RFC 2616 (sect 14.30), it mentions using Location
with 201 and 3xx responses and an absolute URI to specify the location of the
resource. I'm developing a REST toolkit and I want to make sure my HTTP client
and server code implements this right.

Thanks,
Philip Eskelin







-----------------------------------------------------------------------------------
Post ID:1376
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-02 20:05:42
Subject:HTTP Persistent connection - non-RESTful?
Message:

HTTP allows persistent connections.  That is, the client initiates a
request and the connection stays open until the client closes it.  While
it is open the client can issue multiple requests.  During this open
connection a request can depend on prior requests.  Right?  Isn't this
violating the REST principle that all requests be stateless, i.e., to
promote scalability the server is not expected to maintain information
about prior requests?  /Roger







-----------------------------------------------------------------------------------
Post ID:1377
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-02 21:14:45
Subject:HTTP POST/PUT/DELETE - what happens to the resource?
Message:

I think that I understand the REST abstraction of an HTTP GET:  A
resource is an abstraction of a concept.  How the resource is
implemented is encapsulated.  When a client issues an HTTP GET the
client receives a representation of the resource.  Correct?

I am not clear on what the REST abstraction is of an HTTP POST, PUT or
DELETE.  Is this the intended abstraction for an HTTP POST: the client
sends to the resource a partial representation of the resource, which it
expects the resource to incorporate into itself.  Is that the REST
abstraction for an HTTP POST?

And what is the abstraction with an HTTP PUT?  Is it that the client
sends to the resource a new, complete representation of the resource
which it expects the resource to replace itself with?  

Is the abstraction for an HTTP DELETE that the resource should
completely delete itself?

In the three cases (POST, PUT, DELETE) it seems like the client is
asking the resource to commit partial or complete suicide for the sake
of the client's new representation.  That doesn't seem to be a very
reasonable thing to ask of a resource.   /Roger







-----------------------------------------------------------------------------------
Post ID:1378
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-06-02 21:22:21
Subject:Re: [rest-discuss] HTTP POST/PUT/DELETE - what happens to the resource?
Message:

My take on this from an HTTP spec perspective (see 
http://internet.conveyor.com/RESTwiki/moin.cgi/HttpMethods - an extract from 
the HTTP specs) is as follows:

At 07:14 AM 3/06/2002, Roger L. Costello wrote:
>I think that I understand the REST abstraction of an HTTP GET:  A
>resource is an abstraction of a concept.  How the resource is
>implemented is encapsulated.  When a client issues an HTTP GET the
>client receives a representation of the resource.  Correct?

Yes, but interestingly HTTP allows a partial retrieval by the use of the 
Range header field, which would be useful if the resource was a collection 
of some sort.


>Is this the intended abstraction for an HTTP POST: the client
>sends to the resource a partial representation of the resource, which it
>expects the resource to incorporate into itself.  Is that the REST
>abstraction for an HTTP POST?

POST adds additional sub-resources to an existing resource, e.g. 
annotations, chat-style messages, database appends.

"The actual function performed by the POST method is determined by the 
server and is usually dependent on the Request-URI. The posted entity is 
subordinate to that URI in the same way that a file is subordinate to a 
directory containing it, a news article is subordinate to a newsgroup to 
which it is posted, or a record is subordinate to a database. "


>And what is the abstraction with an HTTP PUT?  Is it that the client
>sends to the resource a new, complete representation of the resource
>which it expects the resource to replace itself with?  

Interestingly (again), "the PUT method SHOULD be considered as a modified 
version of the one residing on the origin server", but it does not have to be. 

PUT can also result in the creation of a new resource "If the Request-URI 
does not point to an existing resource, and that URI is capable of being 
defined as a new resource by the requesting user agent"

"The fundamental difference between the POST and PUT requests is reflected 
in the different meaning of the Request-URI. The URI in a POST request 
identifies the resource that will handle the enclosed entity. That resource 
may be a data-accepting process, a gateway to some other protocol, or a 
separate entity that accepts annotations. In contrast, the URI in a PUT 
request identifies the entity enclosed with the request -- the user agent 
knows what URI is intended and the server MUST NOT attempt to apply the 
request to some other resource. "


>Is the abstraction for an HTTP DELETE that the resource should
>completely delete itself?

"The DELETE method requests that the origin server delete the resource 
identified by the Request-URI. This method MAY be overridden by human 
intervention (or other means) on the origin server. The client cannot be 
guaranteed that the operation has been carried out, even if the status code 
returned from the origin server indicates that the action has been completed 
successfully."


>In the three cases (POST, PUT, DELETE) it seems like the client is
>asking the resource to commit partial or complete suicide for the sake
>of the client's new representation.  

Not true for POST, possibly true for PUT and DELETE.

>That doesn't seem to be a very
>reasonable thing to ask of a resource.

Doesn't it depend on what the resource is and what the servers 'actual' 
interpretation of the method is?


Robert







-----------------------------------------------------------------------------------
Post ID:1379
Sender:rest-discuss@yahoogroups.com
Post Date/Time:2002-06-02 21:55:39
Subject:New file uploaded to rest-discuss
Message:

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the rest-discuss 
group.

  File        : / Looking for fast Internet service? 
  Uploaded by : davenorjsak <davenorjsak@...> 
  Description : Click above to learn what DIRECTV has to offer. 

You can access this file at the URL

http://groups.yahoo.com/group/rest-discuss/files/%20Looking%20for%20fast%20Internet%20service%3F 

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

davenorjsak <davenorjsak@...>
 










-----------------------------------------------------------------------------------
Post ID:1380
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-06-02 23:27:17
Subject:Re: [rest-discuss] REST and travel agents revisited
Message:

At 05:45 PM 1/06/2002, S. Mike Dierken wrote:

>----- Original Message -----
>From: "Robert Leftwich" <robert@...>
>> The resources modelled are similar to those identified in the original
>document:
>>
>> TripIdentifier
>>     Participants
>>         Participant1
>>         Participant2
>>         ....
>>         ParticipantN
>>     Journey
>>         Stage1
>>         Stage2
>>         ....
>>         StageN
>>
>If I'm reading this right, it sounds like you are making each item a full
>resource.

That was to allow access to the sub-resources directly, allowing changes to participants, stages, etc The usefulness of this probably varies depending on the system, but in my case, it is most definitely useful (it's somewhat confusing, in that I am using the travel agent example as a proxy for the real thing). The other area I was attempting to explore was that of a state machine as hypertext, which this design does not address.

>To me, the data called out in the original document (appended at the end of
>the message) don't necessarily need to be full URI resources.

Agreed

>I don't see the URIs, their structure or nesting as all that important.

That's an interesting comment in the light of the whole 'resource modeling' side to REST.

>In the nested text shown above, the Participant1 could be an independent
>entity that is merely referenced by the trip, rather than being
>'subordinate' to the trip resource.

True. I was going to say 'but the nesting above doesn't necessitate a dependant entity' but in the light of the HTTP spec a sub-resource should be owned by its parent (in the sense a directory owns a file in it). I suppose the sub-resource could be a proxy for the real thing.


>-- step one --
>The overall flow of this example is as follows: A traveler will plan her
>trip
>by specifying the various stages of his overall journey and all of its
>participants. For each of the stages, the traveler specifies the location
>that
>she wants to visit as well as the date when she wants to begin and the date
>when she wants to end the particular stay. When the traveler is finished
>with
>this, she sends this information together with the list of all participants
>of
>the trip as well as the information about the credit card to be charged for
>the
>ordered tickets to the travel agent.
>
>== Create a new trip ===
>POST http://services.travelagents.com/trips/ HTTP/1.1
>Content-Type: text/xml
>Content-Model: TripSpecification
>
><trip>
><stage>
> <location>maui</location>
> <start>immediately</start>
> <finish>never</finish>
></stage>
><participant>
> <name>Mike</name>
></participant>
><payment>VISA</payment>
><recipient>mdierken@...</recipient>
></trip>
>
>== Acknowledgement of submission (with location of trip) ==
>HTTP/1.1 202 Accepted
>Location: http://services.travelagents.com/trips/0173/

What is Content-Model? Is it a standard HTTP header or an app-specific one? If it is the former, I cannot find mention of it in RFC 2616 (or anywhere else for that matter).

Of  course this use case is somewhat simplistic as it does not mention problems such as changing participants or stages after submission, problems in seat allocation, flight cancellation, etc but it should serve well enough as a discussion focus.

Robert







-----------------------------------------------------------------------------------
Post ID:1381
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-03 03:18:04
Subject:Re: [rest-discuss] HTTP Persistent connection - non-RESTful?
Message:

On Sun, Jun 02, 2002 at 04:05:42PM -0400, Roger L. Costello wrote:
> HTTP allows persistent connections.  That is, the client initiates a
> request and the connection stays open until the client closes it.  While
> it is open the client can issue multiple requests.  During this open
> connection a request can depend on prior requests.  Right?  Isn't this
> violating the REST principle that all requests be stateless, i.e., to
> promote scalability the server is not expected to maintain information
> about prior requests?  /Roger

"Stateless" just means that all the information that's needed to
interpret the meaning of the message, is available in the message
itself.  The type of connection used doesn't impact this at all,
so it's fine.

It's funny you mentioned this, as a related bug has apparently just
been discovered in IIS;

http://lists.w3.org/Archives/Public/www-talk/2002MayJun/0056

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1382
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-03 03:35:35
Subject:Re: [rest-discuss] HTTP POST/PUT/DELETE - what happens to the resource?
Message:

POST doesn't have to create new resources, it can just be a logical
"add" where what is "added" can be consumed as soon as it's processed
and not provided its own identity.  I like thinking about it as an "add
operation, because the notion of containment is very much key to how I
model.  But it's more abstract an operation than you appear to suggest.

FWIW, I've written a couple of things that talk about this;

http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model
http://www.markbaker.ca/2002/03/RestRDF/

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1383
Sender:Jason Petrone <jpetrone@...>
Post Date/Time:2002-06-03 15:29:10
Subject:Re: [rest-discuss] REST-OO? (URIs as passing by reference)
Message:

On Tue, May 28, 2002 at 01:39:59AM -0700, Joe Hsy wrote:
> Historically, one of the biggest issues of distributed programming is that
> it is difficult to pass by reference.  Thus, you have to pass the entire
> data from one addressing space to another (thus RPCs).  If we think of the
> URI naming system as an universal addressing space - we are in essence
> creating the ability to pass by reference - isn't that what a link is, after
> all?

Pass by reference is a problem in distributed systems, but it seems to
be solved in CORBA, and I believe in DCOM as well.  The problem I
usually think of is *garbage collection*.  

The SOAP RFC quotes garbage collection as a reason for not providing for
object references.

I'm still settling on this whole REST thing, but as I understand it, the
idea in REST is to avoid transient references as much as possible.
Instead, store whatever information is needed to rebuild the object in
the URI.  

jlp






-----------------------------------------------------------------------------------
Post ID:1384
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-03 16:50:20
Subject:Re: [rest-discuss] REST and travel agents revisited
Message:

----- Original Message -----
From: "Philip Eskelin" <philip@...>


> Mike wrote:
> [snip]
> > == Acknowledgement of submission (with location of trip) ==
> > HTTP/1.1 202 Accepted
> > Location: http://services.travelagents.com/trips/0173/
> [snip]
>
> Quick HTTP question: is it standard to include a Location header field
with 202
> responses?  After looking at RFC 2616 (sect 14.30), it mentions using
Location
> with 201 and 3xx responses and an absolute URI to specify the location of
the
> resource. I'm developing a REST toolkit and I want to make sure my HTTP
client
> and server code implements this right.

Nope - that was my little addition. I haven't sent a mail to IETF asking
about the appropriateness. Probably should do that...







-----------------------------------------------------------------------------------
Post ID:1385
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-03 16:53:01
Subject:Re: [rest-discuss] HTTP Persistent connection - non-RESTful?
Message:

----- Original Message -----
From: "Roger L. Costello" <costello@...>


> HTTP allows persistent connections.  That is, the client initiates a
> request and the connection stays open until the client closes it.  While
> it is open the client can issue multiple requests.  During this open
> connection a request can depend on prior requests.  Right?
No - the requests are (should) be independent. They each must specify
resource, method, auth, encoding, etc.

As a side note, imagine what would happen if what was kept open was not the
connection but the response... a never-ending view onto the (past and
future) state of a resource. If you are into Fun Tricks with Sockets you can
do neat stuff.






-----------------------------------------------------------------------------------
Post ID:1386
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-03 17:00:53
Subject:Re: [rest-discuss] REST and travel agents revisited
Message:

----- Original Message -----
From: "Robert Leftwich" <robert@...>

> >If I'm reading this right, it sounds like you are making each item a full
> >resource.
>
> That was to allow access to the sub-resources directly, allowing changes
to participants, stages, etc
If as a URI the participant would be "Trip1/participants/Participant1", then
that person is not identifiable separate from a trip. I was thinking that
the trip would point to participants independent of any particular trip.
Just a different way of splitting it up.

>
> >I don't see the URIs, their structure or nesting as all that important.
>
> That's an interesting comment in the light of the whole 'resource
modeling' side to REST.
I meant the URI text format - whether you use '/' or '?' or ';' or
whatever - is not meaningful to the client. Having one resource nested
within another is not part of the coordination between client and server.
The XML (or whatever) representation of a resource will explicitly point to
whatever resource should be used (with absolute or relative URIs).








-----------------------------------------------------------------------------------
Post ID:1387
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-03 17:04:08
Subject:Re: [rest-discuss] REST and travel agents revisited
Message:

----- Original Message -----
From: "Robert Leftwich" <robert@...>

> >== Create a new trip ===
> >POST http://services.travelagents.com/trips/ HTTP/1.1
> >Content-Type: text/xml
> >Content-Model: TripSpecification
>
> What is Content-Model? Is it a standard HTTP header or an app-specific
one?
> If it is the former, I cannot find mention of it in RFC 2616 (or anywhere
else for that matter).
Another mike-ism. I think it is useful to identify the meaning the entity
body separate from any particular encoding/syntax. Not actually standard
HTTP. It cuts across debates on whether a DTD identifier, or Schema location
or 'root' namespace URI or whatever is the ultimate semantically meaningful
value.








-----------------------------------------------------------------------------------
Post ID:1388
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-03 17:05:57
Subject:Re: [rest-discuss] REST-OO? (URIs as passing by reference)
Message:

----- Original Message -----
From: "Jason Petrone" <jpetrone@...>


> I'm still settling on this whole REST thing, but as I understand it, the
> idea in REST is to avoid transient references as much as possible.
> Instead, store whatever information is needed to rebuild the object in
> the URI.

By 'rebuild' to you mean 're-acquire' or do you mean that the URI has the
full state of the object?






-----------------------------------------------------------------------------------
Post ID:1389
Sender:Jason Petrone <jpetrone@...>
Post Date/Time:2002-06-03 17:50:54
Subject:Re: [rest-discuss] REST-OO? (URIs as passing by reference)
Message:

On Mon, Jun 03, 2002 at 10:05:57AM -0700, S. Mike Dierken wrote:
> From: "Jason Petrone" <jpetrone@...>
> > I'm still settling on this whole REST thing, but as I understand it, the
> > idea in REST is to avoid transient references as much as possible.
> > Instead, store whatever information is needed to rebuild the object in
> > the URI.
> 
> By 'rebuild' to you mean 're-acquire' or do you mean that the URI has the
> full state of the object?

Correct me if I am wrong, but I meant that "the URI has the full state
of the object."

I suppose there will be some cases where encoding the full state in the
URI is not possible, but I'm not confident enough to speak to that.

jlp






-----------------------------------------------------------------------------------
Post ID:1390
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-03 20:52:32
Subject:Re: [rest-discuss] REST-OO? (URIs as passing by reference)
Message:

----- Original Message -----
From: "Jason Petrone" <jpetrone@...>
To: <rest-discuss@yahoogroups.com>
Sent: Monday, June 03, 2002 10:50 AM
Subject: Re: [rest-discuss] REST-OO? (URIs as passing by reference)


> On Mon, Jun 03, 2002 at 10:05:57AM -0700, S. Mike Dierken wrote:
> > From: "Jason Petrone" <jpetrone@...>
> > > I'm still settling on this whole REST thing, but as I understand it,
the
> > > idea in REST is to avoid transient references as much as possible.
> > > Instead, store whatever information is needed to rebuild the object in
> > > the URI.
> >
> > By 'rebuild' to you mean 're-acquire' or do you mean that the URI has
the
> > full state of the object?
>
> Correct me if I am wrong, but I meant that "the URI has the full state
> of the object."
>
> I suppose there will be some cases where encoding the full state in the
> URI is not possible, but I'm not confident enough to speak to that.
>

I don't think it is a primary goal of REST to avoid transient references,
although it is a good design principle.
Regardless, I'm pretty sure REST and pure-HTTP advocates are not suggesting
that the URI stores the full state of the object.

What is being recommended is that the URI - and the URI alone - /identifies/
the object. The state remains within the 'origin server' and clients can
interact with the object only through sending and receiving representations
of the object.

Many discussions show fairly long URI with a lot of information in it, but
that is not intended to be the /state/ of the object.

Do you have any examples that made it look like the URI had the full state
of the object?








-----------------------------------------------------------------------------------
Post ID:1391
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-04 05:24:18
Subject:Anybody familiar with AS2?
Message:

http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-11.txt
HTTP Transport for Secure Peer-to-Peer Business Data Interchange over the
Internet

---

Abstract

   This document describes how to exchange structured business data
   securely using HTTP transport for Electronic Data Interchange,
   (EDI - either the American Standards Committee X12 or UN/EDIFACT,
   Electronic Data Interchange for Administration, Commerce and
   Transport), XML or other data used for business to business data
   interchange. The data is packaged using standard MIME
   content-types. Authentication and privacy are obtained by using
   Cryptographic Message Syntax (S/MIME) or OpenPGP security body
   parts. Authenticated acknowledgements make use of
   multipart/signed replies to the HTTP POST requests.

   This document extends the procedures and payload packaging options
   of AS1 in the following ways: HTTPS may be used to obtain data,
   privacy both synchronous and asynchronous reply procedures are,
   described multipart/form-data packaging may be used, a generalized
   multipart/report format is added to the MDN format of AS1, replies
   may include a multipart/mixed payload that contains both the
   acknowledgement and an additional EDI payload.







-----------------------------------------------------------------------------------
Post ID:1392
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-04 12:28:52
Subject:Cookies not RESTful - need explaination
Message:

Hi Folks,

Below is an except from Fielding's REST dissertation, describing why
cookies are not RESTful.  Can someone explain what he is saying here?

"Likewise, the use of cookies to identify a user-specific 'shopping
basket' within a server-side database could be more efficiently
implemented by defining the semantics of shopping items within the
hypermedia data formats, allowing the user agent to select and store
those items within their own client-side shopping basket, complete with
a URI to be used for check-out when the client is ready to purchase."

/Roger








-----------------------------------------------------------------------------------
Post ID:1393
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-04 12:51:30
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

On Tue, Jun 04, 2002 at 08:28:52AM -0400, Roger L. Costello wrote:
> Hi Folks,
> 
> Below is an except from Fielding's REST dissertation, describing why
> cookies are not RESTful.  Can someone explain what he is saying here?
> 
> "Likewise, the use of cookies to identify a user-specific 'shopping
> basket' within a server-side database could be more efficiently
> implemented by defining the semantics of shopping items within the
> hypermedia data formats, allowing the user agent to select and store
> those items within their own client-side shopping basket, complete with
> a URI to be used for check-out when the client is ready to purchase."

You know that cookies are stateful, right?  That is, they make it so
that there isn't enough information in the HTTP message to understand
what it does, because it depends on the information represented by
the cookie which is invisible to everybody but the server.

So if you wanted to do a shopping basket statelessly, it's up to the
client to manage that the state of the basket, submitting a
representation of the basket to the server when it wants to checkout.
The local URI would be needed to identify which shopping basket, so that
when you opted to put something in the basket, you would do a local POST
of the representation of the item to your basket.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1394
Sender:Lucas Gonze <lgonze@...>
Post Date/Time:2002-06-04 12:34:52
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

Basically he's saying that cookies are a quick hack that ignores REST.  
Rather than specifying session state in a message header, session state 
should be part of the server resource.

So instead of:
GET /someresource
session-state-store-on-client: mynameis=slimshady

use:
GET /slimshady/someresource

- Lucas








-----------------------------------------------------------------------------------
Post ID:1395
Sender:Allan Doyle <adoyle@...>
Post Date/Time:2002-06-04 13:38:19
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

On Tuesday 2002-06-04 at 08:51:30(-0400) Mark Baker wrote:
 > On Tue, Jun 04, 2002 at 08:28:52AM -0400, Roger L. Costello wrote:
 > > Hi Folks,
 > > 
 > > Below is an except from Fielding's REST dissertation, describing why
 > > cookies are not RESTful.  Can someone explain what he is saying here?
 > > 
 > > "Likewise, the use of cookies to identify a user-specific 'shopping
 > > basket' within a server-side database could be more efficiently
 > > implemented by defining the semantics of shopping items within the
 > > hypermedia data formats, allowing the user agent to select and store
 > > those items within their own client-side shopping basket, complete with
 > > a URI to be used for check-out when the client is ready to purchase."
 > 
 > You know that cookies are stateful, right?  That is, they make it so
 > that there isn't enough information in the HTTP message to understand
 > what it does, because it depends on the information represented by
 > the cookie which is invisible to everybody but the server.

Just a nit. The second part of that sentence is true, but the first
part is not the issue. Any individual HTTP message need not contain
the state, let alone let you understand what it does.  The state
should be contained in representations that are accessible via GET (or
maybe POST).

Cookies are out of band as far as REST is concerned, and are
downright anti-REST because you will probably never see the cookie
contents but those contents are responsible for a ton of information
transfer between client and server. If you moved the cookie info to a
URI-accessible location, then it would be RESTful. A big issue with
current practice (not with HTTP or REST) is that usually clients don't
have HTTP servers running in them or on their behalf so the server
can't get at client-side state with a simple GET. (c.f. the
"client-side shopping basket" statement above). This asymmetry also
impacts the ability to do decent asynchronous callbacks from the
server to the client.

 > 
 > So if you wanted to do a shopping basket statelessly, it's up to the
 > client to manage that the state of the basket, submitting a
 > representation of the basket to the server when it wants to checkout.
 > The local URI would be needed to identify which shopping basket, so that
 > when you opted to put something in the basket, you would do a local POST
 > of the representation of the item to your basket.
 > 
 > MB
 > -- 
 > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
 > Ottawa, Ontario, CANADA.               distobj@...
 > http://www.markbaker.ca        http://www.idokorro.com
 > 
 > 
 > To unsubscribe from this group, send an email to:
 > rest-discuss-unsubscribe@yahoogroups.com
 > 
 >  
 > 
 > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
 > 
 > 
 > 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle                         http://www.intl-interfaces.com
adoyle@...







-----------------------------------------------------------------------------------
Post ID:1396
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-04 14:11:38
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

Allan,

On Tue, Jun 04, 2002 at 09:38:19AM -0400, Allan Doyle wrote:
>  > You know that cookies are stateful, right?  That is, they make it so
>  > that there isn't enough information in the HTTP message to understand
>  > what it does, because it depends on the information represented by
>  > the cookie which is invisible to everybody but the server.
> 
> Just a nit. The second part of that sentence is true, but the first
> part is not the issue. Any individual HTTP message need not contain
> the state, let alone let you understand what it does.  The state
> should be contained in representations that are accessible via GET (or
> maybe POST).

No, the first part is the issue (though I could have chosen a better
word than "does").  You appear to be confusing "stateful interaction"
with "stateful service".

Just take a message, and ask yourself this question; "Will this message
mean the same thing in 20 years?".  If so, then that is stateless.  If
you use cookies with HTTP, then the answer is "no", because the cookie
would have expired in that time, and that would change the meaning of
the message.

Note that the "meaning of the message" is not the same as "the result
of the message being processed".  Obviously a message sent now, versus
the same one sent 20 years from now, will do something different.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1397
Sender:Allan Doyle <adoyle@...>
Post Date/Time:2002-06-04 14:09:50
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

On Tuesday 2002-06-04 at 10:11:38(-0400) Mark Baker wrote:
 > Allan,
 > 
 > On Tue, Jun 04, 2002 at 09:38:19AM -0400, Allan Doyle wrote:
 > >  > You know that cookies are stateful, right?  That is, they make it so
 > >  > that there isn't enough information in the HTTP message to understand
 > >  > what it does, because it depends on the information represented by
 > >  > the cookie which is invisible to everybody but the server.
 > > 
 > > Just a nit. The second part of that sentence is true, but the first
 > > part is not the issue. Any individual HTTP message need not contain
 > > the state, let alone let you understand what it does.  The state
 > > should be contained in representations that are accessible via GET (or
 > > maybe POST).
 > 
 > No, the first part is the issue (though I could have chosen a better
 > word than "does").  You appear to be confusing "stateful interaction"
 > with "stateful service".

I read it differently because the subject was cookies. Cookies are for
session state, i.e. stateful service.

 > 
 > Just take a message, and ask yourself this question; "Will this message
 > mean the same thing in 20 years?".  If so, then that is stateless.  If
 > you use cookies with HTTP, then the answer is "no", because the cookie
 > would have expired in that time, and that would change the meaning of
 > the message.

Yes, I agree fully with this.

 > 
 > Note that the "meaning of the message" is not the same as "the result
 > of the message being processed".  Obviously a message sent now, versus
 > the same one sent 20 years from now, will do something different.

and this...

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle                         http://www.intl-interfaces.com
adoyle@...







-----------------------------------------------------------------------------------
Post ID:1398
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-04 14:39:30
Subject:Re: RESTful shopping basket
Message:

Mark Baker wrote:
> So if you wanted to do a shopping basket statelessly, it's up to the
> client to manage that the state of the basket, submitting a
> representation of the basket to the server when it wants to 
checkout.

Why couldn't the shopping basket be kept on the server, with a 
customer-specific URI?  Why is it any different than an uncommitted 
order?  The order gets a URI on the server.  

I'm not saying you would always want to do it that way - given the 
percentage of abandoned shopping baskets - but wouldn't be a RESTful 
alternative?

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1399
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-04 14:47:25
Subject:REST transaction idea
Message:

State-Alignment Transaction Model
AKA RosettaNet/ebXML/UNCEFACT Business Transactions

This transaction model was first published for RosettaNet (as far as 
I know). But I understand that it came from telecom practices. 
I think it is also very similar to some previous work on consensus.  
But I am not an expert in transaction or consensus theory.

I just know that this transaction model has been used fairly widely 
in real electronic commerce by real companies (e.g. Intel and 
Siemens). It is also the simplest Web transaction model I have seen, 
and seems to me to be RESTifiable.

First I'll describe the model in its native form, and then consider 
RESTificiation.

RosettaNet transactions use something like EDI-mailbox-style SOAP.
It's a peer-to-peer interaction between two business activities, 
hidden behind business services (service access points) with 
dispatchers directing messages to the business activities. 
It's not actually SOAP, but ebXML adopted the same transaction model 
and does use SOAP.

It's not REST because the business entities (whose states are to be 
aligned) are hidden behind the service access point and dispatcher.  

But I think that the EDI-mailbox-style is a RosettaNet+ebXML 
implementation detail.

UN/CEFACT has a metamodel for this transaction model that claims to 
be technology-neutral. So if the transaction model is not 
RESTifiable, UN/CEFACT might be concerned.

The basics of the transaction model:

It's a two-party request-response interaction, with receipt 
acknowledgements for both request and response.
The interactions are between a requesting business activity and a 
responding business activity.
UN/CEFACT describes five different patterns for different kinds of 
business interactions.
I will consider only one pattern here which is most applicable to 
Offer-Acceptance, the business protocol for contract formation and 
order placement.

In an Offer-Acceptance state-alignment transaction consists of these 
steps:
1. The requesting activity sends an Offer document to the responding 
activity via the responding business service.
2. The responding  business service sends back a receipt 
acknowledgment for the Offer document, or an error message.  If an 
error message, the transaction fails with a Control Failure. In some 
cases, there can be two acknowledgments or possible points of error: 
the first for schema validation, the second for business rules.  
UN/CEFACT, ebXML and RosettaNet V1.0 require both; RosettaNet V2.0 
only requires one.
3. The responding business activity does whatever it needs to do to 
decide whether it can fill the order or not.  It then sends back a 
Response document that says it either Accepts or Rejects (declines) 
the offer.  If Rejection, the transaction fails with a Contract 
Failure.
4. The requesting business service sends back a receipt 
acknowledgment for the Response document, or an error message.  If an 
error message, the transaction fails with a Control Failure.

If the Response document says "Accept" and there were no error 
messages, the transaction succeeds.

There are time constraints on each step.  If any timeout occurs, the 
transaction fails with a Control Failure.

In cases where the Response document says "Accept" but has an error, 
and the error message from the requesting business service cannot be 
delivered, the transaction model specifies a separate Notification of 
Failure to be sent from the requesting business service via another 
channel.  Otherwise the responding activity may think incorrectly 
that the transaction succeeded.

State Alignment:

There are two levels of state alignment in this transaction model:
1. The state of the transaction, aligned between the requesting and 
responding business activities, where the events that trigger state 
transitions are the requesting and responding documents, receipt 
acknowledgments and/or error messages.
2. The state of the business entity being offered, for example an 
Order. Example states might include Offered, Accepted and Rejected  
The event that triggers a state transition in the Order is the end of 
the transaction.  If the transaction succeeds, the Order transitions 
to the Accepted state.  If the transaction fails with a Contract 
Failure. the Order transitions to the Rejected state. If the 
transaction fails with a Control Failure, the Order stays in the 
Offered state.

Restification:

I'll stick with a peer-to-peer configuration because it is most like 
the source.  But I think the same underlying principles apply to a 
client-service configuration, although only the Web resource for the 
business entity will exist only on the server side.

Replace the business service access points with resources 
representing the business entity being offered, for example the 
Order.  (Alternatively, each transaction might become a sub-resource 
under the Order.)

RosettaNet and ebXML assume that a business service access point will 
handle many transactions for many business activities, so each 
message contains tags for dispatching to the business collaboration 
(long conversation about the Order), business transaction, and 
business activity.

If the resource is the Order, then only the business transaction and 
business activity tags are required.
If the resource is the Transaction, then the business activity can be 
assumed.

In either case, I think the REST style is functionally equivalent to 
the EDI-mailbox style, but has at least two advantages:
1. the business entities and transaction results are Web resources, 
and
2. the "service access point" is finer-grained.

I assume the members of this list understand some of the advantages 
of #1.  If not, and there's interest, I could expand  and of course 
help is always appreciated.

There is a lot more to the transaction model  mostly about security 
issues.  But I think those are also functionally equivalent between a 
REST and EDI-mailbox style.

So what do you all think?  Does this have promise for fulfilling the 
business transaction requirement for REST?  Should I post it on the 
rest-wiki?

What else is required or would be nice to add?

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:1400
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-04 15:20:37
Subject:Re: [rest-discuss] Re: RESTful shopping basket
Message:

On Tue, Jun 04, 2002 at 10:39:30AM -0400, bhaugen32 wrote:
> Mark Baker wrote:
> > So if you wanted to do a shopping basket statelessly, it's up to the
> > client to manage that the state of the basket, submitting a
> > representation of the basket to the server when it wants to 
> checkout.
> 
> Why couldn't the shopping basket be kept on the server, with a 
> customer-specific URI?  Why is it any different than an uncommitted 
> order?  The order gets a URI on the server.  
> 
> I'm not saying you would always want to do it that way - given the 
> percentage of abandoned shopping baskets - but wouldn't be a RESTful 
> alternative?

There are cases when you'd want this, for example when the shopping
basket did things very specific to the app.  But generally, I don't
think that shopping baskets do very much at all, and could be
generalized to some dumb client-side container in which the
representations of the things you want are placed.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1401
Sender:Chuck Hinson <hinson@...>
Post Date/Time:2002-06-04 15:49:55
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

Allan Doyle wrote:
> 
> Cookies are out of band as far as REST is concerned, and are
> downright anti-REST because you will probably never see the cookie
> contents but those contents are responsible for a ton of information
> transfer between client and server. If you moved the cookie info to a
> URI-accessible location, then it would be RESTful. A big issue with
> current practice (not with HTTP or REST) is that usually clients don't
> have HTTP servers running in them or on their behalf so the server
> can't get at client-side state with a simple GET. (c.f. the
> "client-side shopping basket" statement above). This asymmetry also
> impacts the ability to do decent asynchronous callbacks from the
> server to the client.
> 

I've been struggling with authentication/authorization and how to fit it 
into the REST model...

I'm probably confusing several issues (and I'm probably unaware of others), 
but it seems very difficult to provide authentication and authorization 
without cookies or some similar mechanism - and I'm not sure I see a 
solution that doesn't just shift the problem (state-hiding) somewhere else.

In all the examples I've seen, the resources are assumed to be publicly 
accessible.  In the example above, the suggestion is to move the hidden 
state stored in a cookie to a URI-accessible location.  However, once I've 
done that, I would think that I am then obliged to ensure that only the user 
who owns that information is able to retrieve it.  How do I do that if I 
cant also issue the user a token (cookie) that they can then use as proof of 
identity?

My first thoughts were that you could use HTTPS with client certs to provide 
identity, but it seems that you've only shifted the problem around.  Instead 
of providing proof of identity with a cookie, your providing it with a 
certificate.  Or maybe using a cookie for authentication doesnt violate the 
no-hidden-state rule.

--Chuck







-----------------------------------------------------------------------------------
Post ID:1402
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-04 16:12:49
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

On Tue, Jun 04, 2002 at 11:49:55AM -0400, Chuck Hinson wrote:
> I've been struggling with authentication/authorization and how to fit it
> into the REST model...

It's already there, with HTTP authentication.

A 401 response to a HTTP request tells the client to provide a header
with the authentication info, next time it does that request.  On
subsequent requests, that header is always included, making the
interaction stateless.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1403
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-06-04 16:48:21
Subject:RE: [rest-discuss] Cookies not RESTful - need explaination
Message:

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> -----Original Message-----
> From: Roger L. Costello [mailto:costello@...] 
> Sent: 04 June 2002 13:29
> To: rest-discuss@yahoogroups.com; costello@...
> Subject: [rest-discuss] Cookies not RESTful - need explaination
> 
> 
> Hi Folks,
> 
> Below is an except from Fielding's REST dissertation, 
> describing why cookies are not RESTful.  Can someone explain 
> what he is saying here?
> 
> "Likewise, the use of cookies to identify a user-specific 
> 'shopping basket' within a server-side database could be more 
> efficiently implemented by defining the semantics of shopping 
> items within the hypermedia data formats, allowing the user 
> agent to select and store those items within their own 
> client-side shopping basket, complete with a URI to be used 
> for check-out when the client is ready to purchase."

He wants you to store the basket details on the client using URIs
to manage the representations. The cost is coordinating client and
server software. I imagine that cost would less if the client could
also act as a server, i.e. you could get at the basket using HTTP
methods. It would be efficient insofar as you'd stop routing around
your local CPU to do processing on the server's. Cookies may not be
restful, but the more appealing argument to some might be that they
could throw away their enterprise class web server infrastructure,
load balancers et al and apportion some of the costs to the client.
I haven't heard an argument for rest based on reducing server side
costs, it would be an interesting one.

Bill

 

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPPzvUuaWiFwg2CH4EQLwzwCgiY4ZxB7zVXpORPRBiKWcumiFUd4AoJl4
7IZp/H7jS9Ne4clLuCChzSB8
=C8E3
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:1404
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-04 16:54:31
Subject:What does stateless mean?
Message:

If a client makes a request of  a server which has information from a
prior request (e.g., session ID) is that request stateful or stateless?
Aren't HTTP requests by definition "stateless", and it is the
server-side application which maintains state information (e.g,, session
ID) to simulate a (stateful)  connection.  I guess that I need a real
concrete definition of what stateless means.

Lucas Gonze wrote:

> So instead of:
> GET /someresource
> session-state-store-on-client: mynameis=slimshady
>
> use:
> GET /slimshady/someresource

Why is it that putting information in the HTTP header is not RESTful,
whereas putting information in a URL is RESTful?  /Roger








-----------------------------------------------------------------------------------
Post ID:1405
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-04 17:48:05
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>
>
> You know that cookies are stateful, right?  That is, they make it so
> that there isn't enough information in the HTTP message to understand
> what it does, because it depends on the information represented by
> the cookie which is invisible to everybody but the server.
I'm confused - a cookie is part of the HTTP message, both request and
response.
The client can read and write them and so can the server.
And anyway, combining information from the request and server-only state
isn't a bad thing - security permissions, etc. do this all the time.

The problem I have is that they are often used to qualify the URI - for
example
http://my.example.org/startpage.asp is the same URI for everyone, but the
page - the 'actual' resource - is different based on the value of the
cookie. This makes the sample URI unsharable, uncacheable, etc. - which is
good or bad depending on what you are trying to do.
They are also often used to identify the user, or at least a user's
server-side session.








-----------------------------------------------------------------------------------
Post ID:1406
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-04 18:03:49
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

----- Original Message -----
From: "Chuck Hinson" <hinson@...>

>
> In all the examples I've seen, the resources are assumed to be publicly
> accessible.
The examples I write have the assumption that permissions exist on the
server for the resources.
Any message that has a cookie in it can be captured and re-played with the
cookie intact, so the message itself is just as 'public' as the URI only.

> In the example above, the suggestion is to move the hidden
> state stored in a cookie to a URI-accessible location.
I wouldn't call it 'state' that is in the cookie, the data usually is used
as values for lookup on the server side.

> However, once I've
> done that, I would think that I am then obliged to ensure that only the
user
> who owns that information is able to retrieve it.
Yes, that would be a good thing.

> How do I do that if I cant also issue the user a token (cookie)
> that they can then use as proof of identity?
This token isn't proof of identity. It can be captured, copied, and replayed
elsewhere. Cookie based approaches are just breaking the URI into two pieces
and hoping that the Bad Guys don't capture both pieces. Since that is not
doable, people make one piece very transient, which only reduces the window
of opportunity.
Now that I think about it, using HTTPS would minimize the chance that other
people will find the cookie.

>
> My first thoughts were that you could use HTTPS with client certs to
provide
> identity, but it seems that you've only shifted the problem around.
Instead
> of providing proof of identity with a cookie, your providing it with a
> certificate.  Or maybe using a cookie for authentication doesnt violate
the
> no-hidden-state rule.
>
I think there is an interesting design question here regarding coordination
costs of establishing trust:
 - server provides tokens for identity
 - client provides tokens for identity

I'll have to think about this for a while.








-----------------------------------------------------------------------------------
Post ID:1407
Sender:Chuck Hinson <hinson@...>
Post Date/Time:2002-06-04 18:56:21
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

Mark Baker wrote:
> On Tue, Jun 04, 2002 at 11:49:55AM -0400, Chuck Hinson wrote:
> 
>>I've been struggling with authentication/authorization and how to fit it
>>into the REST model...
> 
> 
> It's already there, with HTTP authentication.
> 
> A 401 response to a HTTP request tells the client to provide a header
> with the authentication info, next time it does that request.  On
> subsequent requests, that header is always included, making the
> interaction stateless.
> 

Hmm.  I guess I already knew that.  However, the lack of support by browsers 
for anything other than Basic Auth pretty much eliminates the Authorization 
header as a solution today.  (Once again, reality interferes...)

Given that, it would seem that using a cookie for authentication is a 
reasonable alternative -- the spec say use the Authorization header; 
browsers and servers dont support that very well, so I'll use a header that 
they do support and that happens to be a cookie.

--Chuck


> MB








-----------------------------------------------------------------------------------
Post ID:1408
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-04 19:22:15
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

On Tue, Jun 04, 2002 at 01:48:05PM -0400, S. Mike Dierken wrote:
> I'm confused - a cookie is part of the HTTP message, both request and
> response.

Yes, but the information necessary to understand what a message with
a cookie means, is not part of the message.

GET /foo HTTP/1.1

has one meaning for all time, which you can lookup in RFC 2616.

GET /foo HTTP/1.1
Cookie: bar=goo

can have many meanings depending upon what magic that cookie induces
in the behaviour of the server.  You can't look up what it means
anywhere.

> The problem I have is that they are often used to qualify the URI - for
> example
> http://my.example.org/startpage.asp is the same URI for everyone, but
> the
> page - the 'actual' resource - is different based on the value of the
> cookie. This makes the sample URI unsharable, uncacheable, etc. - which
> is
> good or bad depending on what you are trying to do.
> They are also often used to identify the user, or at least a user's
> server-side session.

Right, that's a special case of the problem I described above; if you
allow a message's meaning to change (be it the identified-resource, the
authorization info, etc..) depending upon information not in the message
itself, then you can very easily do the Wrong Thing.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1409
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-04 21:47:41
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

Mark Baker wrote:
> 
>...
> 
> Right, that's a special case of the problem I described above; if you
> allow a message's meaning to change (be it the identified-resource, the
> authorization info, etc..) depending upon information not in the message
> itself, then you can very easily do the Wrong Thing.

I think you mean "information in the message or *REFERENCED* by the
message through a derferencerable URI." Am I right? For instance it is
not wrong for a "purchase now" message to point to a shopping cart URI.
As long as the two do not change you could understand that message a
hundred years from now on a totally different device.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1410
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-04 23:16:47
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

Mark Baker wrote:
> 
> On Tue, Jun 04, 2002 at 01:48:05PM -0400, S. Mike Dierken wrote:
> > I'm confused - a cookie is part of the HTTP message, both request and
> > response.
> 
> Yes, but the information necessary to understand what a message with
> a cookie means, is not part of the message.
> 
> GET /foo HTTP/1.1
> 
> has one meaning for all time, which you can lookup in RFC 2616.
> 
> GET /foo HTTP/1.1
> Cookie: bar=goo
> 
> can have many meanings depending upon what magic that cookie induces
> in the behaviour of the server.  You can't look up what it means
> anywhere.

Let me see if I understand what you are saying Mark: if the HTTP header
contains information (e.g., cookie information) that is used by the
server application then that is not RESTful.  However, if we were to
move the (e.g., cookie) information into the HTTP message body, then it
would be RESTful.  Is that it?  That doesn't seem reasonable since the
HTTP header contains a lot of information that a server application will
typically use, such as the content type that the client will accept
(e.g., text/html), and many other things.  These HTTP headers induces
behaviour in the server application.  Taking this argument to its
logical conclusion, then I conclude that no HTTP message can ever be
RESTful, unless it has no HTTP headers, since HTTP headers by their very
nature induces behaviour in the server application.  Yes?

To restate my earlier question: what exactly does it mean to be
stateless?  In light of the above, does it mean that all information is
carried in the HTTP message body?  That is, the server application's
behaviour is not influenced by anything in the HTTP header?

Sorry to be so dense on this.  However, I feel that it is a critical
issue that I want to make certain I fully understand as I go out into
the world to preach the merits of REST.  /Roger







-----------------------------------------------------------------------------------
Post ID:1411
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-04 22:34:17
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

On Tue, Jun 04, 2002 at 02:47:41PM -0700, Paul Prescod wrote:
> > Right, that's a special case of the problem I described above; if you
> > allow a message's meaning to change (be it the identified-resource, the
> > authorization info, etc..) depending upon information not in the message
> > itself, then you can very easily do the Wrong Thing.
> 
> I think you mean "information in the message or *REFERENCED* by the
> message through a derferencerable URI." Am I right?

No, in the message itself.  If the meaning of the message depends
on information you get from dereferencing a URI (or anything else
outside the message), then it is stateful.

> For instance it is
> not wrong for a "purchase now" message to point to a shopping cart URI.
> As long as the two do not change you could understand that message a
> hundred years from now on a totally different device.

Right, because the meaning of "purchase this shopping cart now" doesn't
depend on what you get by dereferencing the shopping cart URI.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1412
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-05 00:02:52
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

----- Original Message -----
From: "Chuck Hinson" <hinson@...>

>
> Hmm.  I guess I already knew that.  However, the lack of support by
browsers
> for anything other than Basic Auth pretty much eliminates the
Authorization
> header as a solution today.  (Once again, reality interferes...)
The systems I'm envisioning go way beyond the browser - and then the full
potential of HTTP is available. Build a different user agent, or if you
really must, use components that do provide full HTTP access
(IXMLHTTPRequest in IE and others).

>
> Given that, it would seem that using a cookie for authentication is a
> reasonable alternative -- the spec say use the Authorization header;
> browsers and servers dont support that very well, so I'll use a header
that
> they do support and that happens to be a cookie.
It isn't reasonable, but there is little alternative. I'm amazed the browser
world has gone this long without extending FORM to support users entering
credentials.
A big reason sites use FORMs is to control the UI. It shouldn't be a big
deal to for FORM to specify that it is user input for credentials at the
specified URI.






-----------------------------------------------------------------------------------
Post ID:1413
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-05 01:27:16
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

On Tue, Jun 04, 2002 at 07:16:47PM -0400, Roger L. Costello wrote:
> Let me see if I understand what you are saying Mark: if the HTTP header
> contains information (e.g., cookie information) that is used by the
> server application then that is not RESTful.

No ...

>  However, if we were to
> move the (e.g., cookie) information into the HTTP message body, then it
> would be RESTful.  Is that it?

Hmm, no.  By "message", I mean the entire HTTP message; request line,
headers, and body.

Think about taking an HTTP message, and storing it to disk for 20
years.  When you "reconstitute" it at that time, will people still
know what it means?  If it used cookies, they won't, because some
information necessary to understanding it was on the server, and it
expired years ago.

Compare it to FTP, if that helps.  If I pickle the (logical) command
"RETR foo.zip" to disk, and reconstitute it 10 minutes later, nobody
will know what it means because they don't know what the current
directory is, and hence which foo.zip to retrieve.  FTP is a stateful
protocol.

> Sorry to be so dense on this.  However, I feel that it is a critical
> issue that I want to make certain I fully understand as I go out into
> the world to preach the merits of REST.  /Roger

It's definitely a critical issue, as statelessness is so key to
visibility and reliability.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1414
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-06-05 13:06:35
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

Some thoughts...


> behaviour in the server application.  Taking this argument to its
> logical conclusion, then I conclude that no HTTP message can ever be
> RESTful, unless it has no HTTP headers, since HTTP headers by their very
> nature induces behaviour in the server application.  Yes?


An HTTP message can certainly be RESTful.  You can accomplish this by 
correctly using a URI to reference a real, true object.  The headers can 
still be there, and are very helpful as metadata and instructions on how 
to handle the message itself.

For instance, REST likes to transfer state of objects.  But, some 
objects can be represented many different ways.  For example, a daily 
report can be represented as a PDF, HTML, XML, etc.  That's just the 
physical form.  The logical object itself is the same.  Now, this object 
might have a URI of http://example.org/finance/report/2002/06/05.  Using 
that URI, I can GET and SET that report throughout time and space.  But 
how do I know what I'm getting?  HTTP is the protocol we're using, so 
HTTP headers are introduced.  Think of the headers like the envolope. 
They tell us more info about the resource.  That info isn't needed to 
identify the object (that's done with the URI).  So the HTTP header will 
say "Content-type: application/pdf" to indicate what bytes are being 
sent.  This doesn't violate REST (IMO) since we haven't obfuscated the 
object identifier.


> To restate my earlier question: what exactly does it mean to be
> stateless?  In light of the above, does it mean that all information is
> carried in the HTTP message body?  That is, the server application's
> behaviour is not influenced by anything in the HTTP header?

It might help for your understanding of REST to divorce yourself from 
HTTP a bit.  REST is a paradigm and a set of patterns.  HTTP can be used 
for an implementation of REST, but isn't the perfect embodiment of REST.

To be stateless means to carry all information needed for the request 
along with the request.  That request must be able to stand alone.  If 
the process requires three messages in a certain order, each depending 
on the first one, that is not stateless.

Hope I didn't confuse things more. :)

Seth







-----------------------------------------------------------------------------------
Post ID:1415
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-05 13:12:53
Subject:RE: [rest-discuss] Cookies not RESTful - need explaination
Message:

[snip]
Seth wrote:
> HTTP headers are introduced.  Think of the headers like the envolope.

For obvious reasons, any mention of the word "envelope" in RESTful discussions
makes me shudder....gives me nightmares where employees from Microsoft and IBM
force-feed me bars of soap until I wake up in a cold sweat ;-)

-Philip







-----------------------------------------------------------------------------------
Post ID:1416
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-06-05 13:28:59
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

Philip Eskelin wrote:
> [snip]
> Seth wrote:
> 
>>HTTP headers are introduced.  Think of the headers like the envolope.
> 
> 
> For obvious reasons, any mention of the word "envelope" in RESTful discussions
> makes me shudder....gives me nightmares where employees from Microsoft and IBM
> force-feed me bars of soap until I wake up in a cold sweat ;-)

Yeah, except SOAP can be used to communicate a RESTful protocol.  It's 
all about how you use the transport mechanism.

Seth








-----------------------------------------------------------------------------------
Post ID:1417
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-05 14:09:20
Subject:RE: [rest-discuss] Cookies not RESTful - need explaination
Message:

Seth wrote:
> Philip Eskelin wrote:
> > [snip]
> > Seth wrote:
> >
> > >HTTP headers are introduced.  Think of the headers like the envolope.
> >
> >
> > For obvious reasons, any mention of the word "envelope" in RESTful
discussions
> > makes me shudder....gives me nightmares where employees from Microsoft and
IBM
> > force-feed me bars of soap until I wake up in a cold sweat ;-)
>
> Yeah, except SOAP can be used to communicate a RESTful protocol.  It's
> all about how you use the transport mechanism.

I've always thought it would be interesting if someone sponsored a "tunneling
contest" to see who can tunnel the most protocols in the most creative fashion.
Someone might try to say "hello world" across a network by distributing dynamic
data exchange between windows on separate machines by taking a DDE execute
message and marshaling it as COM invocation using an RPC tunneled through
canonicalized, base 64-encoded XML-RPC messages communicated via a RESTful
implementation built with Python on SOAP running on HTTP implemented over
TCP/IP, where a proxy server sitting inside a firewall receives the request,
unmarshals each of its layers, and faxes the message to a gorilla who takes the
paper and feeds it into a scanner that performs OCR to interpret the message and
send it to a Windows desktop running a NetDDE server that dispatches the request
by writing the message to a temporary HTML file containing JavaScript loaded by
a web browser that displays the original "hello world" in a message box.

-Phil







-----------------------------------------------------------------------------------
Post ID:1418
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-05 14:53:36
Subject:Re: REST toolkits
Message:

"Philip Eskelin" wrote:
> I'm developing a REST toolkit 

Philip and anybody else who is developing REST toolkits please 
announce when something becomes available for use?  Either here or 
maybe better, start a rest-wiki page?

I'm not developing one, but would like to use one.

Thanks,
Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1419
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-05 15:08:41
Subject:RE: [rest-discuss] Re: REST toolkits
Message:

Bob,

Thanks for showing interest!  Originally, my toolkit wasn't officially REST.
But as I began to read RESTwiki and lurk on this group, I realized that my
design turned out to be very RESTful.  I'm also working on including
environmental acquisition [1], which I find complements REST *very* well.
They're a powerful combo.

I hesitate to say much until I've got a stable release, but I plan on announcing
availability as soon as possible.  Then, whether we mention it on RESTwiki or
create a separate wiki instance is fine with me.

My hope is that its availability will help us really see and be able to use
something that's concrete and helps us refine our notion of REST.

Thanks,
Philip

[1] http://www.ccs.neu.edu/home/lorenz/research/acquisition/

-----Original Message-----
From: bhaugen32 [mailto:bhaugen32@...]
Sent: Wednesday, June 05, 2002 10:54 AM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] Re: REST toolkits


"Philip Eskelin" wrote:
> I'm developing a REST toolkit

Philip and anybody else who is developing REST toolkits please
announce when something becomes available for use?  Either here or
maybe better, start a rest-wiki page?

I'm not developing one, but would like to use one.

Thanks,
Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1420
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-05 17:53:24
Subject:RE: [rest-discuss] Re: REST toolkits
Message:

Scott wrote:
> Our company is in kind of the same boat WRT REST. We started
> building our product back in spring of 2000, and now we're
> finding out that we've incorporated a lot of RESTful features.
> At the moment we're working on putting together a developer
> release for people to play with until we can get to a Beta
> release.

That's great.  We should try to provide a place on RESTwiki (if it doesn't
already exist) that starts to collect references to some of these efforts.  I
feel like I'm at the same location in development as you are, so it will be
interesting to share our interpretations of REST once the work goes public.

-Philip







-----------------------------------------------------------------------------------
Post ID:1421
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-06-06 19:22:36
Subject:Re: Re[2]: [rest-discuss] HTTP caching questions ?
Message:

/me catches up on this list

What Web server are you using? Is the content generated, or just on disk?

This problem (load balancing vs. ETag generation) was recognized a while
back, and I know that Apache has recently put a fix in (but IIRC you have
to explicitly configure the behaviour). Depending on your situation, there
are a number of ways to approach the problem.

Cheers,


----- Original Message -----
From: "Simon Fell" <sf@...>
To: <rest-discuss@yahoogroups.com>
Sent: Sunday, May 19, 2002 1:58 PM
Subject: Re[2]: [rest-discuss] HTTP caching questions ?


> ok, here goes.
>
> Basically i need to support efficient checks that content is upto
> date, and to also support resumable downloads [some of the content is
large
> binary files accessed via a potentially un-reliable low bandwidth
> connection]. This content is potentially served by a set of web servers
> running behind a HTTP load balancer.
>
> For a single server scenario, this seems pretty straightforward, At
> the client cache I track expected size [from the content-length
> header], Etag and last-modified. for subsequent requests I populate a
> If-None-Match header from the etag, a Range & Range-If header if the
> expected size is not the same as the cached file size, and i send a
> If-Modified-Since header if i don't have a Range header [my reading of
> the use of Range & Range-If lead me to believe to not use
> If-Modified-Since if i'm using ranges].
>
> My concern is when i have 2 or more web servers, all running behind a
> load balancer [local director etc], that each server will be assigning
> different etags to the same content (i don't see anything in the spec
> that lets me assume different server instances will generate the same
> etag for the same content, even for the same versions of HTTP server
> software). This is leading me to think about not using etags, and to
> just use the modified date, but then it doesn't look like you can do
> ranges with modified dates. Its also crossed my mind to use
> content-md5, but this doesn't seem very widely support [if at all].
>
> Any suggestions ?
>
> Thanks
> Simon
>
> Saturday, May 18, 2002, 1:50:51 PM, you wrote:
>
> > I think it would be great if you asked the questions here. I am not
> > "deep" in HTTP cacheing but I know that Mark Nottingham is and I
suspect
> > Mark Baker knows quite a bit also. This list seems to be the last
refuge
> > of people who don't think of HTTP as a dinosaur ;).
>
> > simonfell99 wrote:
> >>
> >> Hi,
> >>
> >> I'm in the process of prototyping a REST version of an existing RPC
> >> based system, a large chunk of this system revolves around
> >> efficiently managing updates to content at the client system. I'm
> >> looking at using the HTTP/1.1 caching support (Etag, If-Modified-
> >> Since, If-None-Match and If-Range). I have some questions about how
> >> this works when deployed on a cluster of servers with a load
> >> balancer, is this a good place to ask, or can someone recommend a
> >> good list to discuss HTTP caching.
> >>
> >> Tx
> >> Simon
> >>
> >>
> >> To unsubscribe from this group, send an email to:
> >> rest-discuss-unsubscribe@yahoogroups.com
> >>
> >>
> >>
> >> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:1422
Sender:Simon Fell <sf@...>
Post Date/Time:2002-06-07 02:09:51
Subject:Re[4]: [rest-discuss] HTTP caching questions ?
Message:

Thanks Mark,

I'm using Apache, I found the info about the directives that control
the etag generation, and am in the process of getting some servers
updated so i can test this out.

I was hoping to find a solution that wasn't reliant on specific
behavior in the web server, but couldn't come up with anything.

The content is generated, but due to the way the generation process
works, its static files as far as the web server is concerned.

Cheers,
Simon                            

Thursday, June 06, 2002, 12:22:36 PM, you wrote:

> /me catches up on this list

> What Web server are you using? Is the content generated, or just on disk?

> This problem (load balancing vs. ETag generation) was recognized a while
> back, and I know that Apache has recently put a fix in (but IIRC you have
> to explicitly configure the behaviour). Depending on your situation, there
> are a number of ways to approach the problem.

> Cheers,


> ----- Original Message -----
> From: "Simon Fell" <sf@...>
> To: <rest-discuss@yahoogroups.com>
> Sent: Sunday, May 19, 2002 1:58 PM
> Subject: Re[2]: [rest-discuss] HTTP caching questions ?


>> ok, here goes.
>>
>> Basically i need to support efficient checks that content is upto
>> date, and to also support resumable downloads [some of the content is
> large
>> binary files accessed via a potentially un-reliable low bandwidth
>> connection]. This content is potentially served by a set of web servers
>> running behind a HTTP load balancer.
>>
>> For a single server scenario, this seems pretty straightforward, At
>> the client cache I track expected size [from the content-length
>> header], Etag and last-modified. for subsequent requests I populate a
>> If-None-Match header from the etag, a Range & Range-If header if the
>> expected size is not the same as the cached file size, and i send a
>> If-Modified-Since header if i don't have a Range header [my reading of
>> the use of Range & Range-If lead me to believe to not use
>> If-Modified-Since if i'm using ranges].
>>
>> My concern is when i have 2 or more web servers, all running behind a
>> load balancer [local director etc], that each server will be assigning
>> different etags to the same content (i don't see anything in the spec
>> that lets me assume different server instances will generate the same
>> etag for the same content, even for the same versions of HTTP server
>> software). This is leading me to think about not using etags, and to
>> just use the modified date, but then it doesn't look like you can do
>> ranges with modified dates. Its also crossed my mind to use
>> content-md5, but this doesn't seem very widely support [if at all].
>>
>> Any suggestions ?
>>
>> Thanks
>> Simon
>>
>> Saturday, May 18, 2002, 1:50:51 PM, you wrote:
>>
>> > I think it would be great if you asked the questions here. I am not
>> > "deep" in HTTP cacheing but I know that Mark Nottingham is and I
> suspect
>> > Mark Baker knows quite a bit also. This list seems to be the last
> refuge
>> > of people who don't think of HTTP as a dinosaur ;).
>>
>> > simonfell99 wrote:
>> >>
>> >> Hi,
>> >>
>> >> I'm in the process of prototyping a REST version of an existing RPC
>> >> based system, a large chunk of this system revolves around
>> >> efficiently managing updates to content at the client system. I'm
>> >> looking at using the HTTP/1.1 caching support (Etag, If-Modified-
>> >> Since, If-None-Match and If-Range). I have some questions about how
>> >> this works when deployed on a cluster of servers with a load
>> >> balancer, is this a good place to ask, or can someone recommend a
>> >> good list to discuss HTTP caching.
>> >>
>> >> Tx
>> >> Simon
>> >>
>> >>
>> >> To unsubscribe from this group, send an email to:
>> >> rest-discuss-unsubscribe@yahoogroups.com
>> >>







-----------------------------------------------------------------------------------
Post ID:1423
Sender:Gordon Weakliem <gweakliem@...>
Post Date/Time:2002-06-07 03:36:58
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

>It might help for your understanding of REST to divorce yourself from 
>HTTP a bit. REST is a paradigm and a set of patterns. HTTP can be used 
>for an implementation of REST, but isn't the perfect embodiment of REST. 

Is it me, or does this sound strangely close to the thinking that brought about Don Box's notorious "HTTP is Dead" keynote?  Replace REST with SOAP in the last sentence, and what do you have?  Put another way, is there a meaningful non-HTTP implementation of REST out in the wild?  Sorry, but I really tripped on this statement.  Would anybody care to expand on it?  






-----------------------------------------------------------------------------------
Post ID:1424
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-07 03:42:46
Subject:Re: Re[4]: [rest-discuss] HTTP caching questions ?
Message:

> > ----- Original Message -----
> > From: "Simon Fell" <sf@...>

> >>
> >> My concern is when i have 2 or more web servers, all running behind a
> >> load balancer [local director etc], that each server will be assigning
> >> different etags to the same content (i don't see anything in the spec
> >> that lets me assume different server instances will generate the same
> >> etag for the same content, even for the same versions of HTTP server
> >> software).
If the server instances are behind a load balancer, then shouldn't both
appear to be a single 'server' in http-spec-land, and the intended behavior
is that the etag should match? In other words, the http spec does let you
assume that different machines behind a logical 'server' will provide the
same etag - but it doesn't assume that it is /easy/ to do that...








-----------------------------------------------------------------------------------
Post ID:1425
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-07 04:17:46
Subject:Re: [rest-discuss] Cookies not RESTful - need explaination
Message:

----- Original Message -----
From: "Gordon Weakliem" <gweakliem@...>

>
> Is it me, or does this sound strangely close to the thinking that brought
about Don Box's notorious "HTTP is Dead"
> keynote?  Replace REST with SOAP in the last sentence, and what do you
have?  Put another way, is
> there a meaningful non-HTTP implementation of REST out in the wild?
> Sorry, but I really tripped on this statement.  Would anybody care to
expand on it?

I think of SQL based systems as something with a lot of REST-like qualities.
They are much better at the jobs they were designed for than a REST based
system, but REST is better at jobs /it/ was designed for.







-----------------------------------------------------------------------------------
Post ID:1426
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-06-07 04:49:34
Subject:Re: Re[4]: [rest-discuss] HTTP caching questions ?
Message:

Do you mean that the content is generated and written to static files, or
that it's served by a process that runs in response to requests (e.g.,
CGI, PHP, etc.), but that the results are generally cacheable?


----- Original Message -----
From: "Simon Fell" <sf@...>
To: "Mark Nottingham" <mnot@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Thursday, June 06, 2002 7:09 PM
Subject: Re[4]: [rest-discuss] HTTP caching questions ?


> Thanks Mark,
>
> I'm using Apache, I found the info about the directives that control
> the etag generation, and am in the process of getting some servers
> updated so i can test this out.
>
> I was hoping to find a solution that wasn't reliant on specific
> behavior in the web server, but couldn't come up with anything.
>
> The content is generated, but due to the way the generation process
> works, its static files as far as the web server is concerned.
>
> Cheers,
> Simon
>
> Thursday, June 06, 2002, 12:22:36 PM, you wrote:
>
> > /me catches up on this list
>
> > What Web server are you using? Is the content generated, or just on
disk?
>
> > This problem (load balancing vs. ETag generation) was recognized a
while
> > back, and I know that Apache has recently put a fix in (but IIRC you
have
> > to explicitly configure the behaviour). Depending on your situation,
there
> > are a number of ways to approach the problem.
>
> > Cheers,
>
>
> > ----- Original Message -----
> > From: "Simon Fell" <sf@...>
> > To: <rest-discuss@yahoogroups.com>
> > Sent: Sunday, May 19, 2002 1:58 PM
> > Subject: Re[2]: [rest-discuss] HTTP caching questions ?
>
>
> >> ok, here goes.
> >>
> >> Basically i need to support efficient checks that content is upto
> >> date, and to also support resumable downloads [some of the content is
> > large
> >> binary files accessed via a potentially un-reliable low bandwidth
> >> connection]. This content is potentially served by a set of web
servers
> >> running behind a HTTP load balancer.
> >>
> >> For a single server scenario, this seems pretty straightforward, At
> >> the client cache I track expected size [from the content-length
> >> header], Etag and last-modified. for subsequent requests I populate a
> >> If-None-Match header from the etag, a Range & Range-If header if the
> >> expected size is not the same as the cached file size, and i send a
> >> If-Modified-Since header if i don't have a Range header [my reading
of
> >> the use of Range & Range-If lead me to believe to not use
> >> If-Modified-Since if i'm using ranges].
> >>
> >> My concern is when i have 2 or more web servers, all running behind a
> >> load balancer [local director etc], that each server will be
assigning
> >> different etags to the same content (i don't see anything in the spec
> >> that lets me assume different server instances will generate the same
> >> etag for the same content, even for the same versions of HTTP server
> >> software). This is leading me to think about not using etags, and to
> >> just use the modified date, but then it doesn't look like you can do
> >> ranges with modified dates. Its also crossed my mind to use
> >> content-md5, but this doesn't seem very widely support [if at all].
> >>
> >> Any suggestions ?
> >>
> >> Thanks
> >> Simon
> >>
> >> Saturday, May 18, 2002, 1:50:51 PM, you wrote:
> >>
> >> > I think it would be great if you asked the questions here. I am not
> >> > "deep" in HTTP cacheing but I know that Mark Nottingham is and I
> > suspect
> >> > Mark Baker knows quite a bit also. This list seems to be the last
> > refuge
> >> > of people who don't think of HTTP as a dinosaur ;).
> >>
> >> > simonfell99 wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I'm in the process of prototyping a REST version of an existing
RPC
> >> >> based system, a large chunk of this system revolves around
> >> >> efficiently managing updates to content at the client system. I'm
> >> >> looking at using the HTTP/1.1 caching support (Etag, If-Modified-
> >> >> Since, If-None-Match and If-Range). I have some questions about
how
> >> >> this works when deployed on a cluster of servers with a load
> >> >> balancer, is this a good place to ask, or can someone recommend a
> >> >> good list to discuss HTTP caching.
> >> >>
> >> >> Tx
> >> >> Simon
> >> >>
> >> >>
> >> >> To unsubscribe from this group, send an email to:
> >> >> rest-discuss-unsubscribe@yahoogroups.com
> >> >>
>







-----------------------------------------------------------------------------------
Post ID:1427
Sender:Simon Fell <sf@...>
Post Date/Time:2002-06-07 05:01:15
Subject:Re[6]: [rest-discuss] HTTP caching questions ?
Message:

The content is generated and written to a static file as part of a
separate process that happens before the HTTP requests start to occur.
The resulting static files are cachable.

At some future date the plan it to ditch the separate process, and
have the content generated dynamically in the HTTP server itself
[probably using servlets], the results of this are still cachable. I
assume in this case I'll have to handle etag validation myself in the
servlet.

Cheers,
Simon                            

Thursday, June 06, 2002, 9:49:34 PM, you wrote:

> Do you mean that the content is generated and written to static files, or
> that it's served by a process that runs in response to requests (e.g.,
> CGI, PHP, etc.), but that the results are generally cacheable?


> ----- Original Message -----
> From: "Simon Fell" <sf@...>
> To: "Mark Nottingham" <mnot@...>
> Cc: <rest-discuss@yahoogroups.com>
> Sent: Thursday, June 06, 2002 7:09 PM
> Subject: Re[4]: [rest-discuss] HTTP caching questions ?


>> Thanks Mark,
>>
>> I'm using Apache, I found the info about the directives that control
>> the etag generation, and am in the process of getting some servers
>> updated so i can test this out.
>>
>> I was hoping to find a solution that wasn't reliant on specific
>> behavior in the web server, but couldn't come up with anything.
>>
>> The content is generated, but due to the way the generation process
>> works, its static files as far as the web server is concerned.
>>
>> Cheers,
>> Simon
>>
>> Thursday, June 06, 2002, 12:22:36 PM, you wrote:
>>
>> > /me catches up on this list
>>
>> > What Web server are you using? Is the content generated, or just on
> disk?
>>
>> > This problem (load balancing vs. ETag generation) was recognized a
> while
>> > back, and I know that Apache has recently put a fix in (but IIRC you
> have
>> > to explicitly configure the behaviour). Depending on your situation,
> there
>> > are a number of ways to approach the problem.
>>
>> > Cheers,
>>
>>
>> > ----- Original Message -----
>> > From: "Simon Fell" <sf@...>
>> > To: <rest-discuss@yahoogroups.com>
>> > Sent: Sunday, May 19, 2002 1:58 PM
>> > Subject: Re[2]: [rest-discuss] HTTP caching questions ?
>>
>>
>> >> ok, here goes.
>> >>
>> >> Basically i need to support efficient checks that content is upto
>> >> date, and to also support resumable downloads [some of the content is
>> > large
>> >> binary files accessed via a potentially un-reliable low bandwidth
>> >> connection]. This content is potentially served by a set of web
> servers
>> >> running behind a HTTP load balancer.
>> >>
>> >> For a single server scenario, this seems pretty straightforward, At
>> >> the client cache I track expected size [from the content-length
>> >> header], Etag and last-modified. for subsequent requests I populate a
>> >> If-None-Match header from the etag, a Range & Range-If header if the
>> >> expected size is not the same as the cached file size, and i send a
>> >> If-Modified-Since header if i don't have a Range header [my reading
> of
>> >> the use of Range & Range-If lead me to believe to not use
>> >> If-Modified-Since if i'm using ranges].
>> >>
>> >> My concern is when i have 2 or more web servers, all running behind a
>> >> load balancer [local director etc], that each server will be
> assigning
>> >> different etags to the same content (i don't see anything in the spec
>> >> that lets me assume different server instances will generate the same
>> >> etag for the same content, even for the same versions of HTTP server
>> >> software). This is leading me to think about not using etags, and to
>> >> just use the modified date, but then it doesn't look like you can do
>> >> ranges with modified dates. Its also crossed my mind to use
>> >> content-md5, but this doesn't seem very widely support [if at all].
>> >>
>> >> Any suggestions ?
>> >>
>> >> Thanks
>> >> Simon
>> >>
>> >> Saturday, May 18, 2002, 1:50:51 PM, you wrote:
>> >>
>> >> > I think it would be great if you asked the questions here. I am not
>> >> > "deep" in HTTP cacheing but I know that Mark Nottingham is and I
>> > suspect
>> >> > Mark Baker knows quite a bit also. This list seems to be the last
>> > refuge
>> >> > of people who don't think of HTTP as a dinosaur ;).
>> >>
>> >> > simonfell99 wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> I'm in the process of prototyping a REST version of an existing
> RPC
>> >> >> based system, a large chunk of this system revolves around
>> >> >> efficiently managing updates to content at the client system. I'm
>> >> >> looking at using the HTTP/1.1 caching support (Etag, If-Modified-
>> >> >> Since, If-None-Match and If-Range). I have some questions about
> how
>> >> >> this works when deployed on a cluster of servers with a load
>> >> >> balancer, is this a good place to ask, or can someone recommend a
>> >> >> good list to discuss HTTP caching.
>> >> >>
>> >> >> Tx
>> >> >> Simon
>> >> >>
>> >> >>
>> >> >> To unsubscribe from this group, send an email to:
>> >> >> rest-discuss-unsubscribe@yahoogroups.com
>> >> >>
>>







-----------------------------------------------------------------------------------
Post ID:1428
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-06-07 05:48:39
Subject:Re: Re[6]: [rest-discuss] HTTP caching questions ?
Message:

That's probably the way to go. I had a hope in the back of my mind that
you could assign ETags using .htaccess, but some quick testing rules that
out.

If you want to generate and validate ETags, you might be interested in
cgi_buffer[1]; there isn't Java in there, but it may be useful as a
starting point.

1. http://www.mnot.net/cgi_buffer/



----- Original Message -----
From: "Simon Fell" <sf@...>
To: "Mark Nottingham" <mnot@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Thursday, June 06, 2002 10:01 PM
Subject: Re[6]: [rest-discuss] HTTP caching questions ?


> The content is generated and written to a static file as part of a
> separate process that happens before the HTTP requests start to occur.
> The resulting static files are cachable.
>
> At some future date the plan it to ditch the separate process, and
> have the content generated dynamically in the HTTP server itself
> [probably using servlets], the results of this are still cachable. I
> assume in this case I'll have to handle etag validation myself in the
> servlet.
>
> Cheers,
> Simon
>
> Thursday, June 06, 2002, 9:49:34 PM, you wrote:
>
> > Do you mean that the content is generated and written to static files,
or
> > that it's served by a process that runs in response to requests (e.g.,
> > CGI, PHP, etc.), but that the results are generally cacheable?
>
>
> > ----- Original Message -----
> > From: "Simon Fell" <sf@...>
> > To: "Mark Nottingham" <mnot@...>
> > Cc: <rest-discuss@yahoogroups.com>
> > Sent: Thursday, June 06, 2002 7:09 PM
> > Subject: Re[4]: [rest-discuss] HTTP caching questions ?
>
>
> >> Thanks Mark,
> >>
> >> I'm using Apache, I found the info about the directives that control
> >> the etag generation, and am in the process of getting some servers
> >> updated so i can test this out.
> >>
> >> I was hoping to find a solution that wasn't reliant on specific
> >> behavior in the web server, but couldn't come up with anything.
> >>
> >> The content is generated, but due to the way the generation process
> >> works, its static files as far as the web server is concerned.
> >>
> >> Cheers,
> >> Simon
> >>
> >> Thursday, June 06, 2002, 12:22:36 PM, you wrote:
> >>
> >> > /me catches up on this list
> >>
> >> > What Web server are you using? Is the content generated, or just on
> > disk?
> >>
> >> > This problem (load balancing vs. ETag generation) was recognized a
> > while
> >> > back, and I know that Apache has recently put a fix in (but IIRC
you
> > have
> >> > to explicitly configure the behaviour). Depending on your
situation,
> > there
> >> > are a number of ways to approach the problem.
> >>
> >> > Cheers,
> >>
> >>
> >> > ----- Original Message -----
> >> > From: "Simon Fell" <sf@...>
> >> > To: <rest-discuss@yahoogroups.com>
> >> > Sent: Sunday, May 19, 2002 1:58 PM
> >> > Subject: Re[2]: [rest-discuss] HTTP caching questions ?
> >>
> >>
> >> >> ok, here goes.
> >> >>
> >> >> Basically i need to support efficient checks that content is upto
> >> >> date, and to also support resumable downloads [some of the content
is
> >> > large
> >> >> binary files accessed via a potentially un-reliable low bandwidth
> >> >> connection]. This content is potentially served by a set of web
> > servers
> >> >> running behind a HTTP load balancer.
> >> >>
> >> >> For a single server scenario, this seems pretty straightforward,
At
> >> >> the client cache I track expected size [from the content-length
> >> >> header], Etag and last-modified. for subsequent requests I
populate a
> >> >> If-None-Match header from the etag, a Range & Range-If header if
the
> >> >> expected size is not the same as the cached file size, and i send
a
> >> >> If-Modified-Since header if i don't have a Range header [my
reading
> > of
> >> >> the use of Range & Range-If lead me to believe to not use
> >> >> If-Modified-Since if i'm using ranges].
> >> >>
> >> >> My concern is when i have 2 or more web servers, all running
behind a
> >> >> load balancer [local director etc], that each server will be
> > assigning
> >> >> different etags to the same content (i don't see anything in the
spec
> >> >> that lets me assume different server instances will generate the
same
> >> >> etag for the same content, even for the same versions of HTTP
server
> >> >> software). This is leading me to think about not using etags, and
to
> >> >> just use the modified date, but then it doesn't look like you can
do
> >> >> ranges with modified dates. Its also crossed my mind to use
> >> >> content-md5, but this doesn't seem very widely support [if at
all].
> >> >>
> >> >> Any suggestions ?
> >> >>
> >> >> Thanks
> >> >> Simon
> >> >>
> >> >> Saturday, May 18, 2002, 1:50:51 PM, you wrote:
> >> >>
> >> >> > I think it would be great if you asked the questions here. I am
not
> >> >> > "deep" in HTTP cacheing but I know that Mark Nottingham is and I
> >> > suspect
> >> >> > Mark Baker knows quite a bit also. This list seems to be the
last
> >> > refuge
> >> >> > of people who don't think of HTTP as a dinosaur ;).
> >> >>
> >> >> > simonfell99 wrote:
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> I'm in the process of prototyping a REST version of an existing
> > RPC
> >> >> >> based system, a large chunk of this system revolves around
> >> >> >> efficiently managing updates to content at the client system.
I'm
> >> >> >> looking at using the HTTP/1.1 caching support (Etag,
If-Modified-
> >> >> >> Since, If-None-Match and If-Range). I have some questions about
> > how
> >> >> >> this works when deployed on a cluster of servers with a load
> >> >> >> balancer, is this a good place to ask, or can someone recommend
a
> >> >> >> good list to discuss HTTP caching.
> >> >> >>
> >> >> >> Tx
> >> >> >> Simon
> >> >> >>
> >> >> >>
> >> >> >> To unsubscribe from this group, send an email to:
> >> >> >> rest-discuss-unsubscribe@yahoogroups.com
> >> >> >>
> >>
>







-----------------------------------------------------------------------------------
Post ID:1429
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-07 11:20:37
Subject:With SOAP the URI does not directly reference the resource, right?
Message:

I am having a debate with a colleague.  I am arguing that when SOAP is
used you POST to the SOAP server, and it then looks inside the SOAP
message to determine which application to delegate to.  Thus, when you
invoke a Web service the URI is to the SOAP server, not to the target
application (i.e., resource).  For example, if a company has deployed
three Web services then despite which Web service a client wishes to
invoke, the URI will always be the same, for example:

   http://www.parts-depot.com/soap/server

What differs, of course, is the contents of the SOAP message.  I argue
that this hiding of the identity of the target resource in the SOAP
message is a disadvantage of SOAP (one of the key disadvantages of
SOAP).  

My colleague argues that this is not true.  He says that a client can
provide the URI directly to the target Web service (resource), for
example:

   http://www.parts-depot.com/parts
   http://www.parts-depot.com/parts/part/00345
   http://www.parts-depot.com/parts/purchase-order

He claims that he has done this using WebLogic. Here's a quote from him: 

"We were able to have 2 web services on the same machines with different
URI, using WebLogic.

I haven't used WebLogic, so I can't verify his statement. 

Can someone settle this debate please?  /Roger







-----------------------------------------------------------------------------------
Post ID:1430
Sender:Holden Glova <dsafari@...>
Post Date/Time:2002-06-07 10:58:25
Subject:Representing URI's
Message:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

I have somewhat of dilemma with regard to representing URI's to resources in 
the data returned back to the client. I know I could use things like XLink or 
RDF (I have the theoretical howto, not practical knowledge) to represent the 
URI's in the data, but I am not sure what the point would be - perhaps 
someone can enlighten me and point me to some recommended starting points? I 
have searched the web for XLink and RDF stuff but it isn't really clear why I 
would do this.

Here is a small snippet of what I currently have:

<craft>
  <package name="package_name" uri="http://craft.org/package/package_name/">
    <homepage-url location="http://somehost.com" />
    <download-url location="http://somehost.com/ri.tgz" />
.....
  </package>
</craft>

Any pointers on this dilemma would be greatly appreciated, thank you in 
advance.

- -- 
Signed,
Holden Glova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9AJHR0X8w8X71zPcRAodvAJsGVi4loj2+FTKaDkGyQudTkrkoYACfXnOv
s6uvUKdqczoSvG2ycn4au7I=
=FgXK
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:1431
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-07 20:29:57
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

"Roger L. Costello" wrote:
> 
> I am having a debate with a colleague.  I am arguing that when SOAP is
> used you POST to the SOAP server, and it then looks inside the SOAP
> message to determine which application to delegate to.  

The protocol can only suggest, not enforce, a dispatching strategy.
Still, Sam Ruby and I discussed this issue a few weeks ago and we could
not come up with a simple, documented way (or at least a way that is
simply documented) to do dispatching to a logical resource in the
popular SOAP toolkits out there. 

>...
> My colleague argues that this is not true.  He says that a client can
> provide the URI directly to the target Web service (resource), for
> example:
> 
>    http://www.parts-depot.com/parts
>    http://www.parts-depot.com/parts/part/00345
>    http://www.parts-depot.com/parts/purchase-order
> 
> He claims that he has done this using WebLogic. Here's a quote from him:
> 
> "We were able to have 2 web services on the same machines with different
> URI, using WebLogic.

Sure, that latter statement is absolutely true. You can have ten web
services at ten URIs if you want. But let's say someone adds a purchase
order. Will WebLogic make it easy for software to accept SOAP POSTs to a
newly created URI? Or would it have to do something gross like tweaking
a configuration file or copying files around the file system. In other
words, do you have to trick it into supporting dynamically created
objects with new URIs or is it a native feature? SOAP won't stop you
from being more intelligent than the average SOAP service but most SOAP
toolkits will make it difficult or impossible.

And even if a single SOAP-based web service did the right thing, you
don't get the network effect if you are the only person who has figured
out how to trick the tools into doing what you want.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1432
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-07 21:12:03
Subject:Articulating REST
Message:

I would like to thank all those who have argued so eloquently, so
patiently the case of REST, both on the list groups and in articles, and
who have answered my oftentimes naive questions.  

I came across some wonderful wisdom lately, that I think has relevance
to the REST "cause".  There is an online e-book called the Wisdom of
Henry Hazlitt[1].  He is a delightful writer (his most famous book is
Economics in One Lesson, which is great!).  In one part of the e-book is
a transcript of a speech that he gave to an audience of economists.  He
talks about the free market, and why there is increasingly less openness
in the market.  He talks about how, when you're in the minority, it is
important to clearly, logically articulate your position.  Many people
on this list have done so.  You are to be applauded.  I intend on doing
my part in the upcoming weeks and months.  

Below is an excerpt from Henry Hazlitt's talk. /Roger

The Wisdom of Henry Hazlitt

Why are we drifting deeper and deeper into socialism and the dark night
of totalitarianism? Why have those of us who believe in human liberty
been so ineffective?

   "We Haven't Been Good Enough"

I am going to give what is no doubt a terribly oversimplified answer to
that question. In the first place, we are almost hopelessly outnumbered.
Our voices are simply drowned out in the general tumult and clamor. But
there is another reason. And this is hard to say, above all to an
audience of this sort, which contains some of the most brilliant writers
and minds in the fields of economics, of jurisprudence, of politics, not
only of this age but of any age. But the hard thing must be said that,
collectively, we just haven't been good enough. We haven't convinced the
majority. Is this because the majority just won't listen to reason? I am
enough of an optimist, and I have enough faith in human nature, to
believe that people will listen to reason if they are convinced that it
is reason. Somewhere, there must be some missing argument, something
that we haven't seen clearly enough, or said clearly enough, or,
perhaps, just not said often enough.

A minority is in a very awkward position. The individuals in it can't
afford to be just as good as the individuals in the majority. If they
hope to convert the majority they have to be much better; and the
smaller the minority, the better they have to be. They have to think
better. They have to know more. They have to write better. They have to
have better controversial manners. Above all, they have to
have far more courage. And they have to be infinitely patient.

[1] http://www.hazlitt.org/e-texts/wisdom/







-----------------------------------------------------------------------------------
Post ID:1433
Sender:Todd Boyle <tboyle@...>
Post Date/Time:2002-06-07 21:35:29
Subject:Re: [rest-discuss] Articulating REST
Message:

At 02:12 PM 6/7/02, Roger L. Costello quoted Henry Hazlitt,
[1] http://www.hazlitt.org/e-texts/wisdom/
>Why have those of us who believe in human liberty been so ineffective?
>
>    "We Haven't Been Good Enough"
>
>I am going to give what is no doubt a terribly oversimplified answer to
>that question. In the first place, we are almost hopelessly outnumbered.
>Our voices are simply drowned out in the general tumult and clamor. But
>there is another reason....collectively, we just haven't been good enough.

I think REST like many other technologies, is moving in the right
direction.  I'm an accountant, an economist really. Not a programmer.
As a user, I just look at software and ask, "does this give me a
net advantage, or disadvantage?"

But when non-programmers look at the entire range of verbs,
nouns, platforms, software objects, routing, business models,
tiers etc. there is a complete and total paralysis because
the permutations are so great.  Vendors of course, bundle many
decisions into their software product, service etc. having some
kind of resultant force vector that usually cuts too deep into
the users' sovereignty or advantage.

I have listed some of these "axes" of centralization/decentralization
on my website... comments welcome, hope this is useful.
http://www.gldialtone.com/P2PAxes.htm

In summary, whenever a particular technical or functional requirement
is served most economically by centralization, a transfer of business
advantage (asymmetry of benefit) needs to be avoided by some means,

TOdd










-----------------------------------------------------------------------------------
Post ID:1434
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-07 22:01:51
Subject:Re: [rest-discuss] REST transaction idea
Message:

Argh. Lost my try at this to a mailer crash. :(

Okay, let's first define transactions in the context of this discussion
because people often mean different things. You do not mean transaction
in the sense of requiring "a group of operations on (distributed)
resources be treated as one unit of work. In a unit of work, all the
participating operations should either succeed or fail and recover
together." 

*
http://www.subrahmanyam.com/articles/transactions/NutsAndBoltsOfTP.html

Rather you mean transaction in the business sense, which is an agreement
to exchange services, products or money.

Now thinking about this from an XP perspective, I want to think about
the simplest thing and see why it won't work. The simplest thing is for
me to send you an "offer" message and you reply with "accept" or
"decline". That's not good enough, however, because deciding whether to
accept may take a long time. So it is necessary for the exchange to be
broken into two parts: "request service" and then at some indeterminate
time later, "provide response". In other words there are four messages: 

bhaugen32 wrote:
> 
>...
> 
> It's a two-party request-response interaction, with receipt
> acknowledgements for both request and response.

"Can we do business?"
"I acknowledge that you want to do business. I will get back to you."
"I agree/disagree we should do business."
"I acknowledge your agreement/disagreement."

>...
> 
> There are time constraints on each step.  If any timeout occurs, the
> transaction fails with a Control Failure.

Note that in the absence of reliable transport it is still possible for
the businesses to end up misaligned. An HTTP-based solution needs to use
HTTP in a manner that will ensure reliability.

> In cases where the Response document says "Accept" but has an error,
> and the error message from the requesting business service cannot be
> delivered, the transaction model specifies a separate Notification of
> Failure to be sent from the requesting business service via another
> channel.  Otherwise the responding activity may think incorrectly
> that the transaction succeeded.

I see, so otherwise it is to assume the transaction succeeded if it
returns an Accept, whether it gets a receipt or not?

>...
> Replace the business service access points with resources
> representing the business entity being offered, for example the
> Order.  (Alternatively, each transaction might become a sub-resource
> under the Order.)
> 
> RosettaNet and ebXML assume that a business service access point will
> handle many transactions for many business activities, so each
> message contains tags for dispatching to the business collaboration
> (long conversation about the Order), business transaction, and
> business activity.

You'll have to describe why all of these levels of statefulness are
necessary. And if you want to represent them in REST then you should
give them all URIs and point to them.

> If the resource is the Order, then only the business transaction and
> business activity tags are required.
> If the resource is the Transaction, then the business activity can be
> assumed.

Sounds stateful. Better to use references.

> In either case, I think the REST style is functionally equivalent to
> the EDI-mailbox style, but has at least two advantages:

Before I feel comfortable that this has been expressed in a REST style,
I'd like to see some URIs, XML and HTTP methods. ;)

I propose that what you will need is at least two HTTP request/response
pairs, one in each direction. To get reliability, though, you probably
actually need four, as I discuss here:

 * http://www.prescod.net/reliable_http.html

So you would 
	-> POST: "I'd like to make an offer"
	<- OK, here's an offer-holder URI
	-> PUT the offer at offer-holder URI
	<- OK, I've received it and will get back to you

The offer should have a callback address, unless you are using something
like HTTP events. Either way,

	<- POST "I'd like to return a reliable offer-response"
	-> OK, here's an offer-response-holder URI
	<- PUT the offer-response at the holder-URI
	-> OK, I've got the offer-response

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1435
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-06-07 22:38:18
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

You're both right ;)

It's certainly possible to hide "applications" behind a single URI in
SOAP, just as it is in other uses of the HTTP (think PowerPoint, some uses
of cookies, query args, etc.)

The trick is how you define "application" (or, more in tune with this
list, "resource"); it's a design-time philosophical question of how much
you want to expose.

For example, my car could have a URI*. The resource is the car, and it has
an identifier;
  http://www.mnot.net/2000/vw/golf/VIN1234567
How do I roll down the window? I could POST to the car with a body
containing something like
  part=leftwindow&action=rolldown
or I could expose a subresource
  http://www.mnot.net/2000/vw/golf/VIN1234567/window-left/
to POST a action=rolldown to.
Then again, I could expose
  http://www.mnot.net/2000/vw/golf/VIN1234567/window/left/
and do the same; this would allow me to perform actions on all of the
windows (such as "clean") by specifying "window", whilst still preserving
the subresource relationship between "window" and "left".
Being more specific, I could expose the position of the window as a
resource;
  http://www.mnot.net/2000/vw/golf/VIN1234567/window/left/position
which is quite RESTful.
Now, what if I wanted to wash only part of the window, say the inside?

Wait a minute, you say; if we reduce this argment to the absurd, every
atom (and atomic particle) in the window is potentially a resource. I am
very much reminded of my first year philosophy teacher; he introduced
himself to the class by asking us what a chair was. We replied, after some
hesitation, "that", accompanied by some pointing. Without repeating the
progression above, we got down to the point where an atom was in an
indeterminate state based on whether the chair was touching the floor or
not.

Back to SOAP (and hopefully a bit closer to reality), it's up to you as to
what you expose in the URI interface. If you want it to be interoperable
with applications that need to reference different subresources, that
would indicate the use of separate URIs. You can do this in any Web
Services environment; the only question is how much pain you have to put
up with to give different services different URIs. If you're happy with
the services that have to do with a car being available on the 'car' URI,
so be it; that's your choice, and it's just as much on the Web as the
other ones.


* This is the subject of some debate elsewhere, but let's assume it's true
;)


----- Original Message -----
From: "Roger L. Costello" <costello@...>
To: <rest-discuss@yahoogroups.com>; <costello@...>
Sent: Friday, June 07, 2002 4:20 AM
Subject: [rest-discuss] With SOAP the URI does not directly reference the
resource, right?


> I am having a debate with a colleague.  I am arguing that when SOAP is
> used you POST to the SOAP server, and it then looks inside the SOAP
> message to determine which application to delegate to.  Thus, when you
> invoke a Web service the URI is to the SOAP server, not to the target
> application (i.e., resource).  For example, if a company has deployed
> three Web services then despite which Web service a client wishes to
> invoke, the URI will always be the same, for example:
>
>    http://www.parts-depot.com/soap/server
>
> What differs, of course, is the contents of the SOAP message.  I argue
> that this hiding of the identity of the target resource in the SOAP
> message is a disadvantage of SOAP (one of the key disadvantages of
> SOAP).
>
> My colleague argues that this is not true.  He says that a client can
> provide the URI directly to the target Web service (resource), for
> example:
>
>    http://www.parts-depot.com/parts
>    http://www.parts-depot.com/parts/part/00345
>    http://www.parts-depot.com/parts/purchase-order
>
> He claims that he has done this using WebLogic. Here's a quote from him:
>
> "We were able to have 2 web services on the same machines with different
> URI, using WebLogic.
>
> I haven't used WebLogic, so I can't verify his statement.
>
> Can someone settle this debate please?  /Roger
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:1436
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-07 22:58:37
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

----- Original Message -----
From: "Roger L. Costello" <costello@...>

>
> My colleague argues that this is not true.  He says that a client can
> provide the URI directly to the target Web service (resource), for
> example:
>
>    http://www.parts-depot.com/parts
>    http://www.parts-depot.com/parts/part/00345
>    http://www.parts-depot.com/parts/purchase-order
>
> He claims that he has done this using WebLogic. Here's a quote from him:
>
> "We were able to have 2 web services on the same machines with different
> URI, using WebLogic.
>
> I haven't used WebLogic, so I can't verify his statement.
>

I haven't done this with WebLogic or any other toolkit, but my guess is that
it is pretty easy to route HTTP requests to HTTP handlers based on a URI
pattern. For example, in Java servlets, you can associate a single servlet
with the pattern "/parts/part" and a different one to
"/parts/purchase-order" - and the servlet you route to could be a SOAP aware
thing.
So, my guess is that it isn't that hard.

If you did route this way - via common HTTP URI based handling - then the
SOAP receiver probably won't be coded to know the HTTP URI - the info would
have to be replicated within the SOAP body.








-----------------------------------------------------------------------------------
Post ID:1437
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-07 23:02:40
Subject:RE: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

 

-----Original Message-----
From: Mark Nottingham [mailto:mnot@...]
Sent: Friday, June 07, 2002 3:38 PM
To: rest-discuss@yahoogroups.com; costello@...
Subject: Re: [rest-discuss] With SOAP the URI does not directly reference
the resource, right?


You're both right ;)

It's certainly possible to hide "applications" behind a single URI in
SOAP, just as it is in other uses of the HTTP (think PowerPoint, some uses
of cookies, query args, etc.)

The trick is how you define "application" (or, more in tune with this
list, "resource"); it's a design-time philosophical question of how much
you want to expose.
 

 
I think this points out subtle but important distinction.  There are certain
ramifications if we make what to expose and how to expose "applications",
"resources", or "objects" a design-time decision.
 
I think one of the fundamental advantages of RESTful thinking is that it
allows you make closer to a run-time decision.  In other words, you don't
need to rewrite an application, you can simply choose to expose something
later or hide something as your needs change or the needs of you partners
change.
 
You can only do this if the resource addressing mechanism is the same
regardless of whether you choose to expose it at design time or not.
Whereas SOAP forces you to choose your addressing scheme at design time
depending on if the resource is to be hidden or exposed.  There is certainly
no inherent limit from SOAP as to what you can choose to expose or not.
What is limiting is that once you decide what is to be accessed via URI and
what is to be accessed via a method call, you are locked in.
 
This gets back to what I was trying to say (maybe unsuccessfully), that the
universality of URI as a pass-by-reference addressing scheme allows us one
of the advantage of OOP programming where everything is an object and every
object is addressable.  Hiding and not hiding is simply a matter of whether
you want to give someone the reference to that object or not.  You don't
need to redesign the whole thing.
 
//Joe
 
 
 
 

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 





-----------------------------------------------------------------------------------
Post ID:1438
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-07 23:45:21
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

Mark Nottingham wrote:
> 
> You're both right ;)
> 
> It's certainly possible to hide "applications" behind a single URI in
> SOAP, just as it is in other uses of the HTTP (think PowerPoint, some uses
> of cookies, query args, etc.)

Actually, I don't think that PowerPoint hides anything at all. There is
a URI representing the PowerPoint document. That is the level at which
you can do network transactions. You can talk about individual slides
using pointers into the slideshow, but that isn't a protocol/networking
issue, because it has resolved completely on the "client side".

> ...
> Wait a minute, you say; if we reduce this argment to the absurd, every
> atom (and atomic particle) in the window is potentially a resource. 

No. At some point you are no longer interested in sending messages to
objects and I would say that that's the point you stop decomposing. It
isn't a judgement call. If you need to address something in a network
transaction then the thing needs a URI.

>...
> Back to SOAP (and hopefully a bit closer to reality), it's up to you as to
> what you expose in the URI interface. If you want it to be interoperable
> with applications that need to reference different subresources, that
> would indicate the use of separate URIs. You can do this in any Web
> Services environment; the only question is how much pain you have to put
> up with to give different services different URIs. 

Could you describe how to do this in any web service environments you
are familiar with? Remember that an important requirement is that new
resources will be created all of the time with no human interaction.

> ... If you're happy with
> the services that have to do with a car being available on the 'car' URI,
> so be it; that's your choice, and it's just as much on the Web as the
> other ones.

I think you've missed an important distinction. If the "car" has a
representation that exposes all of the state of the window then yes, the
window is "on the Web" despite the fact that it does not have its own
URI. It can be addressed through a URI reference (e.g. URI+XPointer) But
if you must POST a message to the car to ask *it* about the state of the
window, then the window has neither a URI nor a URI refrence and it is
not on the Web. If you cannot reference it with a Web address then I
don't think it is on the Web.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1439
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-06-08 05:11:18
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

> Actually, I don't think that PowerPoint hides anything at all. There is
> a URI representing the PowerPoint document. That is the level at which
> you can do network transactions. You can talk about individual slides
> using pointers into the slideshow, but that isn't a protocol/networking
> issue, because it has resolved completely on the "client side".
[...]
> I think you've missed an important distinction. If the "car" has a
> representation that exposes all of the state of the window then yes, the
> window is "on the Web" despite the fact that it does not have its own
> URI. It can be addressed through a URI reference (e.g. URI+XPointer) But
> if you must POST a message to the car to ask *it* about the state of the
> window, then the window has neither a URI nor a URI refrence and it is
> not on the Web. If you cannot reference it with a Web address then I
> don't think it is on the Web.

I'm no Microsoft guru (Actually, I've started using Windows as my primary
desktop for the first time, and I'm less than pleased), but from what I've
seen there isn't a fragment identifier that can be used to identify a
slide in a powerpoint show; the slides are not addressable.

If we assume that's the case (PDF is another format that can be
substituted for the purposes of this discussion if it's not), one can put
a slide on the Web by making its parent slideshow available at a URI. I'd
say that a reasonable interpretation of "on the Web" is "available on the
Web"; certainly more accurate than "addressable on the Web."

Addressability is a very important aspect of the Web, but let's not
confuse it with availability. Remember that resources are abstract, while
representations are concrete; when you use a URI reference, you're
identifying something concrete in the representation, not in the resource.


> No. At some point you are no longer interested in sending messages to
> objects and I would say that that's the point you stop decomposing. It
> isn't a judgement call. If you need to address something in a network
> transaction then the thing needs a URI.

Determining your level of interest in something isn't a judgement call?


> > Back to SOAP (and hopefully a bit closer to reality), it's up to you
as to
> > what you expose in the URI interface. If you want it to be
interoperable
> > with applications that need to reference different subresources, that
> > would indicate the use of separate URIs. You can do this in any Web
> > Services environment; the only question is how much pain you have to
put
> > up with to give different services different URIs.
>
> Could you describe how to do this in any web service environments you
> are familiar with? Remember that an important requirement is that new
> resources will be created all of the time with no human interaction.

I think it was noted before that this information is available in most
environments; it's more a question of whether people will use it, and
whether they'll be encouraged to use it. I'm somewhat hopeful that
progress can be made here.











-----------------------------------------------------------------------------------
Post ID:1440
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-08 12:16:31
Subject:Re: REST transaction idea
Message:

Paul, thanks for the well-reasoned reply.
My followup comments interspersed.

A little clarification on where I'm coming from first, though:
I'm not trying to sell the REST gang on ebXML.
Yes, I worked on ebXML, but I have been trying to solve the problem 
of freely-associating economic agents for years. Working with ebXML 
was just one learning experience.  Working with REST is another.

I do think the RosettaNet-ebXML transaction model is RESTifiable, 
though, which is why I suggest it.  Database transaction models are 
clearly not appropriate.

I also think the next direction that the UN/CEFACT business process 
gang went in is also RESTifiable.  It could resolve to using 
published resource state as an orchestration mechanism, which I think 
was the same direction as you have been going in casting state 
machines into hypertext form.

Paul Prescod wrote:
> Okay, let's first define transactions in the context of this 
discussion
> because people often mean different things. You do not mean 
transaction
> in the sense of requiring "a group of operations on (distributed)
> resources be treated as one unit of work. In a unit of work, all the
> participating operations should either succeed or fail and recover
> together." 

Oh, but I *do* mean a unit of work, in the sense of two trading 
partners coming to agreement on advancing a business deal to the next 
state.  Each business transaction succeeds or fails as a whole.

But they are only trying to agree on whether or not to advance to the 
next state.  Any database transactions are each partner's purely 
private matter.  I would not do my private database updates until the 
shared transaction completed, so no rollback or recovery would be 
necessary.

For an Order, the transaction is Offer-Acceptance.  At the end of the 
transaction, the order will be either accepted or not (it was either 
rejected or the transaction failed for technical reasons).  To be 
accepted, both trading partners must agree explicitly and auditably.

> Rather you mean transaction in the business sense, which is an 
agreement
> to exchange services, products or money.

In a typical order, there are at least three business stages:
*order
*delivery of goods or services
*payment (not necessarily in that order, cd be prepay).

If all three stages are performed electronically, there will be at 
least three business transactions:
*Order - Offer-Acceptance, which we've been discussing.
*Delivery and Payment - Notify-Confirm, where one partner notifies 
the other that the economic event happened, and the other partner 
confirms that yes it did happen as notified (or it doesn't agree, in 
which case they need to go into a problem resolution process, which 
could be another electronic transaction or a phone call or whatever).

> Now thinking about this from an XP perspective, I want to think 
about
> the simplest thing and see why it won't work. The simplest thing is 
for
> me to send you an "offer" message and you reply with "accept" or
> "decline". That's not good enough, however, because deciding 
whether to
> accept may take a long time. So it is necessary for the exchange to 
be
> broken into two parts: "request service" and then at some 
indeterminate
> time later, "provide response". In other words there are four 
messages: 

Exactly.  That's why I think this transaction model is about the 
simplest thing that will work in situations where there is a lag.

> bhaugen32 wrote:
> > It's a two-party request-response interaction, with receipt
> > acknowledgements for both request and response.
> 
> "Can we do business?"
> "I acknowledge that you want to do business. I will get back to 
you."
> "I agree/disagree we should do business."
> "I acknowledge your agreement/disagreement."


Beautiful recap, you nailed it!

> > There are time constraints on each step.  If any timeout occurs, 
the
> > transaction fails with a Control Failure.
> 
> Note that in the absence of reliable transport it is still possible 
for
> the businesses to end up misaligned. An HTTP-based solution needs 
to use
> HTTP in a manner that will ensure reliability.

Yes.

> > In cases where the Response document says "Accept" but has an 
error,
> > and the error message from the requesting business service cannot 
be
> > delivered, the transaction model specifies a separate 
Notification of
> > Failure to be sent from the requesting business service via 
another
> > channel.  Otherwise the responding activity may think incorrectly
> > that the transaction succeeded.
> 
> I see, so otherwise it is to assume the transaction succeeded if it
> returns an Accept, whether it gets a receipt or not?

Well, it would be a bad assumption, but the end state is ambiguous, 
and ambiguities are what sometimes end up in court.

> > RosettaNet and ebXML assume that a business service access point 
will
> > handle many transactions for many business activities, so each
> > message contains tags for dispatching to the business 
collaboration
> > (long conversation about the Order), business transaction, and
> > business activity.
> 
> You'll have to describe why all of these levels of statefulness are
> necessary. And if you want to represent them in REST then you should
> give them all URIs and point to them.

I'm describing the complex dispatching as a bad example, something I 
would prefer to avoid.  (I hope that was clear...)

> > If the resource is the Order, then only the business transaction 
and
> > business activity tags are required.
> > If the resource is the Transaction, then the business activity 
can be
> > assumed.
> 
> Sounds stateful. Better to use references.

I agree.

> > In either case, I think the REST style is functionally equivalent 
to
> > the EDI-mailbox style, but has at least two advantages:
> 
> Before I feel comfortable that this has been expressed in a REST 
style,
> I'd like to see some URIs, XML and HTTP methods. ;)
> 
> I propose that what you will need is at least two HTTP 
request/response
> pairs, one in each direction. To get reliability, though, you 
probably
> actually need four, as I discuss here:
> 
>  * http://www.prescod.net/reliable_http.html
> 
> So you would 
> 	-> POST: "I'd like to make an offer"
> 	<- OK, here's an offer-holder URI
> 	-> PUT the offer at offer-holder URI
> 	<- OK, I've received it and will get back to you

Ok, I read your Reliable HTTP article and think I agree.

> The offer should have a callback address, unless you are using 
something
> like HTTP events. Either way,
> 
> 	<- POST "I'd like to return a reliable offer-response"
> 	-> OK, here's an offer-response-holder URI
> 	<- PUT the offer-response at the holder-URI
> 	-> OK, I've got the offer-response

Couldn't you just send the offer-response-holder URI with the offer?

So do you think this has promise as a REST transaction protocol?
(Are you still having trouble thinking of it as a transaction?)

Thanks again,
Bob Haugen









-----------------------------------------------------------------------------------
Post ID:1441
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-08 14:38:23
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

Mark Nottingham wrote:
> 
>...
> 
> I'm no Microsoft guru (Actually, I've started using Windows as my primary
> desktop for the first time, and I'm less than pleased), but from what I've
> seen there isn't a fragment identifier that can be used to identify a
> slide in a powerpoint show; the slides are not addressable.

I believe that there is a fragment identifier syntax for both PowerPoint
and PDF but it is neither here nor there. As long as the bits you want
are sent across the network when you do an HTTP GET then the information
is "on the web" and an appropriate fragment identifier *could be worked
out* either globally or for a particular application. That means that it
is no longer a protocol issue, it is an application software issue. A
Web protocol has a responsibility to turn an address into bits and the
rest is up to the client.

> If we assume that's the case (PDF is another format that can be
> substituted for the purposes of this discussion if it's not), one can put
> a slide on the Web by making its parent slideshow available at a URI. I'd
> say that a reasonable interpretation of "on the Web" is "available on the
> Web"; certainly more accurate than "addressable on the Web."

Let's presume that's true. What if I give you a URI to Java applet that
implements the telnet or SSH protocols? Can I now declare that my
/etc/passwd is "on the web" because all you need to do is send the right
commands (machine name, username, password, cat /etc/passwd) to the Java
applet? In my opinion, that definition is too vague to be useful. Using
URI-addressability as the definition is crisp and helpful. If there
exists a URI that addresses a resource that returns a representation
that contains the bits then those bits are on the Web. Otherwise, not.

> Addressability is a very important aspect of the Web, but let's not
> confuse it with availability. Remember that resources are abstract, while
> representations are concrete; when you use a URI reference, you're
> identifying something concrete in the representation, not in the resource.

I agree but don't understand the relevance.

> > No. At some point you are no longer interested in sending messages to
> > objects and I would say that that's the point you stop decomposing. It
> > isn't a judgement call. If you need to address something in a network
> > transaction then the thing needs a URI.
> 
> Determining your level of interest in something isn't a judgement call?

My point is that there is a simple rule of thumb for determining whether
you've got the granularity right or not. If you need to send a message
to something then that thing should have an address. This issue is not
one that is particularly confusing in (e.g.) object oriented programming
and it shouldn't be in networking either.

>...
> > Could you describe how to do this in any web service environments you
> > are familiar with? Remember that an important requirement is that new
> > resources will be created all of the time with no human interaction.
> 
> I think it was noted before that this information is available in most
> environments; it's more a question of whether people will use it, and
> whether they'll be encouraged to use it. I'm somewhat hopeful that
> progress can be made here.

I may have missed this note. 

Here's what I remember: A few weeks ago Sam Ruby pointed me to a few
Axis documents that I couldn't interpret. 

Yesterday, Mike Dierken said: "my guess is that it is pretty easy to
route HTTP requests to HTTP handlers based on a URI pattern" and "If you
did route this way - via common HTTP URI based handling - then the SOAP
receiver probably won't be coded to know the HTTP URI - the info would
have to be replicated within the SOAP body."

Which in my mind defeats the whole purpose. The SOAP elements are still
the canonical address for the referenced object, not the URI. The URI is
more or less ignored.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1442
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-09 13:42:14
Subject:Dynamic exposing/hiding of Web resources! [was: With SOAP the URI does not directly reference the resource, right?]
Message:

Joe Hsy wrote:

> I think one of the fundamental advantages of RESTful thinking 
> is that it allows you make closer to a run-time decision.  In
> other words, you don't need to rewrite an application, you can 
> simply choose to expose something later or hide something
> as your needs change or the needs of you partners change.

Wow!  This is a really interesting idea.  Let me see if I understand
your idea.  I work best with a concrete example, so let's consider the
fictitious company, Parts Depot, Inc. One of the services it has
deployed is a service to enable clients to get detailed info about a
specific part.  For example, if the client is interested in part 00345
this is the URI that it would use:

     http://www.parts-depot.com/parts/00345

Here's a representation for that Part 00345 resource:

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"   
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>
         This part is used within the frap assembly
      </Description>
      <Specification
xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>0</Quantity>
</p:Part>

As you can see, at the moment Parts Depot is out of Part 00345 [Note
that <Quantity> is 0].

In those cases where a part is out of stock Parts Depot may wish to
additionally provide a URL to a shipping schedule of that part as a
courtesy to its clients.  For example, rather than sending the above
document, this one is sent:

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"   
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>
         This part is used within the frap assembly
      </Description>
      <Specification
xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>0</Quantity>
      <ShippingSchedule
href="http://www.parts-depot/parts/00345/shipping-schedule"/>
</p:Part>

Note the new element, <ShippingSchedule href="..."/>

Thus, the shipping-schedule resource is exposed when the <Quantity> is
0, and hidden otherwise.

Is this the kind of scenario that you are envisioning?  If so, I have
some questions:

1. In actuality, wouldn't Parts Depot need to deploy the
shipping-schedule resource at design time?  Isn't the only run-time
aspect of this scenario the decision of whether or not the URL to the
shipping-schedule resource is to be provided within the Part document?

2. If the answer to (1) is "yes", then couldn't this also be done using
SOAP?

Interesting idea!  I look forward to your thoughts (to everyone's
thoughts)!  /Roger







-----------------------------------------------------------------------------------
Post ID:1443
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-06-08 19:25:11
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

"Roger L. Costello" wrote:
>
> I am having a debate with a colleague.  I am arguing that when SOAP is
> used you POST to the SOAP server, and it then looks inside the SOAP
> message to determine which application to delegate to.

http://radio.weblogs.
com/0101679/stories/2002/01/25/whatObjectDoesSoapAccess.html

- Sam Ruby





-----------------------------------------------------------------------------------
Post ID:1444
Sender:Todd Boyle <tboyle@...>
Post Date/Time:2002-06-09 21:40:53
Subject:Re: [rest-discuss] Re: REST transaction idea
Message:

Here is some reasoning in favor of a "unilateral submit" idea,
and abandon the idea of scripting business processes.
http://www.gldialtone.com/UEEN.htm

That is, an assumption that the electronic environment is a completely
cynical, untrusted game environment, but knowing that there are good,
real businesses and people behind the crappy software, we try diligently
to execute sales and purchases.

Whatever Individuals and SMEs end up buying, will need to be *very*
simple to deal P2P with other I/SMEs.  Enterprises obviously are getting
better functionality than that with EDI already.  But E's will reap
economic benefits with each electronic exchange by individuals if it can
be understood.  I am advocating that E's deliberately downshift from
4th gear and try to speak in plain, simple, horizontal messages to SMEs.

There are at least 5 major problems with highly orderly Business
Process choreography, for SMEs.

1.  I/SMEs constantly change their behavior and kinds of terms more
dynamically and flexibly than Enterprise and their cost of maintaining
BP templates would be too high.  The economic payoff from BP
choreography (granular state alignment) is greatest when you have high
volume of similar transactions.  I/SMEs are often the opposite.

2.  Individuals and SMEs have so much role compression that the same
person often does most, or all, of customer service has no need for any
explicit, realtime computer record of the business state of the
collaboration or transaction.  So, they're simply not going to sit and
maintain granular diary of everything in a computer--Not now, not ever.

3.  most of the Simple Examples, POCs, and implementations for ebXML BP
are about supply chain for products or materials. The fraction of I/SMEs
in services is so high that *no* BP solution can reach critical mass
(viability) unless it wins adoption from services people.  In other
words, BP standards organizations should admit they have not much to
offer services collaborations, and, perhaps start with a core
functionality around simple communication, billing and reconciliation of
AR and AP that is needed both by services as well as product businesses.
(BP standards bodies are, instead, abandoning SMEs and sticking to their
Enterprise spaces, afaics, which dooms their standard to niche status.)

4.  Strategic.  By cooperating in supply chains dominated by trillion-dollar
corporations, the SME becomes truly a cog in a machine, bidding against
workers in Bangladesh. Knowing this, many businesses deliberately
misbehave and avoid adoption, especially since ebXML doesn't let
them buy/sell from their own neighbors or other SMEs, at first.

5.  The biggest problem with highly engineered, granular BP
specifications is that they cannot succeed without a compliant
application on each end.  Even if the other party tells you their app is
compliant it could be noncompliant or could fail.  Particularly during
the early adoption phase, the level of reliability will not be too
impressive.

So, the thinking behind my suggestion is forget about
changing others behavior and just send them carbon copies of
whatever recordkeeping we are actually posting in our own
computer, about them.   If they figure it out then fine.  If not,
then, fine.  http://www.gldialtone.com/UEEN.htm

I have deliberately written this in advocacy mode.  I realize there are
two sides to every story but feel these points are getting ignored by
all the Business Process standards bodies and I'm "mad as hell and won't
take it anymore"...   I want something simple enough to be understood by
6 billion people, to be adopted, making millions of full-time
bookkeeping positions as obsolete as telephone operators, and which
doesn't transfer economic or strategic advantage to Giant Enterprises.

Respectfully,

Todd

=====================Quote material follows
At 05:16 AM 6/8/02, bhaugen32 wrote:
....
 > So you would
 > 	-> POST: "I'd like to make an offer"
 > 	<- OK, here's an offer-holder URI
 > 	-> PUT the offer at offer-holder URI
 > 	<- OK, I've received it and will get back to you

Ok, I read your Reliable HTTP article and think I agree.

 > The offer should have a callback address, unless you are using
something
 > like HTTP events. Either way,
 >
 > 	<- POST "I'd like to return a reliable offer-response"
 > 	-> OK, here's an offer-response-holder URI
 > 	<- PUT the offer-response at the holder-URI
 > 	-> OK, I've got the offer-response

Couldn't you just send the offer-response-holder URI with the offer?







-----------------------------------------------------------------------------------
Post ID:1445
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-10 07:23:43
Subject:RE: [rest-discuss] Dynamic exposing/hiding of Web resources! [was : With SOAP the URI does not directly reference the resource, right?]
Message:

-----Original Message-----
From: Roger L. Costello [mailto:costello@...]



Wow!  This is a really interesting idea.  Let me see if I understand
your idea.  I work best with a concrete example, so let's consider the
fictitious company, Parts Depot, Inc. One of the services it has
deployed is a service to enable clients to get detailed info about a
specific part.  For example, if the client is interested in part 00345
this is the URI that it would use:

     http://www.parts-depot.com/parts/00345
<http://www.parts-depot.com/parts/00345> 

< ...> 

Is this the kind of scenario that you are envisioning?  If so, I have
some questions:

1. In actuality, wouldn't Parts Depot need to deploy the
shipping-schedule resource at design time?  Isn't the only run-time
aspect of this scenario the decision of whether or not the URL to the
shipping-schedule resource is to be provided within the Part document?
 

Yes, this is one example of what I was thinking.  My basic thought is that
if we can design applications where every resource/object is intrinsically
URL-addressable, it makes it much easier to make changes later which
involves deciding what to hide and what to expose.
 
In order to make this feasible, we need a development environment where
URL-addressability for any object or resource is a built-in feature of the
system and not something that needs to be consciously decided by the
programmer.  This is what I was thinking when I suggested that we create a
full-blown distributed OOP development environment that supports REST
intrinsically.
 
It also allows a business/operations to make decisions on what resources to
expose and what resources need additional security to be accessed without
needing to go back to the developer.


2. If the answer to (1) is "yes", then couldn't this also be done using
SOAP?
 

I actually think SOAP is in many ways tangential to this idea.  SOAP is
concerned with defining methods of objects/resources and does not deal with
the addressaebility of objects/resource.  In fact, URIs are what most
current SOAP implementations use for addressing.  The fact that people talk
about SOAP over SMTP and leveraging email addresses shows that SOAP is not
concerned with this issue at all.
 
Where SOAP falls down is that it encourages what I call "passing by value".
When SOAP returns something, it typically returns the actual values as
defined by the method description.  However, there is no reason that it
can't return the URIs of the desired resources (pass by reference) instead
of the value or in additional to the value.  It is simply not enforced nor
encouraged.
 
This is where REST-oriented thinking helps.  It encourages the developer to
think in terms of URIs and exposing them as the situation warrants.  It also
implements the universal addressability method calls (GET, PUT, POST,
DELETE) for these URI-addressable objects.
 
I think what would make REST really concrete to most people as a development
methodology is to have an environment and tool set that is extended from a
well-understood development environment.  I would like to suggest that java
and C++ can be extended to make URI-addressability an intrinsic part of
being an object and that this one simple capability would allow people to
program in a more RESTful way much more quickly.
 
On the other hand, I think SOAP is a more explicit way to define methods
calls of objects than the currently available set of REST tools.  And if we
add "passing by reference" as a first level concept into SOAP, I believe it
can still play a useful role in such a REST-OOP system.  What I mean by this
is that we can make it the default to return URIs for a method call unless
explicitly specified to be "pass by value".  We can then return the object
value when we explicitly perform the "GET" call.  By making URIs the core
result-passing (or when applicable, parameter passing) mechanism in the SOAP
protocol, I think it can become much more RESTful.
 
//Joe
 

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 





-----------------------------------------------------------------------------------
Post ID:1446
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-10 12:05:17
Subject:RE: Dynamic exposing/hiding of Web resources!
Message:

Joe Hsy wrote:

> In order to make this feasible, we need a development environment 
> where URL-addressability for any object or resource is a built-in > feature of the system and not something that needs to be consciously > decided by the programmer.  This is what I was thinking when I 
> suggested that we create a full-blown distributed OOP development > environment that supports REST intrinsically.

Isn't the idea of REST that URIs identify "resources", i.e., logical
entities?  Whether the resource is implemented as an object or some
other form is transparent.  Consequently, the implementation of the
resource can change without impacting clients.  

I don't really equate "objects" with "logical entities".  There are many
ways to implement a logical entity without the use of objects, e.g., a
logical entitiy could be implemented simply as an XML document, or as
the results of a database query.  

I see these two statements as being very different:

Object-based:

We need a development environment where URL-addressability for any
**object** is a built-in feature of the system. 

Resource-based:

We need a development environment where URL-addressability for any
**resource** is a built-in feature of the system.

I agree with the later, but not the former.  /Roger







-----------------------------------------------------------------------------------
Post ID:1447
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-10 14:21:34
Subject:RE: [rest-discuss] RE: Dynamic exposing/hiding of Web resources!
Message:

Joe, Roger,

The RESTful toolkit that I recently announced I'm developing is designed to do
the important parts of what both of you are saying.  Joe, I think it's wrong to
program every object in an application as URI-addressable.  Only the ones that
should be network-accessible.  And I think Roger's resource-based classification
is more suitable to REST than the object-based one, and it better represents
what I have designed into my toolkit.

For example, in addition to regular HTML content, core resources built into the
toolkit are nodes, containers, components, methods, topics, and queues.  I have
implemented them as objects, but in essence they are better represented as
resources.  Since the toolkit is developed in C++, every object has the abiliity
to subclass from a CObject class, which provides the built-in functionality you
refer to below.  It not only implements URI addressability, but also a facility
for serializing a snapshot of the state of any resource into an XML stream to be
transmitted in response to a GET request.  Combine these features with
environmental acquisition and you've got a great development environment to work
in.

This isn't a sales pitch....it will be free for developers, and I hope it helps
make REST a better philosophy for programming distributed apps than RPCs.

-Philip

-----Original Message-----
From: Roger L. Costello [mailto:costello@...]
Sent: Monday, June 10, 2002 8:05 AM
To: rest-discuss@yahoogroups.com; costello@...
Subject: [rest-discuss] RE: Dynamic exposing/hiding of Web resources!


Joe Hsy wrote:
> In order to make this feasible, we need a development environment
> where URL-addressability for any object or resource is a built-in
> feature of the system and not something that needs to be consciously
> decided by the programmer.  This is what I was thinking when I
> suggested that we create a full-blown distributed OOP development
> environment that supports REST intrinsically.

Isn't the idea of REST that URIs identify "resources", i.e., logical
entities?  Whether the resource is implemented as an object or some
other form is transparent.  Consequently, the implementation of the
resource can change without impacting clients.

I don't really equate "objects" with "logical entities".  There are many
ways to implement a logical entity without the use of objects, e.g., a
logical entitiy could be implemented simply as an XML document, or as
the results of a database query.

I see these two statements as being very different:

Object-based:

We need a development environment where URL-addressability for any
**object** is a built-in feature of the system.

Resource-based:

We need a development environment where URL-addressability for any
**resource** is a built-in feature of the system.

I agree with the later, but not the former.  /Roger







-----------------------------------------------------------------------------------
Post ID:1448
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-10 17:18:19
Subject:RE: [rest-discuss] RE: Dynamic exposing/hiding of Web resources!
Message:

 
Hi Roger, Philip,

I agree with both your messages.  I may have mistakenly given the impression
that I was advocating a specific way of extending OOP as *the* model of
implementing REST.  There are certainly other equally fine ways and it isn't
necessarily to treat resources as objects.

I was merely suggesting that if I want to program in a OOP environment,
having such extensions would make creating a RESTful application much
easier.  And I would have the benefit of pushing the hide/expose decisions
to much later in the development cycle.

From Philip's description of his toolkit, I think it is the very type of
extension that would be very useful.  I would love to see it!  It may never
be necessary to make all objects URI-addressible or to make URI-addressing a
"first-class" concept in a language, but I think if we take it to that
extreme, there may be some interesting ways to leverage this capability.

Some additional challenges for such a environment include the concept of the
life-span or pemanence of objects.  There may also be issues regarding
defining some standard form for URIs that are auto-generated in such a
system.  I've not fully thought this through but I think it could be an
interesting exercise. 8-)

//Joe

-----Original Message-----
From: Philip Eskelin
To: rest-discuss@yahoogroups.com
Cc: 'Roger L. Costello'; joe.hsy@...
Sent: 6/10/2002 7:21 AM
Subject: RE: [rest-discuss] RE: Dynamic exposing/hiding of Web resources!

Joe, Roger,

The RESTful toolkit that I recently announced I'm developing is designed
to do
the important parts of what both of you are saying.  Joe, I think it's
wrong to
program every object in an application as URI-addressable.  Only the
ones that
should be network-accessible.  And I think Roger's resource-based
classification
is more suitable to REST than the object-based one, and it better
represents
what I have designed into my toolkit.

For example, in addition to regular HTML content, core resources built
into the
toolkit are nodes, containers, components, methods, topics, and queues.
I have
implemented them as objects, but in essence they are better represented
as
resources.  Since the toolkit is developed in C++, every object has the
abiliity
to subclass from a CObject class, which provides the built-in
functionality you
refer to below.  It not only implements URI addressability, but also a
facility
for serializing a snapshot of the state of any resource into an XML
stream to be
transmitted in response to a GET request.  Combine these features with
environmental acquisition and you've got a great development environment
to work
in.

This isn't a sales pitch....it will be free for developers, and I hope
it helps
make REST a better philosophy for programming distributed apps than
RPCs.

-Philip

-----Original Message-----
From: Roger L. Costello [mailto:costello@...]
Sent: Monday, June 10, 2002 8:05 AM
To: rest-discuss@yahoogroups.com; costello@...
Subject: [rest-discuss] RE: Dynamic exposing/hiding of Web resources!


Joe Hsy wrote:
> In order to make this feasible, we need a development environment
> where URL-addressability for any object or resource is a built-in
> feature of the system and not something that needs to be consciously
> decided by the programmer.  This is what I was thinking when I
> suggested that we create a full-blown distributed OOP development
> environment that supports REST intrinsically.

Isn't the idea of REST that URIs identify "resources", i.e., logical
entities?  Whether the resource is implemented as an object or some
other form is transparent.  Consequently, the implementation of the
resource can change without impacting clients.

I don't really equate "objects" with "logical entities".  There are many
ways to implement a logical entity without the use of objects, e.g., a
logical entitiy could be implemented simply as an XML document, or as
the results of a database query.

I see these two statements as being very different:

Object-based:

We need a development environment where URL-addressability for any
**object** is a built-in feature of the system.

Resource-based:

We need a development environment where URL-addressability for any
**resource** is a built-in feature of the system.

I agree with the later, but not the former.  /Roger


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1449
Sender:"Sam Ruby" <rubys@...>
Post Date/Time:2002-06-10 19:18:30
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

Paul Prescod wrote:
>
>>> Could you describe how to do this in any web service environments you
>>> are familiar with? Remember that an important requirement is that new
>>> resources will be created all of the time with no human interaction.
>>
>> I think it was noted before that this information is available in most
>> environments; it's more a question of whether people will use it, and
>> whether they'll be encouraged to use it. I'm somewhat hopeful that
>> progress can be made here.
>
> I may have missed this note.
>
> Here's what I remember: A few weeks ago Sam Ruby pointed me to a few
> Axis documents that I couldn't interpret.

http://groups.yahoo.com/group/rest-discuss/message/1291

> Yesterday, Mike Dierken said: "my guess is that it is pretty easy to
> route HTTP requests to HTTP handlers based on a URI pattern" and "If you
> did route this way - via common HTTP URI based handling - then the SOAP
> receiver probably won't be coded to know the HTTP URI - the info would
> have to be replicated within the SOAP body."
>
> Which in my mind defeats the whole purpose. The SOAP elements are still
> the canonical address for the referenced object, not the URI. The URI is
> more or less ignored.

I disagree.

http://radio.weblogs.com/0101679/stories/2002/01/25/whatObjectDoesSoapAccess.html

- Sam Ruby





-----------------------------------------------------------------------------------
Post ID:1450
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-10 20:11:48
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference theresource, right?
Message:

Sam Ruby wrote:
> 
>...
> > Here's what I remember: A few weeks ago Sam Ruby pointed me to a few
> > Axis documents that I couldn't interpret.
> 
> http://groups.yahoo.com/group/rest-discuss/message/1291

If I have to read the source code to figure out how to do it then I'd
have to say it is "not really supported."

>...
> 
> I disagree.
> 
> http://radio.weblogs.com/0101679/stories/2002/01/25/whatObjectDoesSoapAccess.html

You haven't addressed the real-world, concrete problem of building a web
service where every purchase order has its own URI. What does that look
like with an Axis client. What does it look like with an Axis server.
What does the WSDL look like? Everybody is pointing out that this is
possible in theory but nobody has sat down to document how to do this in
practice. It isn't a matter of convincing REST advocates that SOAP is
RESTful. It's more a matter of bolstering the claim of SOAP advocates
that SOAP can use the Web as more than a transport pipe *in practice*.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1451
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-10 20:20:48
Subject:Re: [rest-discuss] Re: REST transaction idea
Message:

bhaugen32 wrote:
> 
> Paul, thanks for the well-reasoned reply.
> My followup comments interspersed.
> 
> A little clarification on where I'm coming from first, though:
> I'm not trying to sell the REST gang on ebXML.
> Yes, I worked on ebXML, but I have been trying to solve the problem
> of freely-associating economic agents for years. Working with ebXML
> was just one learning experience.  Working with REST is another.

I think that it is very important to have people working from the top
down, starting with business requirements. Really there should be more
people working on that end rather than on the plumbing but it is easier
to get your head around plumbing.

>...
> Oh, but I *do* mean a unit of work, in the sense of two trading
> partners coming to agreement on advancing a business deal to the next
> state.  Each business transaction succeeds or fails as a whole.

Okay, but people often mean transactions in this sense: "I want to be
able to take an arbitrary number of state-changing operations and ensure
that the succeed or fail as a single operation." 

For example:

PUT X
PUT Y
POST Z
PUT A
POST B

"But only do ANY of these things if you can guarantee ALL will succeed."

This is tricky in distributed systems because it requires that the
server trust that the client will not lock up too many resources and
then disappear.

>...
> For an Order, the transaction is Offer-Acceptance.  At the end of the
> transaction, the order will be either accepted or not (it was either
> rejected or the transaction failed for technical reasons).  To be
> accepted, both trading partners must agree explicitly and auditably.

Agree.

>...
> 
> Couldn't you just send the offer-response-holder URI with the offer?

Good idea!

> So do you think this has promise as a REST transaction protocol?

I see it as a REST offer-acceptance protocol. But in what sense is it
"transactions in general" and what exact definition of "transactions"
are you using? Is there a way we could avoid that word so as not to
confuse people?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1452
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-10 22:00:58
Subject:Re: REST transaction idea
Message:

Paul,

I'm gonna switch the sequence of your comments around a little.

Paul Prescod <paul@p...> wrote:
> I see it as a REST offer-acceptance protocol. But in what sense is 
it
> "transactions in general" and what exact definition 
of "transactions"
> are you using? Is there a way we could avoid that word so as not to
> confuse people?

Actually, I like using the word "transaction" in this case. 
Database people took the word from business in the first place.
And then narrowed the definition something awful.  
I think it's acceptable to consider other protocols besides 2-phase 
commit to be transactions.

Even in business, the word has several meanings.

The phrase I used is "state-alignment transaction".
Which means that at the end of the transaction, both parties must 
agree on whether the transaction succeeded or not.
I think that's all you can do with a simple Internet interaction, 
although I'm always ready to be proved wrong.

The sense in which it is a transaction-in-general is that it is an 
atomic unit of work.  

The relationship between state-alignment transactions and database 
transactions is that the state-alignment transaction operates in the 
shared space of the Internet, but any database transactions are the 
private and protected business of each of the trading partners.

More on database updates below.  

> > Oh, but I *do* mean a unit of work, in the sense of two trading
> > partners coming to agreement on advancing a business deal to the 
next
> > state.  Each business transaction succeeds or fails as a whole.

> Okay, but people often mean transactions in this sense: "I want to 
be
> able to take an arbitrary number of state-changing operations and 
ensure
> that the succeed or fail as a single operation." 
> 
> For example:
> 
> PUT X
> PUT Y
> POST Z
> PUT A
> POST B
> 
> "But only do ANY of these things if you can guarantee ALL will 
succeed."

> This is tricky in distributed systems because it requires that the
> server trust that the client will not lock up too many resources and
> then disappear.

Exactly.  RosettaNet went through this same conversation we (and W3C) 
are having now in early 1999.  They started out trying to do 2-phase 
commit over the Internet and found it was a very bad idea.  

Then they came up with the state-alignment transaction protocol by 
studying the UNECE and ABA requirements again.  

The idea is that all the tricky database updates listed above should 
be done in somebody's private and protected space.  For example, in 
the offer-acceptance transaction, the responding party may need to do 
a lot operations before coming back with an acceptance.  If any of 
those operations fail, the responding party must reject the offer.

In other words, all you can do (and all you usually need to do) in 
the shared space is synchronize two parties at a time.  If you have a 
situation like the travel agent, where many legs of a trip must be 
booked, you need something like a temporary hold.  In fact, the 
travel industry provides such a feature.  You can put reservations on 
hold for e.g. 24 hours and assemble the legs of the trip and ask the 
traveler to approve it, and then go back and book everything.  They 
provided the feature for the same kinds of reasons it is useful in an 
Internet business conversation:  you're crossing administrative 
boundaries.

I mean, that is one of the limitations of this kind of transaction 
protocol.  I think if you really need to synchronize more than two 
activities at the same time, you need something more complex.  But 
you will pay for it.

On the other hand, I have had conversations with accountants and 
lawyers who say that well-formed business contracts have the same 
characteristic:  however many parties may be involved, all 
commitments can and should be broken down into two-parties.  

Thanks again for the dialog,
Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1453
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-10 23:00:00
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

> ----- Original Message -----
> From: Sam Ruby

> >
> > Which in my mind defeats the whole purpose. The SOAP elements are still
> > the canonical address for the referenced object, not the URI. The URI is
> > more or less ignored.

> I disagree.

>
http://radio.weblogs.com/0101679/stories/2002/01/25/whatObjectDoesSoapAccess
.html

The summary for those who like reliability through replication:
--
Conclusion

In order to correctly and interoperably access a SOAP service, a client must
specify three pieces of information in order to identify the object to be
accessed.  Correspondingly, in order for a web service to be published, all
three pieces should be specified.  A given service implementation may chose
to ignore or validate any of these data.







-----------------------------------------------------------------------------------
Post ID:1454
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-11 15:31:51
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

"S. Mike Dierken" wrote:
> 
> > ----- Original Message -----
> > From: Sam Ruby
> 
> > >
> > > Which in my mind defeats the whole purpose. The SOAP elements are still
> > > the canonical address for the referenced object, not the URI. The URI is
> > > more or less ignored.
> 
> > I disagree.

Mike, I know you didn't write any of this but you did write the
statement that started the whole debate was that you could use HTTP
dispatching to dispatch based on URI and then have the addressing
information redundantly stored in the SOAP message for a SOAP processor.
I couldn't state clearly why I thought this was not helpful but now I
can.

Let's say you are trying to write "update bank account" and it takes a
bank account number and an amount of money. The REST argument is that
you should use standards as much as possible. So you want to use a
standard addressing mechanism, standardized method names/semantics and,
if possible, a standardized information representation. The reason we
use standards is to minimize the amount of a priori knowledge necessary
to invoke a service.

Moving addressing information like "which account number" from the SOAP
body to the URI reduces the amount you have to know to work with a bank
account. Someone can just hand you a URI and you don't even need to know
that bank accounts or numbered, or that savings accounts and chequing
accounts form different namespaces or that the bank has two subsidiaries
with their own numbering system or ... It's all one namespace.

If you must put the information both in the SOAP body and the URI then
we've *increased* the amount of a priori knowledge required. Now you
have to know to do X *and* Y. Sam's URI demonstrates that even without
this extra burden, SOAP already requires you to jump through many "a
priori knowledge" hoops. To invoke the right operation you must know:

 * whether or not there is a SOAPAction. 
 * if there is, what it's value is (there are a variety of conventions)
 * what namespace to use for the operation element
 * what element type to use for the operation
 * what endpoint URI to use

And some of these are only applicable to the HTTP transport so if you
are using another transport then you have other magic cookies to
provide. I've never heard why SOAP needs so many magic incantations when
XML-RPC gets away with URI and method name and you could move even the
method name into the URI (whether or not you believe in REST). But if
you moved the method name into the URI then SOAP would be a web-centric
protocol instead of a protocol that uses the Web as a transport.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1455
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-11 16:56:03
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

>
> Mike, I know you didn't write any of this but you did write the
> statement that started the whole debate was that you could use HTTP
> dispatching to dispatch based on URI and then have the addressing
> information redundantly stored in the SOAP message for a SOAP processor.

Actually it was RogerC that started the discussion.
> For example, if a company has deployed three Web services then despite
which Web service
> a client wishes to invoke, the URI will always be the same, for example:
[...]
> My colleague argues that this is not true.  He says that a client can
> provide the URI directly to the target Web service (resource),
[...]
> "We were able to have 2 web services on the same machines with different
> URI, using WebLogic."
> I haven't used WebLogic, so I can't verify his statement.
> Can someone settle this debate please?

I was pointing out that most HTTP servers have configuration capabilities
that make it easy to target the same internal HTTP handler for many
different URI - which was the question of the original message. The question
looked to me like "Can I have two SOAP listeners on the same web server at
two different URI?"

I also pointed out that replicating the URI to within the SOAP message
(either header or body) would be necessary. I didn't say it was a good idea
or that it should be done this way, but rather that it would be required to
work at all.
But what I should have said was that it would only be necessary if the URI
were fine-grained and pointed to a resource to operate on rather than a
service. If the URI referenced the soap service itself, then that particular
URI wouldn't need to be part of the soap message. Any data needed for the
operation would already be bundled in the message, but then we get into the
whole non-addressable data issue.








-----------------------------------------------------------------------------------
Post ID:1456
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-11 16:58:46
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> But if
> you moved the method name into the URI then SOAP would be a web-centric
> protocol instead of a protocol that uses the Web as a transport.
I wouldn't go so far as to call it 'web-centric' - perhaps web-friendly
because the URI is important, but it still doesn't use standardized/minimal
methods.

>
> ------------------------ Yahoo! Groups Sponsor ---------------------~-->
> Will You Find True Love?
> Will You Meet the One?
> Free Love Reading by phone!

And what's with all this Free Love stuff you keep sending me?






-----------------------------------------------------------------------------------
Post ID:1457
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-06-12 02:10:49
Subject:a RESTful architecture?
Message:

My boss just gave me the go-ahead to investigate REST as the architectural
framework for our middle-tier. I was wondering if it would be OK to post
some of my thoughts for how REST might be utilized in our domain (a hospital
information system). After mostly lurking on the list for a few months, I
think I have a good grasp of what makes an archiectecture RESTful or not but
would love to get some input from those wiser than I.

Thanks,
Jason








-----------------------------------------------------------------------------------
Post ID:1458
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-12 04:03:19
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

"S. Mike Dierken" wrote:
> 
>...
> But what I should have said was that it would only be necessary if the URI
> were fine-grained and pointed to a resource to operate on rather than a
> service. If the URI referenced the soap service itself, then that particular
> URI wouldn't need to be part of the soap message. Any data needed for the
> operation would already be bundled in the message, but then we get into the
> whole non-addressable data issue.

Right. I think that we're in violent agreement. You can use any URI to
talk to a SOAP service but unless your SOAP toolkit can extract
information from the URI the way an HTTP toolkit can, then you haven't
solved the addressability problem. You still need to encode the
addressing data in the SOAP message in some service-specific fashion.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1459
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-06-12 05:55:09
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

Hmm. Would actually including the link to my notes help?

http://www.injektilo.org/REST.html

----- Original Message -----
From: "Jason Diamond" <jason@...>
To: <rest-discuss@yahoogroups.com>
Sent: Tuesday, June 11, 2002 7:10 PM
Subject: [rest-discuss] a RESTful architecture?


> My boss just gave me the go-ahead to investigate REST as the architectural
> framework for our middle-tier. I was wondering if it would be OK to post
> some of my thoughts for how REST might be utilized in our domain (a
hospital
> information system). After mostly lurking on the list for a few months, I
> think I have a good grasp of what makes an archiectecture RESTful or not
but
> would love to get some input from those wiser than I.
>
> Thanks,
> Jason









-----------------------------------------------------------------------------------
Post ID:1460
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-12 06:23:16
Subject:Re: [rest-discuss] With SOAP the URI does not directly reference the resource, right?
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

>
> Right. I think that we're in violent agreement.
Hey - you may be violent, I'm only looking to Find True Love or get a Free
Love Reading by phone!

I suppose that would be reachable via:

GET phone:FreeLoveReading HTTP/1.1
Host: sponsor.yahoo.com

You know... putting non-http protocols in the Request-URI really has some
amazing potentials...

> ------------------------ Yahoo! Groups Sponsor ---------------------~-->
> Will You Find True Love?
> Will You Meet the One?
> Free Love Reading by phone!








-----------------------------------------------------------------------------------
Post ID:1461
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-12 06:24:55
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

----- Original Message ----- 
From: "Jason Diamond" <jason@...>


> Hmm. Would actually including the link to my notes help?
> 
> http://www.injektilo.org/REST.html
> 
Only if you think hypertext is the engine of application state.








-----------------------------------------------------------------------------------
Post ID:1462
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-12 06:37:19
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

----- Original Message -----
From: "Jason Diamond" <jason@...>
>
> http://www.injektilo.org/REST.html
>

> Each patient in these representations will link to an actual patient
resource that might look like this:
>
http://server/CliniVision/MPC.aspx/patients/01234567-89AB-CDEF-0123-456789AB
CDEF
> (Yes, we use UUIDs to identify all of our objects.)
If each object has a long-lived, persistent reference, then the URI doesn't
have to be 'patients/UUID' it can just be 'UUID'. The trick with that is
that you have to retrieve the object before knowing what type it is if you
want to provide a representation. Another issue is what happens if a user
replaces 'patients/UUID' with 'doctors/UUID' but uses the UUID of a patient.
(you are going to make doctors into numbers too, not just patients, right?)


> The reason that the orders for each patient aren't located "beneath" each
patient is for the reason that
> patients can be merged. That would "move" each order from one patient to
the other.
> I didn't want the URIs to change.
Good thinking.


> What I really love about the idea is that each representation could
contain an xml-stylesheet PI so that
> we could easily traverse the model using IE6
Yeah - cool stuff. I haven't played with this much in the past few years, so
I'm not sure what the best way to get 'device independence' - essentially
user-agent detection. Should the URI of the XSL return different XSL for
different devices? Should there be multiple PIs in the XML? Should the PI in
the XML be different for different user-agents? etc...









-----------------------------------------------------------------------------------
Post ID:1463
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-06-12 07:21:19
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

S. Mike Dierken <mdierken@...> wrote:

> If each object has a long-lived, persistent reference, then the URI
doesn't
> have to be 'patients/UUID' it can just be 'UUID'. The trick with that is
> that you have to retrieve the object before knowing what type it is if you
> want to provide a representation.

You're right. The UUIDs are unique even across "types" of resources. So the
patients/ or orders/ "prefixes" aren't really necessary. Since we have to
have some URI to list all resources of a given type to start with, I guess I
thought that it would make sense to use those URIs as "containers". Of
course, since all of these URIs are retrieved via links in representations,
it doesn't really matter what they look like as long as they're unique.

With regards to your "trick" are you talking about the implementation of the
service? I wasn't trying to think that far ahead yet but I think I see what
you mean now. If all that's specified is the UUID in the URI, the code
implementing the service would need to figure out what table to query into
in the database before it can get the information to return a
representation. That could be costly. So having the type in the URI makes it
easier for the implementation to dispatch to different code for different
types of resources (while still being opaque to the client).

> Another issue is what happens if a user
> replaces 'patients/UUID' with 'doctors/UUID' but uses the UUID of a
patient.
> (you are going to make doctors into numbers too, not just patients,
right?)

Shouldn't you get a 404?

> > What I really love about the idea is that each representation could
> contain an xml-stylesheet PI so that
> > we could easily traverse the model using IE6
> Yeah - cool stuff. I haven't played with this much in the past few years,
so
> I'm not sure what the best way to get 'device independence' - essentially
> user-agent detection. Should the URI of the XSL return different XSL for
> different devices? Should there be multiple PIs in the XML? Should the PI
in
> the XML be different for different user-agents? etc...

That's a good idea. Of course, working in a Microsoft-only shop makes this
really easy. (But living in a fully standards-compliant world would make it
even easier.)

Jason









-----------------------------------------------------------------------------------
Post ID:1464
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-06-12 11:29:46
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

At 03:55 PM 12/06/2002, Jason Diamond wrote:
>http://server/CliniVision/MPC.aspx/patients/new
>When you POST to that URI, it returns the URI of the new patient in the Location header. It will probably look like the patient URI we've already seen

I'm not sure about the /new as it looks suspiciously like a verb and REST resources should be nouns. I'd be tempted to use /patients/schema or /patients/structure on which a GET will return the required fields list (alternatively the list returned from a GET to /patients could include a link to the patients required field structure, see also my ps below). You would then do a POST containing the appropriate data to /patients to create a new patient. 
Similarly for /patients/uuid/orders/new and /orders/uuid/activities/new. 

I'm a bit confused on the relationship between orders/activities and procedures, as you say :

>Each patient has a list of orders....Each order has a list of activities...
>There can be many different types of orders. Each different type requires different bits of information. We call an order type a procedure. 

and later you say:

>This list of orders will contain a link to the page that lists all of the procedures that can be used to create a new order for this type of patient.

I don't understand this sentence at all. 


I was thinking you might have the following resource structure:

/orders

on which a GET returns a list of all the available procedures( aka order types)

/orders/procedure1
/orders/procedure2
/orders/procedure3
...

A GET on /orders/procedureN would return the structure of that particular order type, including the activities, i.e.

<order type='procedureN'>
    <activities>
        <activity type='activity1' mandatory=true>
             ...add required activity info specification
        </activity>
        ....
    </activities>
</order>

Note that you could allow a POST to /orders/procedureN as long as the posted info contained a valid UUID of the patient to add the order to. This would allow you a bit of symmetry in the /orders and /patients URI's. 

If activities are always subordinate to orders do you need the separate /activities URI's? Could you use /patients/uuid/orders/uuid or alternatively /patients/uuid/orders/procedureN/activityN to POST the data containing the required activity information?

Robert

PS One thing that has been bothering me in the REST examples I have seen - how are the required formats/structures discovered by the user? For example, in the case of REST-ifying the UserLand XML storage api (http://internet.conveyor.com/RESTwiki/moin.cgi/RestifyingUserlandsXmlStorageSystem) it says:
"xmlStorageSystem.registerUser() 
This method creates a new user account, or updates an existing one on the server. This could quite easily have been done with either an XML document containing this information..." 

How do I as a user or a system find out what structure the XML document should be?







-----------------------------------------------------------------------------------
Post ID:1465
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-06-12 14:59:23
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

Robert Leftwich <robert@...> wrote:

> I'm not sure about the /new as it looks suspiciously like a verb and
> REST resources should be nouns. I'd be tempted to use /patients/schema
> or /patients/structure on which a GET will return the required fields
> list (alternatively the list returned from a GET to /patients could
> include a link to the patients required field structure, see also my ps
> below). You would then do a POST containing the appropriate data to
> /patients to create a new patient.

Ah. Thanks for pointing that out! I like your approach much better.

> I'm a bit confused on the relationship between orders/activities and
procedures, as you say :
>
> >Each patient has a list of orders....Each order has a list of
activities...
> >There can be many different types of orders. Each different type requires
different bits of information. We call an order type a procedure.
>
> and later you say:
>
> >This list of orders will contain a link to the page that lists all of the
procedures that can be used to create a new order for this type of patient.
>
> I don't understand this sentence at all.

Yeah, it's a little awkward. I probably shouldn't have mentioned the
different types of patients since I left out the details about those
earlier. A procedure (in our vocabulary) can just be thought of as the
schema for an order. In our application, when you create a new order for a
patient, you're presented with a list of procedures. The fields that you get
to fill in for your new order differ depending on which procedure you chose.

> I was thinking you might have the following resource structure:
>
> /orders
>
> on which a GET returns a list of all the available procedures( aka order
types)
>
> /orders/procedure1
> /orders/procedure2
> /orders/procedure3
> ...
>
> A GET on /orders/procedureN would return the structure of that particular
order type, including the activities, i.e.
>
> <order type='procedureN'>
>     <activities>
>         <activity type='activity1' mandatory=true>
>              ...add required activity info specification
>         </activity>
>         ....
>     </activities>
> </order>
>
> Note that you could allow a POST to /orders/procedureN as long as the
> posted info contained a valid UUID of the patient to add the order to.
> This would allow you a bit of symmetry in the /orders and /patients URI's.

Since I wasn't focusing on the vocabulary yet, it hadn't occurred to me that
the patient UUID could be in the submitted XML to the generic procedure
resources. The type of order (procedure) could also be indicated in the
markup like you showed. That avoids the awkward URIs where every procedure
has a path under every patient.

> If activities are always subordinate to orders do you need the
> separate /activities URI's? Could you use /patients/uuid/orders/uuid
> or alternatively /patients/uuid/orders/procedureN/activityN to POST
> the data containing the required activity information?

It's possible that an activity can change it's parent order. This could
happen during the merge patient process. If it's determined that two orders
for the two patients are the same, the activities from one get moved to the
other and the now empty order would get deleted. I know that it sounds a
little odd but it occasionally happens that the same patient and/or order
gets entered on different disconnected clients and this has to be resolved
when the clients reconnect and upload their work back to the server.

> PS One thing that has been bothering me in the REST examples I have
> seen - how are the required formats/structures discovered by the user?
> For example, in the case of REST-ifying the UserLand XML storage api
>
(http://internet.conveyor.com/RESTwiki/moin.cgi/RestifyingUserlandsXmlStorag
eSystem)
> it says:
> "xmlStorageSystem.registerUser()
> This method creates a new user account, or updates an existing one on
> the server. This could quite easily have been done with either an XML
> document containing this information..."
>
> How do I as a user or a system find out what structure the XML document
> should be?

Even if there was some standard way of obtaining the schema for a service,
applications can never really "know" what those elements and attributes
"mean". Some understanding between the two parties has to be achieved before
you can start making use of it. RDF might change things but until then, I'm
resigned to the fact that it's impossible to expect to use a web service
(SOAP or REST) without some development effort.

Thank you very much for your comments!

Jason









-----------------------------------------------------------------------------------
Post ID:1466
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-12 15:14:13
Subject:CGI = Cold Fusion = SOAP? Is the Web today mostly non-RESTful?
Message:

I was talking with a colleague this morning and evangelizing REST to
him.  I was telling him that one of the disavantages of SOAP is that the
identity of a target resource is hidden within the SOAP body, as opposed
to being clearly shown in the URL [although this is not a requirement of
SOAP it is common practice of vendors].  

My colleague responded saying that many (if not most) Web applications
today use this paradigm of funneling all requests though a single URL. 
For example, with CGI applications there is only one URL.  The CGI code
delegates the request to the appropriate application.  Likewise, Cold
Fusion applications all funnel to the same URL.  He said, "go to amazon,
you will see that all URLs funnel through obidos" (I checked, he's
correct).  

He stipulated that the majority of the Web is non-RESTful.  He also
argued that if the REST model does not support this single-URL paradigm
then it is not in tune with the "real Web" and therefore REST is merely
a figment of Roy Fielding's imagination.

Three (very naive) questions:

1. Are his statements about CGI and Cold Fusion correct?

2. Is it true that the majority of the Web is non-RESTful?

3. Should we (the REST evangelists) be arguing against CGI, Cold Fusion,
as well as SOAP?

/Roger







-----------------------------------------------------------------------------------
Post ID:1467
Sender:Chris Croome <chris@...>
Post Date/Time:2002-06-12 15:30:23
Subject:Re: [rest-discuss] CGI = Cold Fusion = SOAP? Is the Web today mostly non-RESTful?
Message:

Hi

On Wed 12-Jun-2002 at 11:14:13AM -0400, Roger L. Costello wrote:
> 
> My colleague responded saying that many (if not most) Web applications
> today use this paradigm of funneling all requests though a single URL.
> For example, with CGI applications there is only one URL.

The way the we [1] have got around this is by aliasing / to the CGI, for
example in a Apache httpd.conf file:

  Alias /     /usr/local/mkdoc/cgi/mkdoc.cgi/
  <Directory /usr/local/mkdoc/cgi>
     Options ExecCGI
     AddHandler cgi-script .cgi
  </Directory>

And then we use the PATH_INFO env var to get the /foo/bar/ bit of the URI and
then we can create web sites that appear to be based on a file system but in
reality its all served up from a database.

I don't see why Amazon couldn't alias obidos to / for nicer URIs, but I guess
they are stuck with it now.

Chris


[1] http://mkdoc.com/ 

-- 
Chris Croome                               <chris@...>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   
everything else                               http://chris.croome.net/  






-----------------------------------------------------------------------------------
Post ID:1468
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-06-12 15:47:57
Subject:RE: [rest-discuss] CGI = Cold Fusion = SOAP? Is the Web today mostly non-RESTful?
Message:

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> -----Original Message-----
> From: Roger L. Costello [mailto:costello@...] 
> Sent: 12 June 2002 16:14
> To: rest-discuss@yahoogroups.com; Costello,Roger L.
> Subject: [rest-discuss] CGI = Cold Fusion = SOAP? Is the Web 
> today mostly non-RESTful?
> 
> 
> I was talking with a colleague this morning and evangelizing 
> REST to him.  I was telling him that one of the disavantages 
> of SOAP is that the identity of a target resource is hidden 
> within the SOAP body, as opposed to being clearly shown in 
> the URL [although this is not a requirement of SOAP it is 
> common practice of vendors].  
> 
> My colleague responded saying that many (if not most) Web 
> applications today use this paradigm of funneling all 
> requests though a single URL. 

No, funnelling through a single process maybe. 

> For example, with CGI applications there is only one URL.  
> The CGI code delegates the request to the appropriate 
> application.  

That's not strictly true.


> Likewise, Cold Fusion applications all funnel 
> to the same URL.  He said, "go to amazon, you will see that 
> all URLs funnel through obidos" (I checked, he's correct). 

But that's different from using 1 URL to display many resources.
Some sites do that, it's a pain (they're often the ones you can't
bookmark). Your colleague forget to mention all the stuff appended
after obidos.

 
> He stipulated that the majority of the Web is non-RESTful.  
> He also argued that if the REST model does not support this 
> single-URL paradigm then it is not in tune with the "real 
> Web" and therefore REST is merely a figment of Roy Fielding's 
> imagination.
> 
> Three (very naive) questions:
> 
> 1. Are his statements about CGI and Cold Fusion correct?

Partially. You can do CGI that way, but:

 http: //example.org/cgi-bin/cgi.cgi?resource1
 http: //example.org/cgi-bin/cgi.cgi?resource2

go through the same CGI but use 2 URLs. As I understand it, there's
nothing wrong with doing this, so long as each resources is
addressable. What your colleague describes is sometimes called a
front controller in J2EE land. The ultimate front controller is the
web server dispatching on http: //example.org. By that line of
argument, web servers are not restful. So it's not the funnelling
but the addressing thast counts. 

But if I can get back representations for resources 1 and 2 via a
single URL:

 http: //example.org/cgi-bin/cgi.cgi

my understanding is that's not restful.

 
> 2. Is it true that the majority of the Web is non-RESTful?

Couldn't say and it depends on whether you're counting URLs or
known resources. I doubt if there are more URLs that can return >1
resource representations that there those that return 1. Though
it's quite possible that most resources are sharing URLs.

 
> 3. Should we (the REST evangelists) be arguing against CGI, 
> Cold Fusion, as well as SOAP?

I think only if they are used to hide >1 resources behind a single
URL.

Bill de hra

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPQdtH+aWiFwg2CH4EQJIugCg0aLlQJIzHHH9w3d70z4dKdX+dSkAn1JA
MjAu1WM0K/PxxDK6YcY2JK72
=+i+l
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:1469
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-06-12 15:47:57
Subject:RE: [rest-discuss] CGI = Cold Fusion = SOAP? Is the Web today mostly non-RESTful?
Message:

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> -----Original Message-----
> From: Chris Croome [mailto:chris@...] 
>
> I don't see why Amazon couldn't alias obidos to / for nicer 
> URIs, but I guess they are stuck with it now.

Perhaps it is because Amazon /is/ restful. They're stuck with the
problem of throwing away all those resource names. 

Bill de hra


-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPQdtLOaWiFwg2CH4EQLEHQCffprJg2OHV2lkClp+dlqeOI1ciLYAoIWJ
US+Q2SQNhof/4pEHLyCUdj4k
=SiVQ
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:1470
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-12 16:50:02
Subject:Re: [rest-discuss] CGI = Cold Fusion = SOAP? Is the Web today mostly non-RESTful?
Message:

"Roger L. Costello" wrote:
> 
>...
> 
> My colleague responded saying that many (if not most) Web applications
> today use this paradigm of funneling all requests though a single URL.
> For example, with CGI applications there is only one URL.  The CGI code
> delegates the request to the appropriate application.  Likewise, Cold
> Fusion applications all funnel to the same URL.  He said, "go to amazon,
> you will see that all URLs funnel through obidos" (I checked, he's
> correct).

http://www.amazon.com/exec/obidos/ISBN%3D0136168221/104-7936033-9823945

"obidos" is an implementation detail. What does it matter to a client
application that maybe somewhere in the URI is a trigger that launches a
CGI or J2EE servlet or whatever?

The difference with SOAP is that a typical SOAP service would *stop* at
obdios:

http://www.amazon.com/exec/obidos/

And then you would specify the rest of the information in SOAP elements
like <ISBN>.

This means that "obdios" goes from being a trick the server uses to keep
track of how to dispatch URIs to something the *client* of the service
needs to care about. Now the *client* needs to know to send the ISBN as
an element. This means that there is no compact syntax (like a URI) for
the resource identified. You have to say something like:

"Go to http://www.amazon.com/exec/obidos/and send a message that looks
like this:

<ISBN>0136168221/104-7936033-9823945</ISBN>"

You see the difference? With REST I can send someone to the particular
book with a single declarative, globally understood statement. With SOAP
I can only *describe* how to *configure* a SOAP client to send the right
message to get at the information. One is an address. The other is a
list of instructions of how to get to a place.

> Three (very naive) questions:
> 
> 1. Are his statements about CGI and Cold Fusion correct?

No, Amazon is a wonderful example of CGI used right.

> 2. Is it true that the majority of the Web is non-RESTful?

There is a lot of the Web that violates REST design criteria in one way
or another. Amazon's book URIs are not a good example but it would not
take long to find some. That is only an indictment of REST if there is a
good reason those people did things in a non-RESTful way. i.e. if REST
didn't solve their problems. If it is just the case that they didn't
*know* how to use REST right then REST is in the same position as OO
programming when C++ was just beginning to become popular. People used
OO constructs as structs with methods for years before the paradigm
started to seep in. With no REST books, it is actually amazing how
RESTful average Web sites are! People rediscovered and reinvented REST
before it was named or documented!

There is also a lot of the Web that uses REST beautifully.

> 3. Should we (the REST evangelists) be arguing against CGI, Cold Fusion,
> as well as SOAP?

CGI and cold fusion are implementation techniques. SOAP is a protocol.
CGI and Cold Fusion can be used to present *any* interface to the client
you want. SOAP *defines* the syntax of the messages that the client and
server must send. In other words, CGI and Cold Fusion are the languages
you speak at home with your kids -- none of my business. SOAP is the
language you demand I speak in order to communicate with you. That makes
it my business.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1471
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-12 17:02:37
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

----- Original Message -----
From: "Jason Diamond" <jason@...>

> > Another issue is what happens if a user
> > replaces 'patients/UUID' with 'doctors/UUID' but uses the UUID of a
> patient.
> > (you are going to make doctors into numbers too, not just patients,
> right?)
>
> Shouldn't you get a 404?
Yes - but I can envision some implementations that do weird things. Your app
may not be subject to this though.


> > I'm not sure what the best way to get 'device independence' -
essentially
> > user-agent detection. Should the URI of the XSL return different XSL for
> > different devices? Should there be multiple PIs in the XML? Should the
PI
> in
> > the XML be different for different user-agents? etc...
>
> That's a good idea. Of course, working in a Microsoft-only shop makes this
> really easy. (But living in a fully standards-compliant world would make
it
> even easier.)
Even MS-land has different devices - PocketPC, small-screen PCs, the
often-promised-never-shipped tablets, etc.
Differences between IE4/5/6, etc...









-----------------------------------------------------------------------------------
Post ID:1472
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-06-12 17:06:19
Subject:RE: [rest-discuss] CGI = Cold Fusion = SOAP? Is the Web today mostly non-RESTful?
Message:

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> -----Original Message-----
> From: Roger L. Costello [mailto:costello@...] 
>
> I was talking with a colleague this morning and evangelizing 
> REST to him.  I was telling him that one of the disavantages 
> of SOAP is that the identity of a target resource is hidden 
> within the SOAP body, as opposed to being clearly shown in 
> the URL [although this is not a requirement of SOAP it is 
> common practice of vendors].  

Roger,

Not unrelated: a doc on URIs and addressing [1] was announced by
the tag today. The key bit is:

[[[
1. Relevant Principles of Web Architecture

 1. All important resources SHOULD be identifiable by URI. 
]]]

Bill de hra

[1] http://www.w3.org/2001/tag/doc/get7



-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPQd/iOaWiFwg2CH4EQJuwQCg2SYqg4CusP3/Ipxofnogv92bXtgAn2+p
hxk5q25b9+aAA5ArbbS7PCaL
=ZJrq
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:1473
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-12 17:14:42
Subject:Re: [rest-discuss] CGI = Cold Fusion = SOAP? Is the Web today mostly non-RESTful?
Message:

----- Original Message -----
From: "Roger L. Costello" <costello@...>

>
> My colleague responded saying that many (if not most) Web applications
> today use this paradigm of funneling all requests though a single URL.
As others have pointed out, the single URL isn't that common, but a single
request handler is.
The query terms are part of the resource identifer. They are not 'parameters
to the method' - even though that is a handy mental bridge between the
procedural programming world and resource modelling.

There might be many sites that DO use a single URL - if you see everything
done with POST and other data in form fields - like the identifier in a form
field - then that would be an example (and exactly analagous to many SOAP
approaches). You wouldn't be able to hit 'refresh' on these pages or
bookmark them, which is a pain for end-users, so site designers naturally
avoid the 'one URL to rule them all' approach.

mike






-----------------------------------------------------------------------------------
Post ID:1474
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-12 17:40:20
Subject:Re: [rest-discuss] CGI = Cold Fusion = SOAP? Is the Web today mostly non-RESTful?
Message:

 > Roger,
> 
> Not unrelated: a doc on URIs and addressing [1] was announced by
> the tag today. The key bit is:
> 
> [[[
> 1. Relevant Principles of Web Architecture
> 
>  1. All important resources SHOULD be identifiable by URI.
> ]]]
> 
> Bill de hra
> 
> [1] http://www.w3.org/2001/tag/doc/get7

Excellent!  Related, I just looked at Tim Berners-Lee Web Axioms [2] and
it has as its first axioms:

Axiom 0: Universality 1
Any resource anywhere can be given a URI

Axiom 0a: Universality 2
Any resource of significance should be given a URI.

/Roger

[2] http://www.w3.org/DesignIssues/Axioms.html







-----------------------------------------------------------------------------------
Post ID:1475
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-12 19:06:08
Subject:REST Best Practices
Message:

Has anyone put together a set of Best Practices for creating REST
services?  If not, how about getting started on one?  Here's some that
come to mind:

1. Provide a URI for each resource that you want (or will want)
exposed.  This is consistent with Tim Berners-Lee's axioms for the Web,
as well as the W3 TAG recomendations.

2. Prefer URIs that are logical over URIs that are physical.  For
example:

   Prefer:
     http://www.boeing.com/airplanes/747
   Over:
     http://www.boeing.com/airplanes/747.html

Logical URIs allow the resource implementation to change without
impacting client applications.

3. As a corollary to (2) use nouns in the logical URI, not verbs. 
Resources are "things" not "actions".

4. Make all HTTP GETs side-effect free.  Doing so makes the request
"safe".

5. Use links in your responses to requests!  Doing so connects your
response with other data.  It enables client applications to be
"self-propelled".  That is, the response itself contains info about
"what's the next step to take".  Contrast this to responses that do not
contain links.  Thus, the decision of "what's the next step to take"
must be made out-of-band.

6. Minimize the use of query strings.  For example:

    Prefer:
         http://www.parts-depot.com/parts/00345
    Over: 
         http://www.parts-depot.com/parts?part-id=00345

Rationale: it's easier for Web intermedaries such as proxy servers to
evaluate a request when it doesn't need to parse a query string.

What else?  Do you agree with this list?  /Roger







-----------------------------------------------------------------------------------
Post ID:1476
Sender:rubys@...
Post Date/Time:2002-06-12 19:04:05
Subject:Re: [rest-discuss] CGI = Cold Fusion = SOAP? Is the Web today mostly non-RESTful?
Message:

Dr. Fielding's take on the subject can be found at http://lists.w3.
org/Archives/Public/www-tag/2002Apr/0181.html

- Sam Ruby





-----------------------------------------------------------------------------------
Post ID:1477
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-06-12 19:54:42
Subject:Re: [rest-discuss] REST Best Practices
Message:

> 6. Minimize the use of query strings.  For example:
>
>     Prefer:
>          http://www.parts-depot.com/parts/00345
>     Over:
>          http://www.parts-depot.com/parts?part-id=00345
>
> Rationale: it's easier for Web intermedaries such as proxy servers to
> evaluate a request when it doesn't need to parse a query string.

I think the rationale for this is more along the lines that it allows
relative URIs to work; the relationship between 'parts' and '00345' is
clear, and you can instantiate subresources of '00345' easily; this is not
possibly if that information is tucked away in a query string.

I was working on a 'n ways to abuse a URI' document somewhat on these
lines, with real-life examples; I've been sidetracked, but would be happy
to put it up for others to work with (once I clean it up a bit).

Cheers,







-----------------------------------------------------------------------------------
Post ID:1478
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-12 20:00:50
Subject:RE: [rest-discuss] a RESTful architecture?
Message:

Jason wrote:
> You're right. The UUIDs are unique even across "types" of resources. So the
> patients/ or orders/ "prefixes" aren't really necessary. Since we have to
> have some URI to list all resources of a given type to start with, I guess I
> thought that it would make sense to use those URIs as "containers". Of
> course, since all of these URIs are retrieved via links in representations,
> it doesn't really matter what they look like as long as they're unique.

With environmental acquisition as a feature in your RESTful server, all your
UUIDs could physically exist in the container http://server/CliniVision but be
requested as existing in 'patients' or 'doctors' sub-containers.  Therefore, the
server receiving the HTTP request (e.g., let's say it's a POST) would know that
UUIDs exist in the CliniVision container, but see that the client wishes to
locate information in the context of specifically CliniVision patients or
doctors.

-Philip







-----------------------------------------------------------------------------------
Post ID:1479
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-12 20:31:29
Subject:Re: [rest-discuss] REST Best Practices
Message:

Mark Nottingham wrote:
> 
> I was working on a 'n ways to abuse a URI' document somewhat on these
> lines, with real-life examples; I've been sidetracked, but would be 
> happy to put it up for others to work with (once I clean it up a bit).

Yes!  I'd like to see it.  /Roger







-----------------------------------------------------------------------------------
Post ID:1480
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-12 22:37:34
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

"S. Mike Dierken" wrote:
> 
>...
> If each object has a long-lived, persistent reference, then the URI doesn't
> have to be 'patients/UUID' it can just be 'UUID'. 

It seems to me that it is merely preference one way or the other.

> ... The trick with that is
> that you have to retrieve the object before knowing what type it is if you
> want to provide a representation.

In either case you retrieve the object using a URI someone gave you. The
internal syntax of the URI is not important!

> ... Another issue is what happens if a user
> replaces 'patients/UUID' with 'doctors/UUID' but uses the UUID of a patient.
> (you are going to make doctors into numbers too, not just patients, right?)

404.

>...
> Yeah - cool stuff. I haven't played with this much in the past few years, so
> I'm not sure what the best way to get 'device independence' - essentially
> user-agent detection. Should the URI of the XSL return different XSL for
> different devices? Should there be multiple PIs in the XML? Should the PI in
> the XML be different for different user-agents? etc...

Good question. If he's just using it for debugging it doesn't matter
much. The stylesheet PI is a little bit simplistic...

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1481
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-12 22:53:15
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

Robert Leftwich wrote:
> 
>...
> 
> I'm not sure about the /new as it looks suspiciously like a verb 
> and REST resources should be nouns. I'd be tempted to 
> use /patients/schema or /patients/structure on which a GET will 
> return the required fields list (alternatively the list returned from 
> a GET to /patients could include a link to the patients 
> required field structure, see also my ps below). 

I'm not sure why both of your designs includes a link instead of just
inlining the "schema" or "form". Think of it like an HTML page with a
form at the bottom that says: "add a patient by clicking here."

But the analogy breaks down because if there is no human being on the
other end then who interprets the schema and figures out where to get
the information to shove into each field? At best I can see the schema
being useful as a filter over named fields that are known at design
time. "I don't need that field right now so don't bother sending it."
But then that's just a performance optimization to avoid sending extra
information.

>...
> PS One thing that has been bothering me in the REST examples I 
> have seen - how are the required formats/structures discovered 
> by the user? For example, in the case of REST-ifying the 
> UserLand XML storage api (http://internet.conveyor.com/RESTwiki/moin.cgi/RestifyingUserlandsXmlStorageSystem) it says:
> "xmlStorageSystem.registerUser()
> This method creates a new user account, or updates an existing 
> one on the server. This could quite easily have been done with either 
> an XML document containing this information..."
> 
> How do I as a user or a system find out what structure the XML document should be?

How did you figure out the existing Userland API? Either through a prose
document or perhaps through a design-time specification like WSDL. The
same holds for REST. What REST changes is that it separates the globally
standardized stuff (methods, URIs) from the must-be-negotiated stuff
(representations) which simplifies the negotiations and improves partial
understanding. For instance if you define a "UserLandUserML" you'll find
you can much more easily reuse that across different content management
systems and parts of the UserLand API than the "RegisterUserLandUser"
operation.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1482
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-06-12 22:56:59
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

> > ... The trick with that is
> > that you have to retrieve the object before knowing what type it is if
you
> > want to provide a representation.
>
> In either case you retrieve the object using a URI someone gave you. The
> internal syntax of the URI is not important!

It's not important to the client but it can make implementing the server a
heck of a lot easier. Does
http://server/01234567-89AB-CDEF-0123-456789ABCDEF identify a patient or an
order or something else? The client knows what context they received that
link in so most likely knows what it refers to but the server has lost that
context (being stateless and all). Path information can really help the
server out here while still not breaking the REST guidelines (I hope).

Jason








-----------------------------------------------------------------------------------
Post ID:1483
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-12 22:58:23
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

Jason Diamond wrote:
> 
>...
> 
> It's not important to the client but it can make implementing the server a
> heck of a lot easier. Does
> http://server/01234567-89AB-CDEF-0123-456789ABCDEF identify a patient or an
> order or something else? The client knows what context they received that
> link in so most likely knows what it refers to but the server has lost that
> context (being stateless and all). Path information can really help the
> server out here while still not breaking the REST guidelines (I hope).

I agree. I was defending your design. The server can and should stash
whatever it wants in the URI to help it figure out how to find the state
that goes with the referenced resource.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1484
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-06-12 23:06:12
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

Paul Prescod <paul@...> wrote:
>
> Robert Leftwich wrote:
> >
> > I'm not sure about the /new as it looks suspiciously like a verb
> > and REST resources should be nouns. I'd be tempted to
> > use /patients/schema or /patients/structure on which a GET will
> > return the required fields list (alternatively the list returned from
> > a GET to /patients could include a link to the patients
> > required field structure, see also my ps below).
>
> I'm not sure why both of your designs includes a link instead of just
> inlining the "schema" or "form". Think of it like an HTML page with a
> form at the bottom that says: "add a patient by clicking here."

That's a definite true but that means you'd have to fetch the list of
patients just to get the information to create a new one. By extracting that
information out into a separate resource you can fetch the required fields
without listing any patients. If we're transforming the output for display
in a browser, we can always use the document() function to fetch the
required fields to display at the bottom of the patient list.

> But the analogy breaks down because if there is no human being on the
> other end then who interprets the schema and figures out where to get
> the information to shove into each field? At best I can see the schema
> being useful as a filter over named fields that are known at design
> time. "I don't need that field right now so don't bother sending it."
> But then that's just a performance optimization to avoid sending extra
> information.

I'm not sure I understand. In our system there is either a human entering
the data into the fields for each resource or there is another automated
interface that knows how to map fields from systems in other parts of the
hospital into our fields. Either way, they need to know the basic structure
of the objects including the field names, types, constraints, etc.

I admit that having configurable resources makes my example a little more
complex than others would be. But I really appreciate the comments you guys
are giving me. I think I'm finally starting to understand the concept of
resource modelling and hope to get to update my design soon.

Thanks,
Jason








-----------------------------------------------------------------------------------
Post ID:1485
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-12 23:24:33
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

Jason Diamond wrote:
> 
>...
> 
> That's a definite true but that means you'd have to fetch the list of
> patients just to get the information to create a new one.

Okay, fair enough. That's a performance concern.

But I'm getting a little lost in the discussion. Don't you need to fetch
the list of patients to get the link to the "runtime schema"? So you
still have a performance issue. If you're thinking about performance
then maybe the schema should be the parent object and the list should be
the child. Or they could have a common parent (perhaps it summarizes
information from the patient list).

>...
> I'm not sure I understand. In our system there is either a human entering
> the data into the fields for each resource or there is another automated
> interface that knows how to map fields from systems in other parts of the
> hospital into our fields. Either way, they need to know the basic structure
> of the objects including the field names, types, constraints, etc.

Okay, but in the case where it is a machine doing the filling in, that
information needs to be available at *design time* so making it also
available at runtime is redundant extra work for the service designer
(you). Nevertheless, if human beings will be filling it in then of
course it IS useful because there may not be a "design time". You could
use something like HTML forms or XForms.

And come to think of it, if the same schema is used at runtime and
design time then there is no extra effort providing a link to it at
runtime. Maybe that's what you were thinking about.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1486
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-12 23:29:45
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

Jason Diamond wrote:
> 
>...
> 
> Even if there was some standard way of obtaining the schema for a service,
> applications can never really "know" what those elements and attributes
> "mean". 

You're right in general but don't forget that there *are* standardized
vocabularies out there that are appropriate for some projects. That's
why there is a benefit in separating the always-standadized bits
(methods) from the sometimes standardized bits (representations). It
will be much easier to convince the world to standardize on your patient
record vocabulary than on an "API" with more operational (workflow,
business model, ...) semantics.

> ... Some understanding between the two parties has to be achieved before
> you can start making use of it. RDF might change things but until then, I'm
> resigned to the fact that it's impossible to expect to use a web service
> (SOAP or REST) without some development effort.

I agree. I'll be even more pessimistic and say that semantic web
technologies will not change this basic situation. When I walk into a
bank wanting some foreign money, I need to know what an "exchange rate"
is. If I write a currency trading client application it will need to
know that same thing. I.e. it needs to know the concept and it needs to
know either what term you will use for the concept or be able to map
your term into its concept.

Here's what I hope the semantic web technologies will do:

 a) improve the extensibility of representations to allow protocol
evolution

 b) raise the level of abstraction so that rather than working with
"elements and attributes" we can more easily work with objects that
reflect higher level concerns.

 c) allow declarative (rather than programmatic) ways of configuring
clients and servers to talk to each other. "When the server says
patient_height, it means what the client calls the person's height
property" "if the server says the order is shipped that implies that the
client cannot cancel any more."

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1487
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-06-12 23:29:04
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

At 08:53 AM 13/06/2002, Paul Prescod wrote:
>Robert Leftwich wrote:
>> How do I as a user or a system find out what structure the XML document should be?
>
>How did you figure out the existing Userland API? Either through a prose
>document or perhaps through a design-time specification like WSDL. The
>same holds for REST. What REST changes is that it separates the globally
>standardized stuff (methods, URIs) from the must-be-negotiated stuff
>(representations) which simplifies the negotiations and improves partial
>understanding. For instance if you define a "UserLandUserML" you'll find
>you can much more easily reuse that across different content management
>systems and parts of the UserLand API than the "RegisterUserLandUser"
>operation.

This is one area where I see SOAP as having an advantage - you don't need to invent a ???ML (where ??? is your representation/resource space) with the associated problems of deciding how and when do I use XSD, RELAX-NG, DTD's, RDF, DAML, Schematron, ... or do I wait for a standard from the relevant standards body in my domain and if so what do I do in the interim. There is a lot of appeal to the hard-pressed people in the trenches to running a few wizards and presto a nice standards compliant Web interface springs into existence.

Robert







-----------------------------------------------------------------------------------
Post ID:1488
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-12 23:39:56
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

Robert Leftwich wrote:
> 
>...
> 
> This is one area where I see SOAP as having an advantage - you don't need to invent a 
???ML (where ??? is your representation/resource space) with the
associated problems 

WSDL depends on XML Schema for defining ???ML.

> ... of deciding how and when do I use XSD, RELAX-NG, DTD's, RDF, DAML, 
> ... Schematron, ... 

WSDL hard-codes the choice of XSD. If you want a hard-coded choice you
can pay my consulting fee and I'll write you a report telling you which
one to choose. ;)

> ... or do I wait for a standard from the relevant standards 
> body in my domain and if so what do I do in the interim. There 
> is a lot of appeal to the hard-pressed people in the trenches to 
> running a few wizards and presto a nice standards compliant Web 
> interface springs into existence.

REST doesn't require de jure standardization, it just allows it. If you
wanted to convert the Userland API with the least possible work, you can
have representations like:

<xmlrpcresponse>
   <struct>
      <string>...</string>
      <int>...</int>
   </struct>
</xmlrpcresponse>

This could be used across all web services in the world with no more de
jure standardization ever. And It doesn't violate any principles of REST
(as long as you manipulate these using GET, PUT, POST, DELETE). 

I just think it is kind of ugly and verbose compared to:

<person>
  <name>...</name>
  <height>...</height>
</person>

And it is also harder to validate and describe.

But REST doesn't care much.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1489
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-06-13 00:03:03
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

Paul Prescod <paul@...> wrote:
>
> > ... Some understanding between the two parties has to be achieved before
> > you can start making use of it. RDF might change things but until then,
I'm
> > resigned to the fact that it's impossible to expect to use a web service
> > (SOAP or REST) without some development effort.
>
> I agree. I'll be even more pessimistic and say that semantic web
> technologies will not change this basic situation. When I walk into a
> bank wanting some foreign money, I need to know what an "exchange rate"
> is. If I write a currency trading client application it will need to
> know that same thing. I.e. it needs to know the concept and it needs to
> know either what term you will use for the concept or be able to map
> your term into its concept.

You're absolutely right. Since everything in RDF is identified using URIs,
however, all you really need to know is the URIs for the classes and
properties that you're interested in. The format (whether it be RDF in XML,
N3, or arbitrary XML vocabularies augmented with RDF-aware attributes--a pet
project of mine) isn't as important--you can just extract the assertions out
of whatever representation you've requested and then process them
accordingly. I'm probably simplifying thinks too much to be practical but it
sure sounds nice, doesn't it?

Jason








-----------------------------------------------------------------------------------
Post ID:1490
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-06-13 00:04:36
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

On Thu, Jun 13, 2002 at 09:29:04AM +1000, Robert Leftwich wrote:

> >> How do I as a user or a system find out what structure the XML document should be?
> >
> >How did you figure out the existing Userland API? Either through a prose
> >document or perhaps through a design-time specification like WSDL. The
> >same holds for REST. What REST changes is that it separates the globally

[snip]
> This is one area where I see SOAP as having an advantage - you don't
> need to invent a ???ML (where ??? is your representation/resource
> space) with the associated problems of deciding how and when do I use
> XSD, RELAX-NG, DTD's, RDF, DAML, Schematron, ... or do I wait for a
> standard from the relevant standards body in my domain and if so what
> do I do in the interim. There is a lot of appeal to the hard-pressed
> people in the trenches to running a few wizards and presto a nice
> standards compliant Web interface springs into existence.

Do you necessarily need to invent a ???ML for a REST application? You
might very well be able to use one of the ebXML specs for purchase
orders, HIPAA-XML (or whatever the %#@&*$) for a health insurance
application, DocBook &/or RDF for a knowledge base ...

And if you do need to invent your language? I would argue that
(depending on your background) it's no harder to invent an ad-hoc XML
dialect than to write an ad-hoc Java program. And not necessarily
harder to create a well-designed XML spec than a well-designed Java
library ... though, since the XML community is more anal-retentive about
standards, conventions and design principles than most programmer
communities, it might seem that way.

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:1491
Sender:Chuck Hinson <Chuck.Hinson@...>
Post Date/Time:2002-06-13 00:54:52
Subject:[rest-discuss] Path info v query string
Message:

I've seen a number of discussions here that have touched on the 
'structure' of URLs - especially the construction of a hierarchical 
namespace to represent relationships between various resources.

I've noticed that some people prefer to use the query string to convey 
information while others prefer to use the hierarchical structure of 
the namespace.

While I realize that the choice of one over the other is probably a 
matter of preference (or at least dependent on the circumstances), I 
was wondering if anyone had thoughts on general rules-of-thumb for 
deciding whether to embed information in a query string vs in the path 
info; i.e.:

http://server.com/something?item=itemname

vs

http://server.com/something/itemname


Might one form have different semantics than the other?



--Chuck







-----------------------------------------------------------------------------------
Post ID:1492
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-13 01:05:04
Subject:Re: [rest-discuss] Path info v query string
Message:

Chuck Hinson wrote:
> 
>...
> While I realize that the choice of one over the other is probably a
> matter of preference (or at least dependent on the circumstances), I
> was wondering if anyone had thoughts on general rules-of-thumb for
> deciding whether to embed information in a query string vs in the path
> info; i.e.:
> 
> http://server.com/something?item=itemname
> 
> vs
> 
> http://server.com/something/itemname
> 
> Might one form have different semantics than the other?

If the client is expected to fill in values, use a query. By default,
use a hierarchy.

So for instance:

findstocks?minimum_price=10  // client fills in minimum price

customers/UUID019880934802348032 // they'll just follow a link to this,
so use hierarchy

Debatable:

stocks?name=msft

stocks/msft

If you use the latter but you DO expect the client to know stock names
then you should define a mapping somewhere like:

<stock name="MSFT" uri="stocks/msft"/>

You might choose to have this extra level of indirection to allow for
the circumstance where the MSFT stock is served elsewhere:

<stock name="MSFT" uri="http://someothermachine/msft"/>

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1493
Sender:Chuck Hinson <Chuck.Hinson@...>
Post Date/Time:2002-06-13 01:23:31
Subject:Re: [rest-discuss] CGI = Cold Fusion = SOAP? Is the Web today mostly non-RESTful?
Message:


Bill de h�ra wrote:
>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
>>-----Original Message-----
>>From: Chris Croome [mailto:chris@...] 
>>
>>I don't see why Amazon couldn't alias obidos to / for nicer 
>>URIs, but I guess they are stuck with it now.
> 
> 
> Perhaps it is because Amazon /is/ restful. They're stuck with the
> problem of throwing away all those resource names. 
> 

Not that it's completely relevant to the discussion at hand, but I 
don't think amazon is completely RESTful.

Try this:

Go to the front page and do a search for REST (under All Products).

You'll get a results page with a URL that is something like this:

http://www.amazon.com/exec/obidos/search-handle-form/104-2883896-9858338

If Amazon were completely RESTful, I should be able to link to that 
page or bookmark it so that I can revisit my results.

Interestingly, if I try to do this in a new/different browser session, 
Amazon tells me there must be a bug in my browser.

--Chuck








-----------------------------------------------------------------------------------
Post ID:1494
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-13 02:13:52
Subject:Re: [rest-discuss] a RESTful architecture?
Message:


> > ... The trick with that is
> > that you have to retrieve the object before knowing what type it is if
you
> > want to provide a representation.
>
> In either case you retrieve the object using a URI someone gave you. The
> internal syntax of the URI is not important!
I was speaking about the internal implementation of the server interpreting
that URI syntax.
Bugs can happen here if too much dependence is on the URI being 'right'.
Implementation detail, but without paying attention to detail, you don't get
implementation.

>
> > ... Another issue is what happens if a user
> > replaces 'patients/UUID' with 'doctors/UUID' but uses the UUID of a
patient.
> > (you are going to make doctors into numbers too, not just patients,
right?)
>
> 404.
Again, I was considering internal implementation - the correct visible
result should be a "404 Not Found" response status.







-----------------------------------------------------------------------------------
Post ID:1495
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-13 02:26:24
Subject:Amazon home page search - get vs post
Message:

I think that is because they used POST rather then GET from the home page. I
put the query terms on the URI and that didn't work either.
Whatever.

<form method="post"
action="/exec/obidos/search-handle-form/103-9378802-1912632"
name="searchform">

My guess is the 'magic number' in the URI is some user tracking 'invasion of
privacy' thingee.

----- Original Message -----
From: "Chuck Hinson" <Chuck.Hinson@...>

>
> Go to the front page and do a search for REST (under All Products).
>
> You'll get a results page with a URL that is something like this:
>
> http://www.amazon.com/exec/obidos/search-handle-form/104-2883896-9858338







-----------------------------------------------------------------------------------
Post ID:1496
Sender:Chuck Hinson <Chuck.Hinson@...>
Post Date/Time:2002-06-13 02:47:13
Subject:multiple representations of a single resource
Message:

I'm building a web-based admin GUI for an application we have and I'm 
having a difficult time applying REST principles to the design (or 
maybe I'm just making things harder than they need to be).

My current dilemma revolves around different representations of the 
same resource.  In other threads, I've seen reference to the idea of 
resources having multiple representations, but the examples always 
seem to assume that the choice of representation to serve is based on 
the type of user agent or some other kind of http header information.
While this makes sense to me when I'm able to write my own user agent 
and set whatever headers I want, it doesnt help much when I have to 
use a browser as my UA.

So my question is, is it reasonable to encode information in the URL 
that indicates the desired representation?

For example, a GET of http://server.com/users/userid would return
a page listing the attributes of the user identified by userid.  I 
call this the 'default' view for this resource.  I also have the need
for an 'edit' view.  The edit view is similar to the default view 
except that it is presented as a form so as to allow the values of the 
attributes to be edited (and then submitted for update).

That I want to submit the update as a POST to 
http://server.com/users/userid seems obvious.  However its not so 
obvious to me that a GET of http://server.com/users/userid?mode=edit 
is the way to implement my edit view.

I'm not sure why I have a problem with this.  A colleague suggested I 
might feel better about it if I was more consistent:

For the default view:
http://server.com/users/userid?mode=view

For the edit view:
http://server.com/users/userid?mode=edit

This doesnt seem much better.  I can't really say why - except to say 
that it feels wrong to be embedding that kind of information in the 
URL.  Then again, maybe I'm making a mountain out of a mole-hill.

--Chuck








-----------------------------------------------------------------------------------
Post ID:1497
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-13 03:08:29
Subject:Re: [rest-discuss] multiple representations of a single resource
Message:

This is the area where I have the most problem with REST and HTTP.
It's not hard to take back-end information and expose it as a 'resource
model'.
It is hard to put a usable user interface on top of that model - usability
is just a different domain than information structuring.
<flames-go-here href='void' />

The general view I take is that the UI itself is composed of resources with
their own URI. With full hyperlinking, it isn't necessary to make the UI be
a query string off of the 'data' resource - possibly handy, but not
required.

This suggests that rather than thinking about the 'edit vs view' HTML as
being different representations of the same 'data resource', that they are
in fact two different 'user interface' resources. The 'view' one could be a
representation of the data resource and use the user-agent and Accept:
header information to come out as intended.

> That I want to submit the update as a POST to
> http://server.com/users/userid seems obvious.  However its not so
> obvious to me that a GET of http://server.com/users/userid?mode=edit
> is the way to implement my edit view.
Finding the URI for the 'edit mode' has to happen via a hyperlink from some
starting point. It doesn't in fact have to be 'data-uri?mode=edit' it could
be somewhere completely different. Its the tags/location within the
'starting point' that tells you. You can implement the editing page any way
you want and don't have to worry about 'clean uri syntax'.
There are implementation details that suggest you keep the URI on the same
host and if you use HTTP Auth or cookies, that you 'root' those above both
resources - you can just use '/' for the path of the cookie to do that.

Its a tough problem, but I find it helps to think of the UI as a separate
space with its own URI - which don't necessarily have to be textually
similar to the 'data resources'.

Hope this helps.

mike






-----------------------------------------------------------------------------------
Post ID:1498
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-13 05:14:05
Subject:RE: [rest-discuss] REST Best Practices
Message:

Roger,

I really appreciate your always pragmatic approach.  A best practices
document would be very useful and your set is a very good start.

One of your points does bring up some recent thinking on my part:

> 3. As a corollary to (2) use nouns in the logical URI, not verbs. 
> Resources are "things" not "actions".

I know this perspective has been talked about regarding REST, but recently
I've shifted my thinking to view the trade-offs between the nouns vs. verbs
as a tangential issue.  To the extent that URIs should be view as an
universal resource addressing scheme, I really don't know if we need or want
to limit resources to be "nouns".

If we insist that URIs be nouns, we are basically saying that we should use
a different addressing scheme to implement "verbs".  In some ways, we are
justifying the need for something like SOAP in that that SOAP is a way to
define "verbs" that act on the "nouns" addressable via URIs.

Why should we not expose method calls via URIs so that they can participate
in the network effects?  If I want to publish a web service that allows
control of the AC in my building, why should I not provide individual links
for "On", "Off", and "Adjust Temperature"?  E-commerce sites to this all the
time with buttons that "Add to cart" or "Submit transaction".

Maybe another way to look at this is to look at the core "GET, PUT, POST,
and DELETE" as basic "access" mechanisms of an addressing scheme, not really
"verbs" in the sense of actions we would like to perform on things.  So,
REST isn't about reducing the "verbs" and making as many things "nouns" as
possible, but about having an universal addressing and access mechanism.

This also relates to the idea that it is preferable to avoid query strings.
This is certainly valid for accessing real "noun" type resources.  But, in
many cases, query strings are used when we are really accessing "verb" type
resources.  For example, I think it is a real stretch to say that a Google
search URI is pointing at a "noun" type resource.  We are basically asking
Google's search ("verb") resource to do a search for us and we pass along
our search criteria as query strings.

//Joe

-----Original Message-----
From: Roger L. Costello [mailto:costello@...]
Sent: Wednesday, June 12, 2002 12:06 PM
To: rest-discuss@yahoogroups.com; Costello,Roger L.
Subject: [rest-discuss] REST Best Practices


Has anyone put together a set of Best Practices for creating REST
services?  If not, how about getting started on one?  Here's some that
come to mind:

1. Provide a URI for each resource that you want (or will want)
exposed.  This is consistent with Tim Berners-Lee's axioms for the Web,
as well as the W3 TAG recomendations.

2. Prefer URIs that are logical over URIs that are physical.  For
example:

   Prefer:
     http://www.boeing.com/airplanes/747
   Over:
     http://www.boeing.com/airplanes/747.html

Logical URIs allow the resource implementation to change without
impacting client applications.

3. As a corollary to (2) use nouns in the logical URI, not verbs. 
Resources are "things" not "actions".

4. Make all HTTP GETs side-effect free.  Doing so makes the request
"safe".

5. Use links in your responses to requests!  Doing so connects your
response with other data.  It enables client applications to be
"self-propelled".  That is, the response itself contains info about
"what's the next step to take".  Contrast this to responses that do not
contain links.  Thus, the decision of "what's the next step to take"
must be made out-of-band.

6. Minimize the use of query strings.  For example:

    Prefer:
         http://www.parts-depot.com/parts/00345
    Over: 
         http://www.parts-depot.com/parts?part-id=00345

Rationale: it's easier for Web intermedaries such as proxy servers to
evaluate a request when it doesn't need to parse a query string.

What else?  Do you agree with this list?  /Roger


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1499
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-06-13 05:16:02
Subject:Re: [rest-discuss] multiple representations of a single resource
Message:

Chuck Hinson <Chuck.Hinson@...> wrote:

> That I want to submit the update as a POST to
> http://server.com/users/userid seems obvious.  However its not so
> obvious to me that a GET of http://server.com/users/userid?mode=edit
> is the way to implement my edit view.

If you're using CSS/JavaScript-aware browsers, couldn't you include both
modes in the same HTML representation and toggle between them by alternately
setting the display property to none and back again for the <div>s that
contain your two modes?

Jason









-----------------------------------------------------------------------------------
Post ID:1500
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-13 05:50:28
Subject:Re: [rest-discuss] REST Best Practices
Message:

----- Original Message -----
From: "Joe Hsy" <joe.hsy@...>

>
> Why should we not expose method calls via URIs so that they can
participate
> in the network effects?  If I want to publish a web service that allows
> control of the AC in my building, why should I not provide individual
links
> for "On", "Off", and "Adjust Temperature"?  E-commerce sites to this all
the
> time with buttons that "Add to cart" or "Submit transaction".
A network effect occurs when many participate in a limited arena - everybody
uses TCP/IP, rather than netbios, netbui, banyan, etc. By having many verbs,
there is no limited arena - no network effect.

Its an object+method approach rather than a function-only approach, and the
object+method are separately identifiable. If you don't separate
object+method, you get object1.invoke(), object2.invoke(), etc. It is a
/workable/ system, but with the slight change to object.method1(),
object.method2(), you get more benefit - but the benefit drops off if you
have object.method99(), object.mymethod99(), etc.

As for why not with the WWW, the reason is that there is already a slot in
the message for both id and method - use them. There are already a small set
of method defined - used them. The more that participate in this arena, the
more 'network effect' will happen.

>
> Maybe another way to look at this is to look at the core "GET, PUT, POST,
> and DELETE" as basic "access" mechanisms of an addressing scheme, not
really
> "verbs" in the sense of actions we would like to perform on things.  So,
> REST isn't about reducing the "verbs" and making as many things "nouns" as
> possible, but about having an universal addressing and access mechanism.
This is unclear to me - what is different between 'access' and 'action'? The
internal implementation of the interface can have any number of custom
actions - but the public contract and observed behavior is a common/standard
one. Exposing internal action names and assumptions is not necessary and
fragments the total space of addressable things.

>
> This also relates to the idea that it is preferable to avoid query
strings.
> This is certainly valid for accessing real "noun" type resources.  But, in
> many cases, query strings are used when we are really accessing "verb"
type
> resources.  For example, I think it is a real stretch to say that a Google
> search URI is pointing at a "noun" type resource.  We are basically asking
> Google's search ("verb") resource to do a search for us and we pass along
> our search criteria as query strings.
The fundamental shift of thinking 'Web' is that we aren't asking Google to
do a search - I bet you it's cached with some form of consistent hashing and
they /don't/ actually search anyway. What we are asking for are the
/results/ - and those results are just plain data blobs. You can think of it
as 'do search' - but that doesn't apply to all other systems, whereas the
'get results' /will/ apply to all other systems. The Google search URI
points to the results, not the query engine.








-----------------------------------------------------------------------------------
Post ID:1501
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-13 09:47:49
Subject:RE: [rest-discuss] REST Best Practices
Message:

From: S. Mike Dierken [mailto:mdierken@...]

> A network effect occurs when many participate in a limited arena -
everybody
> uses TCP/IP, rather than netbios, netbui, banyan, etc. By having many
verbs,
> there is no limited arena - no network effect.

It is probably better to say that it is commonality that creates network
effects as opposed to limitations, though limitation can have the
side-effect of creating de facto commonality.

Regardless, I think we're talking different verbs.  I am not talking about
adding more "verbs" to HTTP's GET, POST, PUT, DELETE, though there can be
justifiable reasons for doing that.  I'm talking about not getting hung up
on what can be a resource.  I see no reason why a resource can't represent
an action as oppose to data.

> Its an object+method approach rather than a function-only approach, and
the
> object+method are separately identifiable. If you don't separate
> object+method, you get object1.invoke(), object2.invoke(), etc. It is a
> /workable/ system, but with the slight change to object.method1(),
> object.method2(), you get more benefit - but the benefit drops off if you
> have object.method99(), object.mymethod99(), etc.

I am actually not encouraging one programming approach over the other.  As
you said, there are trade-offs.  I am merely saying that there isn't a good
reason to unilaterally discourage making functions URI-accessible.  In OOP,
there are times when you want to pass a function as parameter.  If URIs can
point to actions, there are interesting applications that can be built on
top of these URIs.

> This is unclear to me - what is different between 'access' and 'action'?
The
> internal implementation of the interface can have any number of custom
> actions - but the public contract and observed behavior is a
common/standard
> one. Exposing internal action names and assumptions is not necessary and
> fragments the total space of addressable things.

One way to view the current basic HTTP methods (GET, PUT, POST, DELETE) is
as basic addressing mechanisms that are not much different than core OOP
object get, deletes, assign.  That is what I mean by access.  Actions would
be something like a car.drive() method invocation.

Why do you think exposing action names would fragment the total space of
addressable things?  It is just another resource to be accessed using the
same set of public contract methods.

> The fundamental shift of thinking 'Web' is that we aren't asking Google to
> do a search - I bet you it's cached with some form of consistent hashing
and
> they /don't/ actually search anyway. What we are asking for are the
> /results/ - and those results are just plain data blobs. You can think of
it
> as 'do search' - but that doesn't apply to all other systems, whereas the
> 'get results' /will/ apply to all other systems. The Google search URI
> points to the results, not the query engine.

There is no question some searches are cached, but surely you are not
suggesting that all possible queries to Google are precached? 8-)  Whether
Google is doing a real search action may be debatable, but there is no doubt
that there is a need for action invocation in certain types of applications.
How would you advise that we think 'Web' on a post that purchases a stock?
Is the URI pointing to a purchase result?  That would be a rather awkward
way to look at it, don't you think?

If we insist that thinking 'Web' means we never think in terms of invoking
actions, then we are severely limiting the potential of the web, and we
force people to go "outside of the web" to write applications that are
transaction oriented.

Let's not forget that "the web" is only one application on the internet.
SOAP does not need the web to be successful or to benefit from "network
effect".  The web may have fueled the build-out of the internet, but it
isn't guaranteed to remain the dominant application that runs over the roads
it helped build.  The web needs to evolve to support the needs of the user
community or they will turn to other means to accomplish what they need.

I see problems with SOAP, but I also see that REST lacks clear guidelines
and support for transactional applications and I sense many people
struggling to write these types of applications in a RESTful way.  The
challenge is to provide a clear programming model and tools for developers
as opposed to listing ways in which applications are not be RESTful or
violate web principles.

//Joe




This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1502
Sender:rubys@...
Post Date/Time:2002-06-13 11:05:01
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

Paul Prescod wrote:
>
> WSDL hard-codes the choice of XSD.

False.

http://www.w3.org/TR/wsdl#_types

> If you want a hard-coded choice you
> can pay my consulting fee and I'll write you a report telling you which
> one to choose. ;)

Robert - don't do it ;-)

- Sam Ruby





-----------------------------------------------------------------------------------
Post ID:1503
Sender:Chuck Hinson <Chuck.Hinson@...>
Post Date/Time:2002-06-13 14:49:14
Subject:Re: [rest-discuss] multiple representations of a single resource
Message:

Jason Diamond wrote:
> Chuck Hinson <Chuck.Hinson@...> wrote:
> 
> 
>>That I want to submit the update as a POST to
>>http://server.com/users/userid seems obvious.  However its not so
>>obvious to me that a GET of http://server.com/users/userid?mode=edit
>>is the way to implement my edit view.
> 
> 
> If you're using CSS/JavaScript-aware browsers, couldn't you include both
> modes in the same HTML representation and toggle between them by alternately
> setting the display property to none and back again for the <div>s that
> contain your two modes?
> 
> Jason
> 
> 
> 
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 








-----------------------------------------------------------------------------------
Post ID:1504
Sender:Chuck Hinson <Chuck.Hinson@...>
Post Date/Time:2002-06-13 14:56:16
Subject:Re: [rest-discuss] multiple representations of a single resource
Message:

Jason Diamond wrote:
> Chuck Hinson <Chuck.Hinson@...> wrote:
> 
> 
>>That I want to submit the update as a POST to
>>http://server.com/users/userid seems obvious.  However its not so
>>obvious to me that a GET of http://server.com/users/userid?mode=edit
>>is the way to implement my edit view.
> 
> 
> If you're using CSS/JavaScript-aware browsers, couldn't you include both
> modes in the same HTML representation and toggle between them by alternately
> setting the display property to none and back again for the <div>s that
> contain your two modes?
> 
> Jason
> 


But I still need to be able to indicate which <div> to initially display. 
If somehwere else in my GUI I click on a link labelled 'Edit User', then I 
expect the edit view to come up.  If (somewhere else in my GUI) I click on a 
link labelled 'View User', then I expect the default view to come up.

--Chuck







-----------------------------------------------------------------------------------
Post ID:1505
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-13 15:22:59
Subject:Re: [rest-discuss] REST Best Practices
Message:

On Thu, Jun 13, 2002 at 01:14:05AM -0400, Joe Hsy wrote:
> Maybe another way to look at this is to look at the core "GET, PUT,
> POST,
> and DELETE" as basic "access" mechanisms of an addressing scheme, not
> really
> "verbs" in the sense of actions we would like to perform on things.  So,
> REST isn't about reducing the "verbs" and making as many things "nouns"
> as
> possible, but about having an universal addressing and access mechanism.

It's both.  You can't have one and not the other; they come together.
I strongly agree with Roger's point.

> 6. Minimize the use of query strings.  For example:
> 
>     Prefer:
>          http://www.parts-depot.com/parts/00345
>     Over: 
>          http://www.parts-depot.com/parts?part-id=00345
> 
> Rationale: it's easier for Web intermedaries such as proxy servers to
> evaluate a request when it doesn't need to parse a query string.

I'll comment on this point while I'm here ...

I don't think you need to minimize the use of query strings.  They're
good and fine.  What you might be trying to say is that non-transient
resources should have a "principal" URI that does not include a query
string.  For example, a query returning multiple employees probably
doesn't need one, but one for an individual employee probably does.  The
reason I think this is a good idea is that it allows for later
decomposition of these resources (i.e. treat as containers for composite
state).

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1506
Sender:Chuck Hinson <Chuck.Hinson@...>
Post Date/Time:2002-06-13 15:38:23
Subject:Re: [rest-discuss] REST Best Practices
Message:

Mark Baker wrote:
> 
> It's both.  You can't have one and not the other; they come together.
> I strongly agree with Roger's point.
> 
> 
>>6. Minimize the use of query strings.  For example:
>>
>>    Prefer:
>>         http://www.parts-depot.com/parts/00345
>>    Over: 
>>         http://www.parts-depot.com/parts?part-id=00345
>>
>>Rationale: it's easier for Web intermedaries such as proxy servers to
>>evaluate a request when it doesn't need to parse a query string.
> 
> 
> I'll comment on this point while I'm here ...
> 
> I don't think you need to minimize the use of query strings.  They're
> good and fine.  What you might be trying to say is that non-transient
> resources should have a "principal" URI that does not include a query
> string.  For example, a query returning multiple employees probably
> doesn't need one, but one for an individual employee probably does.  The

Doesnt need one what? - a principal URI or a query string.

--Chuck

> reason I think this is a good idea is that it allows for later
> decomposition of these resources (i.e. treat as containers for composite
> state).
> 
> MB








-----------------------------------------------------------------------------------
Post ID:1507
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-13 17:13:12
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

rubys@... wrote:
> 
> Paul Prescod wrote:
> >
> > WSDL hard-codes the choice of XSD.
> 
> False.

Sorry. "WSDL implementations hard-code the choice of XSD."

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1508
Sender:Sam Ruby <rubys@...>
Post Date/Time:2002-06-13 18:05:40
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

Paul Prescod wrote: 
>
>>> WSDL hard-codes the choice of XSD.
>>
>> False.
>
> Sorry. "WSDL implementations hard-code the choice of XSD."


There may exist a WSDL implementation that hard-codes the choice of XSD, 
but the reference implementation [1] of the Java APIs for WSDL [2] most 
decidedly does not.

[1] http://www-124.ibm.com/developerworks/projects/wsdl4j/
[2] http://www.jcp.org/jsr/detail/110.jsp







-----------------------------------------------------------------------------------
Post ID:1509
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-06-13 18:23:10
Subject:Re: [rest-discuss] Path info v query string
Message:

On 6/12/02 7:54 PM, "Chuck Hinson" <Chuck.Hinson@...> wrote:

> http://server.com/something?item=itemname
> 
> vs
> 
> http://server.com/something/itemname
> 
> 
> Might one form have different semantics than the other?

Hardcore purist's answer:  they are semantically equivalent.  In fact, all
well-formed URI are identical except inasmuch as dereferencing different
ones yields different representations.  By this reasoning, http://12345
would be just as good, because the "information" carried in the hierarchical
part cannot be considered in interpreting the URI (except by the server that
has that very interpretation as its primary function.)  Now, nobody believes
all that, but that's the literal interpretation of the various axioms, etc.

Moderate answer:  They're equivalent, use whichever one tickles your fancy.

Radical answer --- my own opinion.  Wherever there's hierarchy in your
resource model, it should be reflected in your URIs.  If "something" is (a)
a container for items, (b) an object of interest in its own right, and if
items are objects of interest in their own rights that are contained by
"something," then the strictly hierarchical form is preferable.

In addition, it's worth noting that overuse of query strings to convey what
could be represented as hierarchical structure causes proxies / caches and
other intermediaries or agents to do more work or, at worst, to fail
entirely.  It should be possible to compare URIs for determination of
equivalence (something that proxies, crawlers, and the like do all the time)
by a simple lexical test.  Use of nonordinal keyword-based query strings
messes this up;  it's impossible to determine the difference (or lack
thereof) of

http://server.com/container?item=itemname&color=red
http://server.com/container?color=red&item=itemname

Without requiring the proxy etc. to interpret the query string;  and indeed,
it's not possible for proxies to do that reliably, because the resource
implementation could either require ordinality or not, and there's no way to
tell.  The safest thing for the proxy etc. to do is ignore all URIs with
query strings and, indeed, some have in the past;  .: use query strings
sparingly if at all, and if you do try to discriminate based on only a
single property / param / value.

Jb








-----------------------------------------------------------------------------------
Post ID:1510
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-13 18:28:54
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

Sam Ruby wrote:
> 
>...
> 
> There may exist a WSDL implementation that hard-codes the choice of XSD,
> but the reference implementation [1] of the Java APIs for WSDL [2] most
> decidedly does not.

Does there exist a WSDL implementation that allows me to generate
programming language clients from any other schema language? Can I use
RELAX with Axis? Schematron with the .NET Framework?

Or let me back up a step and ask, could I, given a RELAX implementation
for Java, plug it into Axis for use in my WSDLs for bidirectional
conversions to Java types. Could I do that through existing hooks or
only by changing Axis' implementation?

But we're getting off the topic of the original question. REST does not
require de jure standardization and can use either runtime types (like
the SOAP encoding) or design time types (like WSDL+XML Schema) just as
SOAP+WSDL systems can. If Axis allows me to plug in RELAX in a
well-documented way, great!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1511
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-13 18:43:32
Subject:RE: [rest-discuss] REST Best Practices
Message:

> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> 
> It's both.  You can't have one and not the other; they come together.
> I strongly agree with Roger's point.

Again, as I replied to Mike, I think we're talking about different levels of
abstraction regarding "nouns" and "verbs".

At the protocol level of abstractions, we can say that end points are nouns
and the protocol is the verb.  At this level, there is no question that a
small well-defined set of verbs will optimize the network effect.

Take the phone system as an example (a prime network effect system).
Telephony devices are the nouns and there is one main verb - "to call".
From this perspective, the many-noun-to-few-verbs ratio is desirable.

However, from a telephony application perspective, there is no reason to
prevent people from modeling a telephony end-point as an action.  For
example, we "page" a person by calling a pager.  To some people it is a more
natural way to think about the actual "action" of paging someone as opposed
to "calling" a paging device.  I don't see a problem with abstracting the
phone number to a "paging" action as opposed to a paging device.

Let's take a look at the sentence again:

> 3. As a corollary to (2) use nouns in the logical URI, not verbs. 
> Resources are "things" not "actions".

URIs are like phone numbers - both are universal addressing schemes.  All
I'm saying is that we shouldn't arbitrarily discourage people from modeling
"actions" as resources for those applications that makes sense.

Buying a book is a clearly an action.  You can abstract the URI into a noun
by calling it a "purchase transaction record", but to the end user pushing
the "buy" button, it is still an action.

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1512
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-06-13 20:50:06
Subject:Re: [rest-discuss] a RESTful architecture?
Message:

At 09:24 AM 13/06/2002, Paul Prescod wrote:
>Jason Diamond wrote:
> >
> >...
> >
> > That's a definite true but that means you'd have to fetch the list of
> > patients just to get the information to create a new one.
>
>Okay, fair enough. That's a performance concern.
>
>But I'm getting a little lost in the discussion. Don't you need to fetch
>the list of patients to get the link to the "runtime schema"? So you
>still have a performance issue. If you're thinking about performance
>then maybe the schema should be the parent object and the list should be
>the child. Or they could have a common parent (perhaps it summarizes
>information from the patient list).

I don't agree with the notion that a resource model needs to be different
due to performance concerns. What happens if the performance concerns change
due to unforeseen circumstances and/or innovation? The
representation might be different, but not the model.

Could you (or should you) model the metadata as a separate resource?
Something along the lines of /metadata/patient, /metadata/orders/procedure1,
or /patients/metadata, /orders/procedure1/metadata.


> >...
> > I'm not sure I understand. In our system there is either a human entering
> > the data into the fields for each resource or there is another automated
> > interface that knows how to map fields from systems in other parts of the
> > hospital into our fields. Either way, they need to know the basic structure
> > of the objects including the field names, types, constraints, etc.

Along these lines, when you do a POST to /orders (specifying the type in 
the posted data) and it responds with a location where to put the new 
order, i.e. /orders/new_uuid, doing a GET on this location could retrieve 
an empty order of the specified type along with a link to the 
schema/metadata, thus giving you all the structure information that is needed.

Robert








-----------------------------------------------------------------------------------
Post ID:1513
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-06-13 22:22:04
Subject:RE: [rest-discuss] a RESTful architecture?
Message:


> -----Original Message-----
> From: Jason Diamond [mailto:jason@injektilo.org] 
>
>  Since everything in RDF is 
> identified using URIs, however, all you really need to know 
> is the URIs for the classes and properties that you're 
> interested in. 

After you agree on terms you have to agree on processing; there's more
to know than resources. We can't declare behaviour away and just write
down everything we know as RDF triples. RDF doesn't have a processing
model so we have to assume that the semantics associated with the URIs
are extremely clear as a boost to implementers. 

Bill de hra







-----------------------------------------------------------------------------------
Post ID:1514
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-06-13 23:09:06
Subject:RE: [rest-discuss] CGI = Cold Fusion = SOAP? Is the Web today mostly non-RESTful?
Message:

> -----Original Message-----
> From: Chuck Hinson [mailto:Chuck.Hinson@avercom.net] 
>
> Not that it's completely relevant to the discussion at hand, but I 
> don't think amazon is completely RESTful.
> 
> Try this:
> 
> Go to the front page and do a search for REST (under All Products).


Yep. I tried on amazon.co.uk, with the same outcome (and after with my
own uid at the end). Weird that they gateway search like that. Is that
for session tracking?

Bill de hra







-----------------------------------------------------------------------------------
Post ID:1515
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-14 07:13:59
Subject:Re: [rest-discuss] REST Best Practices
Message:

On Thu, Jun 13, 2002 at 11:38:23AM -0400, Chuck Hinson wrote:
> > 
> > I don't think you need to minimize the use of query strings.  They're
> > good and fine.  What you might be trying to say is that non-transient
> > resources should have a "principal" URI that does not include a query
> > string.  For example, a query returning multiple employees probably
> > doesn't need one, but one for an individual employee probably does.
> The
> 
> Doesnt need one what? - a principal URI or a query string.

A principal URI.

BTW, by "transient", I don't mean that it might return 404 at some
point in the future, only that it's rarely (if ever) used outside
of the context of a search.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1516
Sender:Dan Brickley <danbri@...>
Post Date/Time:2002-06-14 10:43:58
Subject:Open Archives Initiative Releases Version 2.0 of the Protocol for Metadata Harvesting (fwd)
Message:


REST folk should find this interesting, imho...


---------- Forwarded message ----------
Date: Fri, 14 Jun 2002 06:33:27 -0400
From: Carl Lagoze <lagoze@...>
To: DC-GENERAL@...
Subject: Open Archives Initiative Releases Version 2.0 of the Protocol
        for Metadata Harvesting

For immediate release June 14, 2002

Open Archives Initiative Releases Version 2.0 of the Protocol for
Metadata Harvesting


Ithaca, NY & Los Alamos NM-The Open Archives Initiative is pleased to
release version 2.0 of the Open Archives Initiative Protocol for
Metadata Harvesting (OAI-PMH). The release of OAI-PMH v.2.0 comes after
16 months of worldwide experimentation with version 1.x of the protocol,
an 8 month revision process by the OAI-tech group, and 4 months of
alpha/beta testing. Thanks to this rigid testing and revision, we feel
confident to release the OAI-PMH version 2.0 as a stable specification.

A full copy of this press release with information about the features of
OAI-PMH version 2 is available at
http://www.openarchives.org/news/oaiv2press020614.html.

The OAI-PMH version 2 specification is available at
http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm.

Visit the OAI web site at http://www.openarchives.org for more related
information.

Carl Lagoze and Herbert Van de Sompel
OAI Executive







-----------------------------------------------------------------------------------
Post ID:1517
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-15 14:49:20
Subject:Use verbs in URIs? [was: REST Best Practices]
Message:

This discussion on whether verbs should be used in URIs is excellent! 
Thanks Joe for raising this issue.  It has certainly stimulated new
ideas and questions in my mind.  Let's not let this discussion stop
until we have fully explored all facets of this issue and have arrived
at consensus.  I think that it is important that we (the REST community)
speak with a unified voice.

Let me try to first summarize the issue and both sides of the argument. 
Then I will add my own thoughts on the topic.

The issue is this: should a URL be allowed to have verbs in it?

Example.  Here's an example of a URL that contains a verb (add-to-cart)

    http://www.parts-depot.com/parts/00345/add-to-cart

Let's now summarize both sides of this issue

The Nouns-Only Camp

This side of the argument says that URLs should only contain nouns. 
They say that verbs should not be allowed in URLs.  Here's why:

1. By definition, resources are "things" not "actions".  URLs identify
resources, not functions.  

2. Separation of concerns: keep the identification (i.e., the URL) of a
resource separate from the methods (HTTP GET, POST, PUT, DELETE) applied
to the resource.  In OO terms we might think of the URL as providing the
name of the Object, and the HTTP methods as the generic set of methods
on the Object.  For example:

     {http://www.parts-depot.com/parts/00345}.GET()

3. Generic interface: keep the interface to resources generic - the HTTP
methods.  When you allow verbs then you are essentially expanding the
interface.  For example:

   http://www.parts-depot.com/parts/00345/add-to-cart

is essentially a composition of methods:

     {{http://www.parts-depot.com/parts/00345}.add-to-cart()}.GET()

Thus, the resource (part 00345) is exposing an implementation function,
add-to-cart.

The Verbs-Allowed Camp

This side of the argument says that URLs should be allowed to contain
verbs as well as nouns.  Here's why:

1. It seems natural that you would want to identify a resource and tell
it to take an action.  Some examples:

   http://www.my-home.org/air-conditioning/on

   http://www.google.com/search?topic="juice-machines"

2. Verb-oriented URLs are very program-friendly.  For example, a program
to control devices in my house might look like this:

   http://www.my-home.org/connect-to-central-computer
   http://www.my-home.org/air-conditioning/on
   http://www.my-home.org/air-conditioning/adjust-temp?value=68
   http://www.my-home.org/stereo/on
   http://www.my-home.org/stereo/play-cd?cd=Timeless-Serenity

3. Unilaterally prohibiting functions as URI-accessible makes the Web
less friendly and useable, as I will need to contort things to get
around this constraint.  Imagine doing the above using just nouns.

Is this a fair summary of both sides?  If not, please add/correct.

Now for my own comments:

As always, I think best with a concrete example in front of me.  So,
let's consider Parts Depot.  This company has deployed some Web services
to enable clients to:

1. Get a list of parts
2. Get detailed information about a part
3. Purchase parts

It is the third service (purchase parts) which is most relevant to this
discussion.

Let's suppose that the client has used the first service to get the
parts list, and then used the second service to drill down to get
detailed information about part 00345.  Suppose that this is the
response:

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"   
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>
          This part is used within the frap assembly
      </Description>
      <Specification
xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>10</Quantity>
</p:Part>

Suppose that the client decides that he/she wants to "add this to
his/her shopping cart".  To provide this capability Parts Depot may
provide another element <AddToCart> when it returns detailed part
information.  Thus, instead of the above XML document the client would
receive this:

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"   
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>
          This part is used within the frap assembly
      </Description>
      <Specification
xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>10</Quantity>
      <AddToCart href="http://parts-depot.com/parts/00345/add-to-cart"/>
</p:Part>

Note the last element, <AddToCart href="..."/>.  The URL in the href
attribute:

    http://parts-depot.com/parts/00345/add-to-cart

clearly contains a verb, add-to-cart.

I have a couple of thoughts about this design:

1. If the HTTP method for the above URL is GET then it is violating the
principle that all GETs should be side-effect free.

2. One of the principles of REST is that the client should maintain
his/her own state.  The server should not do so.  The above approach has
the server maintaining state about the client.

Here's an alternative solution.  The client creates a Purchase Order
(PO) which identifies the parts he/she is interested in purchasing. 
When the client finds a part that he/she is interested in, the client
will add that part number to the PO.  When the client is ready he/she
submits the PO.  Some things to note:

1. The PO represents the "shopping cart".

2. The PO is composed on the client side, not the server side.

This second design seems to be more in the spirit of REST.

Those are the two ways that I see for implementing the purchase parts
Web service.  Are there other (better) ways?  Any comments?  /Roger







-----------------------------------------------------------------------------------
Post ID:1518
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-15 16:18:30
Subject:Re: Use verbs in URIs? [was: REST Best Practices]
Message:

Here's an alternate view of purchasing that might make the resource 
view more clear (and more like nouns):

There are at least two stages of purchasing on the Web:
1. making commitments to exchange money (via credit card) for goods.
2. delivering the goods and charging the credit card.

Except in the case of downloadable electronic goods (e.g. music or 
software), we don't actually handle the goods and money online.

So in stage 1, the Web resources are not actions, they are 
commitments: I promise to pay $30 via my credit card if Amazon 
promises to send me this book.  At this same time, Amazon gets a 
credit charge authorization from the credit card handler, which 
should be but isn't usually a Web resource.

In stage 2, the Web resources include documentation that Amazon 
shipped the book, maybe a shipment tracking ID that could link to a 
UPS Web resource representing the package in transit, and (should be, 
but isn't) a Web resource representing the credit card charge.

So there are no "actions" except GETting, PUTting or POSTing Web 
resources.  The resources themselves represent commitments or 
documentation of actions taken in the meat world.

Even electronic funds transfer does not actually transfer money, it's 
just bits - money of account.  Relevant Web resources would include 
Accounts and Transfer documents.

Almost anything in business has already been represented by a 
document, which could become a Web resource.

Downloading electronic goods is an action.  Is there a common method?

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1519
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-15 21:05:22
Subject:RE: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

Roger wrote:
> Those are the two ways that I see for implementing the purchase parts
> Web service.  Are there other (better) ways?  Any comments?  /Roger

I'm not sure where my version of this verb/URI issue stands, but here is the way
I have designed it in my own efforts.  As I mentioned before, I have a
pre-developed set of resource types, namely methods, components, topics, queues,
etc that are published in a node's hierarchical namespace.  Each type is a
different type of abstraction, but all of them have methods that can be invoked.
Here is the way I see how each of the HTTP methods allow nodes to interact with
them:

------

HTTP GET - allows you to ask a node to return information about a resource at a
URI.  In the case of a method resource, the results of a HTTP GET with
/Fruit/Apple/Washington/harvest might look like this:

 <item key='harvest' type='method'>
    <list>
        <item key='baseName' value='harvest' />
        <item key='baseName' value='cosecha' scope='/Language/ES />
        <item key='optionalParam' type='boolean'>param5Name</item>
        <item key='requiredParam' type='singleText'>param5Name</item>
        <item key='requiredParam' type='multiText'>param4Name</item>
        <item key='requiredParam' type='singleSelect'>param1Name</item>
        <item key='optionalParam' type='multiSelect'>param2Name</item>
    </list>
 </item>

So a GET really only lets you to discover the resource.  Obviously, if you had a
XSL converter, the above XML is easily converted into an HTML form that a
browser can use to can actually invoke the method.

HTTP PUT - instead of getting a pre-existing resource like the one above, it
allows you to effectively copy a resource in its current state to another node.
You are effectively publishing it on the destination node.

HTTP POST - in the case of method resources, like the one above, this is as
close as you get to the "verb" notion, where POST has optional/required
parameters that have been specified in the body and/or request line's query
string.

HTTP DELETE - deletes the published resource at the URI.

------

In essence, even though the URI provides you with the location of a method
resource on the network, it's not pointing to a verb per se.  It is pointing to
the verb "as a noun".  Once you POST to it, then that's when you submit
information to the resource being hosted by the server, and in this case, the
harvest method uses it to invoke behavior.

How far on or off base is this approach to REST?  Do the REST purists out there
agree with it?  Would this be more noun-like or verb-like?

Thanks,
Philip







-----------------------------------------------------------------------------------
Post ID:1520
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-15 21:42:27
Subject:Re: [rest-discuss] REST Best Practices
Message:

Joe Hsy wrote:
> 
>...
> 
> However, from a telephony application perspective, there is no reason to
> prevent people from modeling a telephony end-point as an action.  For
> example, we "page" a person by calling a pager.  To some people it is a more
> natural way to think about the actual "action" of paging someone as opposed
> to "calling" a paging device.  I don't see a problem with abstracting the
> phone number to a "paging" action as opposed to a paging device.

Okay, but let's take this analogy back to the Web. Wouldn't the best way
to page someone be to POST a page so that the thing you've POSTed has a
URI? Then the person doing the paging and the paged person both have a
name for the page, the person doing the page could refer to it later
(e.g. to ask to cancel it (DELETE), or extend it (sub-POST)) and so
forth.

But I do think that there is room for a layer of abstraction on the
client side that allows a natural OO API rather than just HTTP methods.

>...
> Buying a book is a clearly an action.  You can abstract the URI into a noun
> by calling it a "purchase transaction record", but to the end user pushing
> the "buy" button, it is still an action.

Okay, but we might as well call it "submit purchase request" because we
are going to make a new purchase request object and it will have a new
URI. "Buy" might be more familiar but "submit purchase request" is more
accurate. And you are going to want a way to navigate back to *all* of
your purchase requests later, so somewhere there must be a list of them.
So an even more accurate name for the service is "add new purchase
request", i.e. "POST" to "your_purchase_requests".

When I analyze these things I usually don't have a need for verbs as
URIs *except* to work around implementation limitations.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1521
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-15 21:59:23
Subject:Re: [rest-discuss] Re: Use verbs in URIs? [was: REST Best Practices]
Message:

bhaugen32 wrote:
> 
>...
> 
> Downloading electronic goods is an action.  Is there a common method?

I don't think I understand the question. GET is how you download things
using HTTP.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1522
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-15 22:06:39
Subject:Re: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

Philip Eskelin wrote:
> 
>...
> 
> I'm not sure where my version of this verb/URI issue stands, but here is the way
> I have designed it in my own efforts.  As I mentioned before, I have a
> pre-developed set of resource types, namely methods, components, topics, queues,
> etc that are published in a node's hierarchical namespace.  

I guess the basic question is whether you *need* method objects. A
REST-purist view would be that you should use methods as an
implementation technique to implement a resource view of the world.
Since I don't know what method objects you have, I can't
resource-decompose them. But in most cases you will want an action to
have a side-effect that creates a resource+URI, and you will want the
newly created resource to be in some container. So you can instead use a
POST on the container.

>...
> HTTP PUT - instead of getting a pre-existing resource like the one above, it
> allows you to effectively copy a resource in its current state to another node.
> You are effectively publishing it on the destination node.

It's not clear to me how you can copy a method. After all, the real
method is the programming code behind it. And that code will depend on a
complex network of other state. So PUT-ting to a method resource doesn't
make much sense to me.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1523
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-15 22:11:11
Subject:Changing relationship between SOAP and REST
Message:

This is my rambling sense of the state of the debate between SOAP and
REST.

To their credit, the SOAP working group has responded to our criticism
of the SOAP model and I think that there is a 50/50 chance that the most
severe incompatibility between the two models can be fixed over the next
while. In particular, I believe that they are coming to agree that the
"single endpoint" model is architecturally unsound. I have two reasons
to believe that this is the case. The first is that they have defined a
"GET" binding for SOAP and agreed that it should be used for any HTTP
SOAP service that has the semantics of HTTP's GET. The second is that
I've gotten generally positive agreement that the SOAP primer should
specifically say that an endpoint-per-resource model makes more . I
haven't got MUCH feedback but the feedback I've gotten so far has been
positive:

 * http://lists.w3.org/Archives/Public/xml-dist-app/2002Jun/0036.html

Here is the proposed text:

"One of the principles of Web Architecture is that all important
resources should be identified by URIs. This implies that many
well-architected SOAP services will be embodied as large 
numbers or resources, each with its own URI.  Indeed, many
such resources are likely to be created dynamically during
operation of the service, as new information becomes available.
For example, a service offering stock prices might use 
a distinct URI for each stock tracked, and perhaps for
each date and time for which quotes are provided."

This is a non-normative change to the specification but it implies
massive changes to SOAP toolkits and to WSDL. I believe that most
existing SOAP toolkits do not allow easy implementation of this
convention. This is especially true for toolkits for statically typed
languages with "interface generators." But that's okay, because these
toolkits take their lead from WSDL, and one of the WSDL requirements
(that I proposed) also addresses this issue:

"The description language SHOULD allow describing Messages that include
references (URIs) to strongly-typed referents, both values and
Services."

In other words, it should be possible to have a SOAP message or HTTP
message with a URI in it that points to a SOAP/HTTP endpoint described
by another WSDL. This will at least make it possible to use WSDL in a
system where "hypermedia is the engine of application state." We should
work with the WSDL group to make sure that this happens and that
HTTP-based services are strongly represented. We should also try and
work with open source toolkit implementors to make sure that they do the
right thing as examples for the closed-source vendors.

My current hope for the future is that a single URI will commonly
support both HTTP and SOAP methods. For instance, if you avoid the
various optional SOAP features (SOAP encoding, SOAP headers), the only
real difference between the new SOAP GET and a plain old HTTP GET is
that the one returns a SOAP-wrapped body and the other does not.
Content-negotiation could trigger which happens. (that should perhaps be
added normatively to the SOAP specification!). In many situations, you
could just accept that for marketing reasons you must wrap your XML in a
SOAP:Envelope and SOAP:Body and move on. POST is similar to GET. You can
probably just build your REST service and ignore the SOAP:Envelope and
SOAP:Body. SOAP does not define PUT or DELETE, so the "HTTP side" of a
service can use them without conflict. REST could be viewed as a sort of
best-practices for SOAP usage -- even if we're not using much of SOAP.

Hmmmm. There should probably be a TAG ruling on whether it is
appropriate to use SOAP methods to do something that is logically
equivalent to an HTTP PUT and DELETE or whether you should just use HTTP
PUT and DELETE. It seems to me that it kind of follows naturally from
the GET decision but it might be politically harder because PUT and
DELETE are not as popular or architecturally important as GET.

But all of this will only work if the toolkits allow it. If it is
prohibitively expensive to assign URIs to objects, or to accept *both*
HTTP and SOAP methods on the same object, we will find ourselves back at
odds with SOAP again. 

I think that pushback is quite likely because SOAP has many tensions (I
would go so far as to say contradictions) in its design. It's an RPC
protocol but not really. It's a synchronous protocol but not really. The
one that is dangerous to REST: it is a web protocol but it is also
"transport agnostic". This latter means that it could be tricky to make
a SOAP API or user interface that allows really good Web-based Web
Services and then allows you to push a button and get the same features
on MQSeries or SMTP. REST people could fantasize that this might result
in the Web model leaking onto other transports but alternately it might
mean that Web features (like SOAP GET and one-endpoint-per-resource)
just don't get implemented.

In addition, there are all of the SOAP add-ons which will come to the
fore when SOAP is standardized. Someone will have to ensure that
WS-Security, WS-Routing, transaction standards etc. interact properly
with HTTP and Web architecture etc. Keeping up with this stuff is a
full-time job!

In other words, there is a fight on for the Soul of SOAP -- will it be
COM for the Internet, or an XML wrapper for the Web, or something else
entirely?

And of course there remains the issue of pre-defined methods as in HTTP
versus invent your own as in the traditional SOAP style.

Nevertheless, the good news is that it if things go the right way, it
will be increasingly possible to tell our customers and bosses
(honestly!) that we are using SOAP and REST. Perhaps if we are vocal
enough with that message the other standards and implementations will
fall into place more easily.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1524
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-16 07:24:40
Subject:RE: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

Hi Roger,

I'm not sure that there is sufficient disagreement here to warrant "camps"
in this discussion, but as usual, you've done a great job summarizing the
salient points.

I can't speak for others, but your points accurately reflected my general
thinking.  I espcially liked the www.my-home.org examples as an application
where action verbs are a much more natural way of modeling the system.

Regarding the parts-depot purchase example, I think having a URL that would
model the "add-to-cart" action is fine.  You can simply make it a POST to
preserve the no-side-effect condition for GET (maybe GET of that URL will
return the part availability?).  In fact, a POST could provide an added
opportunity to ask for additional authentication.

I think having the action return a set of URLs that provides follow-on
actions would be even more interesting.  For example, you could have the
add-to-cart action return URLs that allows you to remove from cart or go to
checkout.

Implementing a client-side shopping cart is certainly reasonable, but
website have server-side shopping carts because they want to track customers
as they actually add things to the carts even if they don't buy.  It allows
them to remind the shopper and also gather more customer behavior info.

Again, your pragmatic examples are very useful illustrations of the issues.

Thanks!

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1525
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-16 07:46:39
Subject:RE: [rest-discuss] REST Best Practices
Message:

-----Original Message-----
From: Paul Prescod

> Okay, but let's take this analogy back to the Web. Wouldn't the best way
> to page someone be to POST a page so that the thing you've POSTed has a
> URI? Then the person doing the paging and the paged person both have a
> name for the page, the person doing the page could refer to it later
> (e.g. to ask to cancel it (DELETE), or extend it (sub-POST)) and so
> forth.
> 
> But I do think that there is room for a layer of abstraction on the
> client side that allows a natural OO API rather than just HTTP methods.

I agree on both points.  I was merely using paging in the telephony domain
to indicate that we're discussing different abstractions of the words verbs
and nouns.  Paging applications on the web could probably be modeled just as
well using a "page" as document model v.s paging as action model.

I've been looking for exactly this type of natural OOP API as an abstraction
for implementing transactional applications within the REST mdoel.

> Okay, but we might as well call it "submit purchase request" because we
> are going to make a new purchase request object and it will have a new
> URI. "Buy" might be more familiar but "submit purchase request" is more
> accurate. And you are going to want a way to navigate back to *all* of
> your purchase requests later, so somewhere there must be a list of them.
> So an even more accurate name for the service is "add new purchase
> request", i.e. "POST" to "your_purchase_requests".
> 
> When I analyze these things I usually don't have a need for verbs as
> URIs *except* to work around implementation limitations.

I have no doubt that we can convert any action into a "noun" concept.  As
you said, purchasing something is conceptually similar to creating a
purchase record.  An action typically creates a state change that can be
captured as an document record.

This is fine for many actions, but for many other actions, this is very
awkward thinking.  Few people really thinking of turning on the air
conditioning as changing the state of the AC into the "ON" state.  Starting
a race is an action that isn't naturally modeled as a "noun".

I definitely agree that having a record created of an action as a
consequence is often useful, but doesn't necessarily make that the natural
mental model for programmers or ultimately, end-users.

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1526
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-16 11:41:30
Subject:Re: Use verbs in URIs? [was: REST Best Practices]
Message:

Paul Prescod wrote:
> bhaugen32 wrote:
> > Downloading electronic goods is an action.  Is there a common 
method?
> 
> I don't think I understand the question. GET is how you download 
things
> using HTTP.

I know.  I'm afraid I expressed my question very badly.  I should 
have written "is there a pattern for how Web sites usually handle the 
sale of downloaded products, including URIs, methods, etc."? I 
haven't done it for a while, and didn't pay any attention when I did.

The context was purchasing, where somebody wrote that purchasing was 
an action, and the URI should contain a verb.  

My response was that you seldom actually purchase something on the 
Web, in the sense that you purchase something from a store, where you 
take the goods and hand them the money or swipe your credit card.  
Instead you document your commitment to pay if they send you the 
goods, and then later they document that they shipped the goods, etc.

The exception was where you downloaded some bits.

The URI often says /download, which I interpret as a verb.

If memory serves my right, if you're buying the stuff, there is 
usually a POST where you authorize payment from your credit card, and 
then they give you permission for the actual download resource.

At that point, I know that HTTP says use GET, but I have no idea what 
Web sites actually use.  There might also be a state change where 
they record the fact that you downloaded the stuff.








-----------------------------------------------------------------------------------
Post ID:1527
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-16 13:36:07
Subject:Sanity check please: my article on REST
Message:

In the interest of promoting REST I have written an article[1] titled:

   Building Web Services the REST Way

I am planning on submitting it to xml.com for publication.  However,
prior to doing I would like a sanity check (I don't want to embarrass
myself nor the REST community).

So, I have a favor to ask: would you take a look at the article and give
me feedback?  I can accept criticism, so if you think that it's not up
to par please let me know.  Thanks!  /Roger

[1] http://www.xfront.com/REST-Web-Services.html







-----------------------------------------------------------------------------------
Post ID:1528
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-16 19:26:14
Subject:Re: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

> 1. It seems natural that you would want to identify a resource and tell
> it to take an action.  Some examples:
>
>    http://www.my-home.org/air-conditioning/on
>    http://www.google.com/search?topic="juice-machines"

You've identified two resources - what part tells it to take an action? and
what action does it take?

http://www.my-home.org/air-conditioning/on could test whether the unit was
on or not. It could toggle the power. It could set the power on, lots of
things.

http://www.google.com/search?topic="juice-machines" - what is it you are
searching for within the 'juice-machines' topic? Or does it return
true/false if the topic exists?


>
> 2. Verb-oriented URLs are very program-friendly.  For example, a program
> to control devices in my house might look like this:
>
>    http://www.my-home.org/connect-to-central-computer
>    http://www.my-home.org/air-conditioning/on
>    http://www.my-home.org/air-conditioning/adjust-temp?value=68
>    http://www.my-home.org/stereo/on
>    http://www.my-home.org/stereo/play-cd?cd=Timeless-Serenity
What verb is this? It seems more like a 'closure' - binding action and data
into a single opaque 'invokable' object.
It looks more like these URI are reflections of procedural instructions.
They look to be dependent on the correct sequence to operate correctly. Can
you adjust the temp before visiting the 'on' URL? Having sequence dependency
is an issue in networked apps regardless of what paradigm you are taking.

>
For me it is more program friendly to have something like:
 home.server = "http://www.my-home.org/";
 home.put("air-conditioning/power,"on");
 home.put("air-conditioning/temp","68");
 home.put("stereo/power","on");
 home.put("stereo/current-album","Timeless-Serenity");

If you wanted api based access, it wouldn't be hard to define objects with
named properties where each property maps to a URI. You could then have the
client do something like:
 home.airConditioner.power = "on";
 home.airConditioner.temp = "68";
 home.stereo.power = "on";
 home.stereo.album = "Timeless-Serenity";

The benefit would be that you could also query the current values with the
same object/property structures.

I wouldn't do the 'connect-to-central-computer' because I wouldn't trust
that my-home.org would maintain that connection, or that it wouldn't crash,
etc.


> 3. Unilaterally prohibiting functions as URI-accessible makes the Web
> less friendly and useable, as I will need to contort things to get
> around this constraint.  Imagine doing the above using just nouns.
I always do - its easy, very simple and powerful.

...

> Note the last element, <AddToCart href="..."/>.  The URL in the href
> attribute:
>
>     http://parts-depot.com/parts/00345/add-to-cart
>
> clearly contains a verb, add-to-cart.
I thought it clearly contained the verb "parts". Or maybe it was verb 345. I
forget.

>
> I have a couple of thoughts about this design:
>
> 1. If the HTTP method for the above URL is GET then it is violating the
> principle that all GETs should be side-effect free.
>
> 2. One of the principles of REST is that the client should maintain
> his/her own state.  The server should not do so.  The above approach has
> the server maintaining state about the client.
Yes - it looks like the add-to-cart URI doesn't know which shopping cart to
add that part to. It'd be easier to have the client explicity ask for a
shopping cart and repeatedly add (POST) part references to it. You'd get
into the non-idempotent issue though - if you POST twice, did you really
mean to add two items or was it a transmission problem? It's probably better
to just transfer a complete representation of the clients PO.

>
> Here's an alternative solution.  The client creates a Purchase Order
> (PO) which identifies the parts he/she is interested in purchasing.
> When the client finds a part that he/she is interested in, the client
> will add that part number to the PO.  When the client is ready he/she
> submits the PO.  Some things to note:
>
> 1. The PO represents the "shopping cart".
> 2. The PO is composed on the client side, not the server side.
>
> This second design seems to be more in the spirit of REST.
>
> Those are the two ways that I see for implementing the purchase parts
> Web service.  Are there other (better) ways?  Any comments?  /Roger
The server can maintain the PO and the client can incrementally update this.
Provide a unique identifier for it & things will be fine (other than more
messages being exchanged & idempotency issues).

Having the client accumulate a single PO with multiple line items probably
makes more sense if you can code the client yourself though. Not all
financial systems make it easy to update POs directly.








-----------------------------------------------------------------------------------
Post ID:1529
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-16 19:39:01
Subject:Re: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

>
> I can't speak for others, but your points accurately reflected my general
> thinking.  I espcially liked the www.my-home.org examples as an
application
> where action verbs are a much more natural way of modeling the system.
For me, those example are not 'natural', they are merely 'procedural'. A
noun/object/resource based approach isn't any more natural either - it is
just a different way to doing things and it has different characteristics.
Let's follow this example through.

1 Verb-oriented URLs
> For example, a program to control devices in my house might look like
this:
>
>    http://www.my-home.org/connect-to-central-computer
>    http://www.my-home.org/air-conditioning/on
>    http://www.my-home.org/air-conditioning/adjust-temp?value=68
>    http://www.my-home.org/stereo/on
>    http://www.my-home.org/stereo/play-cd?cd=Timeless-Serenity

Question: by 'adjust-temp' do you mean 'add 68 degrees' or do you mean 'set
equal to 68 degrees'?
Question: how do you get the current temperature or the current album?

Additional URLs might look like:
   http://www.my-home.org/disconnect-from-the-central-computer
   http://www.my-home.org/stereo/powerDown
   http://www.my-home.org/stereo/play-cd?cd=none
   http://www.my-home.org/air-conditioning/turnOffNow
   http://www.my-home.org/air-conditioning/reportTemp


2 Noun-oriented URLs
> For me it is more program friendly to have something like:
>  home.server = "http://www.my-home.org/";
>  home.put("air-conditioning/power,"on");
>  home.put("air-conditioning/temp","68");
>  home.put("stereo/power","on");
>  home.put("stereo/current-album","Timeless-Serenity");

> If you wanted api based access, it wouldn't be hard to define objects with
> named properties where each property maps to a URI. You could then have
the
> client do something like:
>  home.airConditioner.power = "on";
>  home.airConditioner.temp = "68";
>  home.stereo.power = "on";
>  home.stereo.album = "Timeless-Serenity";








-----------------------------------------------------------------------------------
Post ID:1530
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-16 19:50:18
Subject:Re: [rest-discuss] REST Best Practices
Message:

>
> This is fine for many actions, but for many other actions, this is very
awkward thinking.
Any time you start with 'foo' and convert to 'bar', it's easy to say that
'bar' is awkward from the point of view of 'foo'.
Rather than converting 'action' into 'noun', convert 'action' into
'noun+action'. Then see how many actions you minimally need to get the job
done.

Lets list these many other actions, show the two approaches and see what
everybody thinks.

> Few people really thinking of turning on the air
> conditioning as changing the state of the AC into the "ON" state.
But what about software systems? How are they best described?

> Starting a race is an action that isn't naturally modeled as a "noun".
The state of a race is information that isn't naturally modelled as an
'action'.

>
> I definitely agree that having a record created of an action as a
> consequence is often useful, but doesn't necessarily make that the natural
> mental model for programmers or ultimately, end-users.
True - but REST isn't about procedural programming or end-users mental
models, it is about large scale networked systems.
RDBMS and SQL isn't all that natural for programmers and don't even try to
explain it to end-users, but they still have some value.









-----------------------------------------------------------------------------------
Post ID:1531
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-16 22:51:41
Subject:Re: [rest-discuss] Re: Use verbs in URIs? [was: REST Best Practices]
Message:

bhaugen32 wrote:
> 
>...
> 
> I know.  I'm afraid I expressed my question very badly.  I should
> have written "is there a pattern for how Web sites usually handle the
> sale of downloaded products, including URIs, methods, etc."? 

I think that they vary widely. I think that after you do all of the
negotiation and credit card stuff you should just have a "click here to
download your data" (i.e. a pointer to a GET URI). You might also have a
link to "click here to download your license file." The former URI is
probably shared by all downloaders and the latter is specific to a
particular downloader. i.e.

/downloads/ourproduct.exe
/license/7439239473298749328.lic

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1532
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-06-16 23:00:22
Subject:Re: [rest-discuss] Re: Use verbs in URIs? [was: REST Best Practices]
Message:

On Sun, Jun 16, 2002 at 03:51:41PM -0700, Paul Prescod wrote:

> I think that they vary widely. I think that after you do all of the
> negotiation and credit card stuff you should just have a "click here to
> download your data" (i.e. a pointer to a GET URI). You might also have a
> link to "click here to download your license file." The former URI is
> probably shared by all downloaders

That doesn't seem very smart from a business perspective. You're talking
about an information product being sold for money, right? What's to stop
me from e-mailing that download URI to all my friends?

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:1533
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-17 03:36:02
Subject:REST and state transitions
Message:

Many people think of protocols in terms of state machines and state
transitions. REST doesn't encourage this. I've written an article that
discusses this:

http://www.prescod.net/rest/state_transition.html

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1534
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-17 04:03:41
Subject:Re: [rest-discuss] Re: Use verbs in URIs? [was: REST Best Practices]
Message:

Matt Gushee wrote:
> 
> On Sun, Jun 16, 2002 at 03:51:41PM -0700, Paul Prescod wrote:
> 
> > I think that they vary widely. I think that after you do all of the
> > negotiation and credit card stuff you should just have a "click here to
> > download your data" (i.e. a pointer to a GET URI). You might also have a
> > link to "click here to download your license file." The former URI is
> > probably shared by all downloaders
> 
> That doesn't seem very smart from a business perspective. You're talking
> about an information product being sold for money, right? What's to stop
> me from e-mailing that download URI to all my friends?

What's to stop you from e-mailing the information you downloaded to all
of your friends?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1535
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-06-17 11:05:53
Subject:Re: [rest-discuss] Re: Use verbs in URIs? [was: REST Best Practices]
Message:

On Sun, Jun 16, 2002 at 09:03:41PM -0700, Paul Prescod wrote:

> > > link to "click here to download your license file." The former URI is
> > > probably shared by all downloaders
> > 
> > That doesn't seem very smart from a business perspective. You're talking
> > about an information product being sold for money, right? What's to stop
> > me from e-mailing that download URI to all my friends?
> 
> What's to stop you from e-mailing the information you downloaded to all
> of your friends?

Ah ... you're right. Nonetheless, I see a lot of businesses obfuscating
URIs or creating them for each (business) transaction, presumably so
that people can't easily remember or share them. How much they really
benefit from that practice I can't say, but it seems to be considered a
good idea.

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:1536
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-17 13:19:32
Subject:Where does the Web community want to go? [Was: Changing relationship between SOAP and REST]
Message:

Paul,

You are to be applauded for your tireless efforts to inform and
enlighten the SOAP community, as well as the REST community.  I
certainly appreciate all of the articles that you have written, as well
as the hundreds of email messages on the topic.  Thank you.

It is certainly very good news that SOAP will provide a SOAP HTTP GET,
and will stop funneling all requests through a single endpoint.  These
changes will have a tumultuous impact on the trio of Web service
technologies - SOAP, WSDL, and UDDI.

While things are being shaken up...

I wonder (out loud) about the virtue of SOAP bothering to continue at
all?  

Where do we, the Web community, want to go with regards to the Web?  I
believe that we want to go to a place where Web messages can be
understood without prior coding (i.e., my robot can travel the Web,
interact with services, dynamically understand how to use the services,
and dynamically understand the information that it gets back from the
services).  From what I have read and heard, that's where we say that we
want to go.

Are the current protocols: 

  - standard addressing/naming using URI, 
  - generic application interface using HTTP, 
  - standard MIME Types, 
  - Standard Representations

sufficient to take us there?  I assert that they are.  To get to where
we say that we want to go is not a matter of creating a new protocol to
tunnel within existing protocols.  

I believe that we can get to where we want to go in a two-step process:

1. Create standard XML vocabularies for Communities of Interest (COI).
This is already happening.

2. Create XML vocabularies that facilitate inferencing and discovery. 
RDF and DAML are nicely guiding us to this direction.

Will SOAP, in any of its forms, take us to where we want to go?  I do
not believe so.  SOAP is a detracter.  It is not helping us get to where
we say that we want to go.

I do not see the need for SOAP, in any form. 

We, the Web community, need to refocus.  /Roger

Paul Prescod wrote:
> 
> This is my rambling sense of the state of the debate between SOAP and
> REST.
> 
> To their credit, the SOAP working group has responded to our criticism
> of the SOAP model and I think that there is a 50/50 chance that the most
> severe incompatibility between the two models can be fixed over the next
> while. In particular, I believe that they are coming to agree that the
> "single endpoint" model is architecturally unsound. I have two reasons
> to believe that this is the case. The first is that they have defined a
> "GET" binding for SOAP and agreed that it should be used for any HTTP
> SOAP service that has the semantics of HTTP's GET. The second is that
> I've gotten generally positive agreement that the SOAP primer should
> specifically say that an endpoint-per-resource model makes more . I
> haven't got MUCH feedback but the feedback I've gotten so far has been
> positive:
> 
>  * http://lists.w3.org/Archives/Public/xml-dist-app/2002Jun/0036.html
> 
> Here is the proposed text:
> 
> "One of the principles of Web Architecture is that all important
> resources should be identified by URIs. This implies that many
> well-architected SOAP services will be embodied as large
> numbers or resources, each with its own URI.  Indeed, many
> such resources are likely to be created dynamically during
> operation of the service, as new information becomes available.
> For example, a service offering stock prices might use
> a distinct URI for each stock tracked, and perhaps for
> each date and time for which quotes are provided."
> 
> This is a non-normative change to the specification but it implies
> massive changes to SOAP toolkits and to WSDL. I believe that most
> existing SOAP toolkits do not allow easy implementation of this
> convention. This is especially true for toolkits for statically typed
> languages with "interface generators." But that's okay, because these
> toolkits take their lead from WSDL, and one of the WSDL requirements
> (that I proposed) also addresses this issue:
> 
> "The description language SHOULD allow describing Messages that include
> references (URIs) to strongly-typed referents, both values and
> Services."
> 
> In other words, it should be possible to have a SOAP message or HTTP
> message with a URI in it that points to a SOAP/HTTP endpoint described
> by another WSDL. This will at least make it possible to use WSDL in a
> system where "hypermedia is the engine of application state." We should
> work with the WSDL group to make sure that this happens and that
> HTTP-based services are strongly represented. We should also try and
> work with open source toolkit implementors to make sure that they do the
> right thing as examples for the closed-source vendors.
> 
> My current hope for the future is that a single URI will commonly
> support both HTTP and SOAP methods. For instance, if you avoid the
> various optional SOAP features (SOAP encoding, SOAP headers), the only
> real difference between the new SOAP GET and a plain old HTTP GET is
> that the one returns a SOAP-wrapped body and the other does not.
> Content-negotiation could trigger which happens. (that should perhaps be
> added normatively to the SOAP specification!). In many situations, you
> could just accept that for marketing reasons you must wrap your XML in a
> SOAP:Envelope and SOAP:Body and move on. POST is similar to GET. You can
> probably just build your REST service and ignore the SOAP:Envelope and
> SOAP:Body. SOAP does not define PUT or DELETE, so the "HTTP side" of a
> service can use them without conflict. REST could be viewed as a sort of
> best-practices for SOAP usage -- even if we're not using much of SOAP.
> 
> Hmmmm. There should probably be a TAG ruling on whether it is
> appropriate to use SOAP methods to do something that is logically
> equivalent to an HTTP PUT and DELETE or whether you should just use HTTP
> PUT and DELETE. It seems to me that it kind of follows naturally from
> the GET decision but it might be politically harder because PUT and
> DELETE are not as popular or architecturally important as GET.
> 
> But all of this will only work if the toolkits allow it. If it is
> prohibitively expensive to assign URIs to objects, or to accept *both*
> HTTP and SOAP methods on the same object, we will find ourselves back at
> odds with SOAP again.
> 
> I think that pushback is quite likely because SOAP has many tensions (I
> would go so far as to say contradictions) in its design. It's an RPC
> protocol but not really. It's a synchronous protocol but not really. The
> one that is dangerous to REST: it is a web protocol but it is also
> "transport agnostic". This latter means that it could be tricky to make
> a SOAP API or user interface that allows really good Web-based Web
> Services and then allows you to push a button and get the same features
> on MQSeries or SMTP. REST people could fantasize that this might result
> in the Web model leaking onto other transports but alternately it might
> mean that Web features (like SOAP GET and one-endpoint-per-resource)
> just don't get implemented.
> 
> In addition, there are all of the SOAP add-ons which will come to the
> fore when SOAP is standardized. Someone will have to ensure that
> WS-Security, WS-Routing, transaction standards etc. interact properly
> with HTTP and Web architecture etc. Keeping up with this stuff is a
> full-time job!
> 
> In other words, there is a fight on for the Soul of SOAP -- will it be
> COM for the Internet, or an XML wrapper for the Web, or something else
> entirely?
> 
> And of course there remains the issue of pre-defined methods as in HTTP
> versus invent your own as in the traditional SOAP style.
> 
> Nevertheless, the good news is that it if things go the right way, it
> will be increasingly possible to tell our customers and bosses
> (honestly!) that we are using SOAP and REST. Perhaps if we are vocal
> enough with that message the other standards and implementations will
> fall into place more easily.
> 
>  Paul Prescod
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:1537
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-17 14:50:07
Subject:Re: REST Best Practices
Message:

"S. Mike Dierken" wrote:
> > I definitely agree that having a record created of an action as a
> > consequence is often useful, but doesn't necessarily make that 
the natural
> > mental model for programmers or ultimately, end-users.
> True - but REST isn't about procedural programming or end-users 
mental
> models, it is about large scale networked systems.
> RDBMS and SQL isn't all that natural for programmers and don't even 
try to
> explain it to end-users, but they still have some value.

In addition:  look at all the "actions" that are also modeled as 
documents in every day life:
In business:
* orders
* shipping documents of all kinds - bills of lading, notifications, 
etc.
* receipts
* transactions
* journal entries
* procedures, recipes, formulas, etc.
In the home:
* recipes
* shopping lists
* todo lists
In social relationships:
* invitations
* rsvp's
* love letters

That's just off the top of my head.
Many of these documents arose from situations somewhat like the Web: 
boundary crossings (or the shared domain) between one private domain 
and another.

In other words, I don't think the techniques are all that contrary to 
normal human experience.







-----------------------------------------------------------------------------------
Post ID:1538
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-17 15:56:14
Subject:Re: REST and state transitions
Message:

Paul Prescod wrote:
> Many people think of protocols in terms of state machines and state
> transitions. REST doesn't encourage this. I've written an article 
that
> discusses this:
> 
> http://www.prescod.net/rest/state_transition.html

Paul, it's a wonderful article, but I don't get the message 
that "REST doesn't encourage state machines".  I get the message 
that "REST discourages *implicit* state machines" where states are 
not available as Web resources.  

Then you go on to describe RESTful techniques for implementing state 
machines.

I think for example that business deals are state machines, it's 
inescapable.  Moreover, I think that your techniques can be 
computationally equivalent to state machines hidden behind service 
access points.

Do you think I am missing the point, that you do really mean to 
discourage state-machine-thinking more generally?  If not, it may be 
tactically better to tell people that they can solve their problem 
RESTfully, rather than making statements that suggest they cannot 
solve their problem RESTfully, in which case they will stay with SOAP.

That being said, for business problems, I think it is more accurate 
to model the state machines as states of resources rather than states 
of a conversation or a process anyway.  In other words, I think the 
way you approach it - modeling states in terms of Web resources - is 
better on many dimensions for business problems than the usual "state 
of conversation" model.

For example, a purchase order as a Web resource is a collection of 
business commitments, which themselves can be Web resources.  A PO 
line item is a commitment from one party to deliver some goods or 
services, and from the other party to pay for them.  

The computation of completeness (or any other interesting state) is 
simple via Web resources. When all of the commitments are fulfilled, 
the PO is complete.  Computation of completeness or any other 
interesting state in terms of a "state of conversation" model can be 
very difficult, and it is easy to construct state machines that 
deadlock or never terminate.

In general, I really like the article.  There are some statements 
that I don't understand, though:

"Business rules can be expressed in terms of the state of the 
transaction at a particular moment rather than in terms of the 
current state of the transaction." -- What's the difference?

"Another nice thing is that if it makes sense for the service, the 
client could go back and change its existing answers merely by PUT-
ting to the appropriate URIs. If you change your mind about your 
quest, just go in and change the data! The server is always in 
control of data in its namespace, however, so it could also make that 
URI read-only."  -- I understand what you mean there, unlike the 
previous example. But it drives me nuts if I am reading this article 
as a way to implement state-dependent conversations in a RESTful 
manner.  Changing an answer that has already conditioned further 
state changes could have scarey consequences.  I know, that's what's 
bad about state dependencies in the first place, but I don't know how 
to eliminate them from real problems - only ways to move the 
complexities around so as to be more manageable.  In other words, if 
the article is about avoiding state-dependent behavior, it's a good 
statement.  If the article is about implementing state-dependent 
behavior RESTfully, it boggles my mind.

Question:  Is the Stateless Example similar to, a variation of, or 
the same as continuation passing style?

But to recap, I love the article! Thanks,
Bob Haugen








-----------------------------------------------------------------------------------
Post ID:1539
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-17 16:20:54
Subject:Re: [rest-discuss] Where does the Web community want to go? [Was: Changing relationship between SOAP and REST]
Message:

"Roger L. Costello" wrote:
> 
>...
> 
> I do not see the need for SOAP, in any form.

There is no use telling people to stop working on a technology they've
already invested millions in. The most we can hope for is to ensure it
isn't harmful to our goals. We may also find eventually that some of the
extensions to SOAP are useful: security, routing?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1540
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-17 16:22:13
Subject:Re: [rest-discuss] Re: Use verbs in URIs? [was: REST Best Practices]
Message:

Matt Gushee wrote:
> 
>...
> >
> > What's to stop you from e-mailing the information you downloaded to all
> > of your friends?
> 
> Ah ... you're right. Nonetheless, I see a lot of businesses obfuscating
> URIs or creating them for each (business) transaction, presumably so
> that people can't easily remember or share them. How much they really
> benefit from that practice I can't say, but it seems to be considered a
> good idea.

Well I did say that the download URI and license URI would usually be
separate. By license URI I meant a license key that makes the download
work. That key could be at a URI that only lasts for ten minutes. You
could have a red flag go up if it detects multiple downloads from
different IP addresses. But in the end you can only make it marginally
harder to share the data.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1541
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-17 17:23:11
Subject:RE: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

Paul Prescod wrote:
> Philip Eskelin wrote:
> >
> >...
> >
> > I'm not sure where my version of this verb/URI issue stands, but
> > here is the way I have designed it in my own efforts.  As I mentioned
> > before, I have a pre-developed set of resource types, namely methods,
> > components, topics, queues, etc that are published in a node's
> > hierarchical namespace.
>
> I guess the basic question is whether you *need* method objects. A
> REST-purist view would be that you should use methods as an
> implementation technique to implement a resource view of the world.
> Since I don't know what method objects you have, I can't
> resource-decompose them. But in most cases you will want an action to
> have a side-effect that creates a resource+URI, and you will want the
> newly created resource to be in some container. So you can
> instead use a POST on the container.

My question was "what are you posting to?" and that's where I came up with the
idea of creating method resources, which have URIs (if they are published), can
be invoked via POST, and need to exist in a container.  GETing, PUTing, and
DELETEing methods act on the resource itself.

> >...
> > HTTP PUT - instead of getting a pre-existing resource like the one
> > above, it allows you to effectively copy a resource in its current
> > state to another node. You are effectively publishing it on the
> > destination node.
>
> It's not clear to me how you can copy a method. After all, the real
> method is the programming code behind it. And that code will
> depend on a complex network of other state. So PUT-ting to a method
> resource doesn't make much sense to me.

Sorry about that - I'll clarify.  One thing I forgot to write into my original
method example was a "localHost" property that references the component where
the implementation of the method is hosted.  So if you merely copy the method
resource, it then exists in a new container but references the same
implementation.

So if you wanted to do what you thought I meant in your response, you would also
need to copy the component to a new location, update new method's localHost URI,
and integrate the new component into its environment.  If the destination node
was identical to the source (code doesn't always depend on a complex network of
state), then it might work without modification.

I agree with you, PUTing to a method resource doesn't make sense. Instead, you
would want to PUT the method to a container.  Is that more clear?  Like Roger, I
want to make sure my work reflects resolve on these issues.

-Philip







-----------------------------------------------------------------------------------
Post ID:1542
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-17 17:43:29
Subject:REST APIs
Message:

I'm struggling to catchup with rest-discuss, but found one point I
wanted to respond to, only to lose the message.  Basically, somebody
was looking for an API that fit well with REST interactions.

IMO, container based component based APIs such as Java Beans 1.2 (aka
Glasgow) are a pretty good fit.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1543
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-17 18:44:58
Subject:Re: [rest-discuss] REST Best Practices
Message:

On Thu, Jun 13, 2002 at 11:43:32AM -0700, Joe Hsy wrote:
> > 3. As a corollary to (2) use nouns in the logical URI, not verbs. 
> > Resources are "things" not "actions".
> 
> URIs are like phone numbers - both are universal addressing schemes.  All
> I'm saying is that we shouldn't arbitrarily discourage people from modeling
> "actions" as resources for those applications that makes sense.
> 
> Buying a book is a clearly an action.  You can abstract the URI into a noun
> by calling it a "purchase transaction record", but to the end user pushing
> the "buy" button, it is still an action.

Right, but GET on that URI does not initiate the action as you might
expect if it was really a verb and not a noun.

I really think it just confuses things immensely to try and validate
the reasons for putting a method in a URI.  If it's not used as a
method, then why bother trying?  Perhaps I've just been doing this long
enough that I never need to consider doing so.  Practice makes perfect,
I suppose.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1544
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-17 18:48:16
Subject:Re: [rest-discuss] Re: Use verbs in URIs? [was: REST Best Practices]
Message:

On Sat, Jun 15, 2002 at 12:18:30PM -0400, bhaugen32 wrote:
> Downloading electronic goods is an action.  Is there a common method?

The one I've seen used most often (mostly on contract agreements
before downloading, not purchasing) is when a POST button is selected
to agree, and then the file is returned as an application/octet-stream
so you automatically get the "save to file" prompt.  Obviously no
Content-Location header is returned. 8-)

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1545
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-17 20:24:54
Subject:RE: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

-----Original Message-----
From: S. Mike Dierken [mailto:mdierken@...]

> For me, those example are not 'natural', they are merely 'procedural'. A
> noun/object/resource based approach isn't any more natural either - it is
> just a different way to doing things and it has different characteristics.

I agree that what is "natural" is often a matter of opinion.  And I
certainly don't view these as mutually exclusive.  There is no reason to be
able to see it both ways as human beings do all the time.  We buy our
groceries and we get a receipt of the transaction.  There is not conflict in
that and it is good to see it both ways at the same time.

I do think that in our universe of human understanding, there are certain
concepts that are that more naturally a resource/noun and others that are
more naturally procedural/actions.  There is a reason that we have a lot of
nouns in our vocabulary as well as a lot of verbs. 8-)  But, you are
certainly welcomed to think otherwise.  I just think that REST should allow
both types of thinking and that they can coexist.

You give a fine example of how the home AC can be viewed both ways and that
the procedural URIs are only 
"more natural" to the extent that we the users are thinking procedurally at
remotely setting our AC.  On the other hand, I see no problem that we expose
both the state-oriented URLs and the action-oriented URLs at the same time,
which would support both types of thinking concurrently.

Maybe a better example of a more naturally action-oriented task would be
driving a car.  If I am driving the car, I am certainly more focused on
turning right and turning left and stepping on the gas or stepping on the
break, as opposed to setting the direction of the car to the left or setting
the car into accelerated state or decelerated state.

One could argue that computers programs at its core are more
state-representational, but that doesn't not mean that we as human beings
and programmers need to think that way as well.  The computer can translate
"turn right" into changing the steering wheel setting for us.

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1546
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-17 23:53:31
Subject:RE: [rest-discuss] REST Best Practices
Message:

-----Original Message-----
From: S. Mike Dierken [mailto:mdierken@...]

> >
> > This is fine for many actions, but for many other actions, this is very
> > awkward thinking.
> 
> Any time you start with 'foo' and convert to 'bar', it's easy to say that
> 'bar' is awkward from the point of view of 'foo'.
> Rather than converting 'action' into 'noun', convert 'action' into
> 'noun+action'. Then see how many actions you minimally need to get the job
> done.

Again, I am by no means trying to force people to change their thinking to a
more 
verb-oriented procedural model if they are comfortable with resource and
state model.  I am simply proposing that we don't limit the programmers to
thinking in a noun-centric way if it makes sense to allow verbs to be part
of the picture.

Maybe, we can just change the recommended best practice to say that it is
usually a good practice to expose states and noun resources, even if one is
also exposing verb resources.  Encouraging one does not have to mean
eliminating the other.

> Lets list these many other actions, show the two approaches and see what
> everybody thinks.

A few things that are very procedural would again be driving a car, cooking
a rack of lamb, or flying a kite, etc.

> > Few people really thinking of turning on the air
> > conditioning as changing the state of the AC into the "ON" state.
> But what about software systems? How are they best described?

As I mentioned in the previous email, at the program level, many programs do
reduce to state management problems.  But, it doesn't mean people have to
think that way as well.

>
> > I definitely agree that having a record created of an action as a
> > consequence is often useful, but doesn't necessarily make that the
natural
> > mental model for programmers or ultimately, end-users.
> True - but REST isn't about procedural programming or end-users mental
> models, it is about large scale networked systems.
> RDBMS and SQL isn't all that natural for programmers and don't even try to
> explain it to end-users, but they still have some value.

I never said that resource-modeling isn't valuable - on the contrary.  I'm
only saying that resource modeling isn't the *only* valuable way to do
things.  RDBMS and SQL is certain useful, but so are spreadsheets and web
logs.

If you are saying REST is not meant to support a procedural model, I will
defer that question to the people defined REST and are refining REST.  But
if that is true, we will need an alternative architecture for the web to
support the procedural programming model.

On the other hand, if you are saying that large scale network systems should
not support procedural programming, I have to ask why you think that is the
case?  I for one would still want to be able to program procedurally for
large scale network applications as a complement to the resource model.

//Joe




This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1547
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-06-18 00:07:00
Subject:Re: [rest-discuss] REST APIs
Message:

At 03:43 AM 18/06/2002, Mark Baker wrote:
>I'm struggling to catchup with rest-discuss, but found one point I
>wanted to respond to, only to lose the message.  Basically, somebody
>was looking for an API that fit well with REST interactions.
>
>IMO, container based component based APIs such as Java Beans 1.2 (aka
>Glasgow) are a pretty good fit.

I would love to hear more detail on your experiences using this API wrt REST

I have been keeping tabs on Cocoon (http://xml.apache.org/cocoon/) as a possible framework with which to build my next app. Has anyone any experience with how well Cocoon and REST fit together in real life?

TIA

Robert







-----------------------------------------------------------------------------------
Post ID:1548
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-06-18 00:28:08
Subject:Re: [rest-discuss] REST Best Practices
Message:

On Mon, Jun 17, 2002 at 04:53:31PM -0700, Joe Hsy wrote:

> > Lets list these many other actions, show the two approaches and see what
> > everybody thinks.
> 
> A few things that are very procedural would again be driving a car, cooking
> a rack of lamb, or flying a kite, etc.

Granted. But it is hard to imagine people using the web for any of these
activities, literally. Do you have examples of analogous activities that
would make sense as web applications?

> I never said that resource-modeling isn't valuable - on the contrary.  I'm
> only saying that resource modeling isn't the *only* valuable way to do
> things.  RDBMS and SQL is certain useful, but so are spreadsheets and web
> logs.

I don't see how spreadsheets or weblogs demand a procedural approach.
What's wrong with, e.g., PUTting an entry to

  http://myweblog.net/2002-06-17/mcg12

or GETting the value of

  http://mymoney.com/expense_record/D:22

or, for that matter, PUTting something like

  <add>129.95</add>

to

  http://mymoney.com/expense_record/D:next_row

Or, if being able to PUT to an arbitrary cell in a spreadsheet gives you
the willies, POST to the whole spreadsheet and give the server more
control over exactly where the entry goes.

How would verbs in URIs simplify this?

> If you are saying REST is not meant to support a procedural model, I will
> defer that question to the people defined REST and are refining REST.  But
> if that is true, we will need an alternative architecture for the web to
> support the procedural programming model.
> 
> On the other hand, if you are saying that large scale network systems should
> not support procedural programming, I have to ask why you think that is the
> case?  I for one would still want to be able to program procedurally for
> large scale network applications as a complement to the resource model.

For an authoritative answer, I will also defer to the people who defined
and are refining REST. But my sense is that procedural programs tend to
be fragile in a loosely-coupled distributed environment, which is what
the Web has been and most people expect Web Services to be.

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:1549
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-18 00:56:12
Subject:RE: [rest-discuss] REST Best Practices
Message:

-----Original Message-----
From: Matt Gushee [mailto:mgushee@...]

> > A few things that are very procedural would again be driving a car,
cooking
> > a rack of lamb, or flying a kite, etc.
> 
> Granted. But it is hard to imagine people using the web for any of these
> activities, literally. Do you have examples of analogous activities that
> would make sense as web applications?

By no means am I suggesting that people use the web for driving a car. 8-)
No, I am simply abstracting the argument that conceptually, people think
both in terms of actions and resources, and that certain concepts are better
thought of as actions.

Ok, let me see if I can come up with a example of a distributed application
that is more naturally thought of procedurally.  How about a distributed
fantasy role-playing game?  The players perform actions in a simulated
world.  This world is certainly full of noun resources and there can be URLs
that refers to each player, each castle, each river, etc.

But, I can also see the advantage of exposing verb URLs can be used to
perform actions such as crossing a river, kill an daemon, etc.  Again, I'm
not saying we get rid of noun-URLs, by God we know we need them.  But, let's
allow the programmers to add a few verb URLs in there when it makes sense.

> > I never said that resource-modeling isn't valuable - on the contrary.
I'm
> > only saying that resource modeling isn't the *only* valuable way to do
> > things.  RDBMS and SQL is certain useful, but so are spreadsheets and
web
> > logs.
>
> I don't see how spreadsheets or weblogs demand a procedural approach.

I would be that last person to say that spreadsheets and weblogs represent
procedural approaches. 8-)  If you would reread what I wrote, I am simply
replying to Mike's analogy.  I was saying that that I am not arguing
*against* noun-oriented URLs, but rather that we should not eliminate
verb-oriented URLs.  This is analogous in the same way that I would not
argue against the usefulness of RDBMS, but I still think spreadsheets are
useful.

> For an authoritative answer, I will also defer to the people who defined
> and are refining REST. But my sense is that procedural programs tend to
> be fragile in a loosely-coupled distributed environment, which is what
> the Web has been and most people expect Web Services to be.

Procedural programming *can* be fragile, but I don't think that they
necessarily have to be.  Creating properties and modes that is then set by
the client can also be very fragile.  Fragility has less to do with being
procedural or representational than whether the design is good or whether
the model accurately reflects the nature of the application.

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1550
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-18 01:08:33
Subject:RE: [rest-discuss] REST Best Practices
Message:

-----Original Message-----
From: Mark Baker [mailto:distobj@...]

> Right, but GET on that URI does not initiate the action as you might
> expect if it was really a verb and not a noun.

I agree, and I would suggest that a GET on a verb URI should return a state
as oppose to performing the action.

> I really think it just confuses things immensely to try and validate
> the reasons for putting a method in a URI.  If it's not used as a
> method, then why bother trying?  Perhaps I've just been doing this long
> enough that I never need to consider doing so.  Practice makes perfect,
> I suppose.

With the recent discussion, maybe people are so used to treating URIs as
representing only nouns that it isn't worth generalizing URIs as an
universal addressing scheme for *anything*.  I just feel that we are losing
some potential interesting applications if we make this restriction and not
getting much in return.

Maybe at the root of what I'm trying to get at is that a method should have
a URI.  Why should objects get all the benefits of universal addressability
and not methods?

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1551
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-06-18 01:11:08
Subject:Re: [rest-discuss] REST Best Practices
Message:

Joe Hsy <joe.hsy@...> wrote:

> But, I can also see the advantage of exposing verb URLs can be used to
> perform actions such as crossing a river, kill an daemon, etc.  Again, I'm
> not saying we get rid of noun-URLs, by God we know we need them.  But,
let's
> allow the programmers to add a few verb URLs in there when it makes sense.

Why wouldn't you POST what verb you're performing to the nouns?

POST /daemon HTTP/1.1
Content-Type: application/rpg+xml

<kill using='sword' />

This way new verbs can be created without having to add sub-resources to
every noun on the server that can be affected by those verbs. Or is this too
RPC-ish?

Jason









-----------------------------------------------------------------------------------
Post ID:1552
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-18 08:43:14
Subject:RE: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

-----Original Message-----
From: Philip Eskelin [mailto:philip@...]

> My question was "what are you posting to?" and that's where I came up with
the
> idea of creating method resources, which have URIs (if they are
published), can
> be invoked via POST, and need to exist in a container.  GETing, PUTing,
and
> DELETEing methods act on the resource itself.

This is very cool and is very much what I was getting at.  I can't wait to
see it.

> > It's not clear to me how you can copy a method. After all, the real
> > method is the programming code behind it. And that code will
> > depend on a complex network of other state. So PUT-ting to a method
> > resource doesn't make much sense to me.
> 
> Sorry about that - I'll clarify.  One thing I forgot to write into my
original
> method example was a "localHost" property that references the component
where
> the implementation of the method is hosted.  So if you merely copy the
method
> resource, it then exists in a new container but references the same
> implementation.
> ...
> I agree with you, PUTing to a method resource doesn't make sense. Instead,
you
> would want to PUT the method to a container.  Is that more clear?  Like
Roger, I
> want to make sure my work reflects resolve on these issues.

This is an interesting concept.  And I also agree that if you are trying to
make "copy" the semantics of PUTing to a URI, that URI should represent a
container of object for which the method would act.  However, I think this
creates a conflict with a normal semantics of PUTing to a noun resource.

Not being certain how often one would want to copy method code to another
node in this way, I would say that it might not be worth the trouble to
support this semantic for PUTing to a verb/method URI.  A nice idea, though.


Again, please let us know when you're ready to reveal your toolkit as I am
quite interested in how it works.

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1553
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-06-18 13:52:22
Subject:Re: [rest-discuss] Where does the Web community want to go? [Was: Changing relationship between SOAP and REST]
Message:

>>I do not see the need for SOAP, in any form.
> 
> 
> There is no use telling people to stop working on a technology they've
> already invested millions in. The most we can hope for is to ensure it
> isn't harmful to our goals. We may also find eventually that some of the
> extensions to SOAP are useful: security, routing?

I'd like to add some real world thoughts on this subject.  We are 
developing an asynchronous communication system between a central system 
and many remote devices.  We have to deliver this product in an almost 
unreal timeline.  So we need to use technologies that can help us meet 
our goal quickly.

I have, luckily, convinced everyone that using REST is the way to go. 
We are transporting the state of objects across the network.  You won't 
see a single method call in the communications.  (This has actually been 
a huge blessing, I am a 100% believer in REST for distributed systems now)

Our central system is written in Java, and the remote devices are all 
running a C++ application.  Our problem became, how do we efficiently 
deal with parsing and unparsing these objects for both systems?  In 
Java, there are many XML mapping tools.  In C++, we had a hard time 
finding libraries that would make the job of taking XML and making a C++ 
object out of it.  I guess people just don't build distributed systems 
in C++ anymore. :)

Anyway, I'm getting to my point.  We needed some libraries to do 
automatic marshalling of objects from the XML.  Guess what libraries do 
that?  You got it:  SOAP.  SOAP libraries will take objects in your 
language and serialize to XML, and back again.  And there are SOAP 
libraries for C++ (we are using gSOAP with pretty good results).  We 
have a single method call invoked via SOAP, sync(), that exchanges 
objects wrapped in either a GET, PUT, or DELETE.  We are essentially 
emulating HTTP inside our objects being passed around with SOAP.

So Paul is right here.  Don't go around bashing SOAP because many people 
use it in a IMHO doomed fashion.  SOAP libraries are very useful for 
object marshalling/unmarshalling.  It has helped us connect two very 
different systems, while remaining true to REST ideas.  Until we can 
find a robust XML data binding library for C++ w/ network capabilities, 
we'll stick with using SOAP for that.

I agree with Paul in that our job now is to show people how to use SOAP 
in a RESTful way.  It can be done, as our product has shown how SOAP can 
be very useful and not harmful.

Seth







-----------------------------------------------------------------------------------
Post ID:1554
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-18 15:55:55
Subject:RE: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

Joe Hsy wrote:
> This is an interesting concept.  And I also agree that if you are trying to
> make "copy" the semantics of PUTing to a URI, that URI should represent a
> container of object for which the method would act.  However, I think this
> creates a conflict with a normal semantics of PUTing to a noun resource.

Yes, I agree with you.  This is a concern of mine, and one of the reasons I've
asked the group about their thoughts on it.  What I really wanted to do was
create a way for people to easily invoke behavior on any node accessible to
them.  So here would be some example code on how that is done:

  CMethod order_parts("http://www.parts-depot.com/parts/order");
  CStringTable params;
  params.addItem("partNumber", "01234");
  order_parts.execute(params);

The above URI is clearly *not* a noun resource, unless you see the method as a
noun resource that can be invoked like a verb.  Bit of a stretch.  In general,
my aim is to make it easy as possible for programmers to invoke behavior in
their distributed while being as RESTful as possible.  I guess what people are
advocating is something more like this:

  CMethod order_parts("http://www.parts-depot.com/parts/01234");
  CStringTable params;
  params.addItem("action", "order")
  order_parts.doPost(params);

If this is more RESTful, then it would be easy to refactor my method concept to
work this way.  Is there a more RESTful way to approach this example?

> Not being certain how often one would want to copy method code to another
> node in this way, I would say that it might not be worth the trouble to
> support this semantic for PUTing to a verb/method URI.  A nice idea, though.

True.  It seems that the concept is more relevant to resources (nouns).

> Again, please let us know when you're ready to reveal your toolkit as I am
> quite interested in how it works.

The only thing holding me back is making sure it's coherent enough for us to
work with.  Then I hope we can really sit down and hash through these concepts.

-Philip







-----------------------------------------------------------------------------------
Post ID:1555
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-06-18 16:58:52
Subject:Re: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

For this example, and to make it more RESTful, I would change it to this...

OLD:
>   CMethod order_parts("http://www.parts-depot.com/parts/order");
>   CStringTable params;
>   params.addItem("partNumber", "01234");
>   order_parts.execute(params);

NEW:
Order order = new Order("http://www.parts-depot.com/orders/32432");
order.addPart( new PartNumber(01234));

// RESTful magic setting state, /NOT/ calling method
order.complete();

// The Transfer part of Representational State Transfer
transfer(order.toXML());

Notice how we just manipulate the state of the object.  We do it twice, 
once when we add Parts and once when we declare this order as complete. 
  The server does not get the new state of the order until we transfer 
it (by PUTing the order on top of the old one, using the same URI).

How does the server know when to process orders?  By checking the state 
of the objects PUT to the server.  The server has a state machine 
looking for particular states of objects.

Remember, in REST you are not calling methods.  You are merely 
transfering the state of objects.  Leave it up to the handler of the 
resource to do something smart with it.  It's only the client's job to 
manipulate that object's state and PUT it back.

> The above URI is clearly *not* a noun resource, unless you see the method as a
> noun resource that can be invoked like a verb.  Bit of a stretch.  In general,
> my aim is to make it easy as possible for programmers to invoke behavior in
> their distributed while being as RESTful as possible.  I guess what people are
> advocating is something more like this:

Actually, I would argue that the above URI 
("http://www.parts-depot.com/parts/order/34254") *is* a noun, it's 
identifying a particular order.  If your aim is to make it easy for 
programmers, take away method calls and actions all together.  That way, 
there is no API to show them or have them mess up.  All they have to do 
is unstand the object hierarchy of your business domain.

>   CMethod order_parts("http://www.parts-depot.com/parts/01234");
>   CStringTable params;
>   params.addItem("action", "order")
>   order_parts.doPost(params);
> 
> If this is more RESTful, then it would be easy to refactor my method concept to
> work this way.  Is there a more RESTful way to approach this example?

I believe my example above is more RESTful.  Here you are declaring an 
action to be performed on that order object.  All you really want to do 
is set the state of the object order to something that means "Done". 
Then let the server do to it whatever it wants to.


> The only thing holding me back is making sure it's coherent enough for us to
> work with.  Then I hope we can really sit down and hash through these concepts.

I think one of the key things to remember here is that you are just 
transfering objects around the network.  Don't try to send programatic 
instructions along with the object.  Let the server's state machine 
handle what to do.  Let your programmers just manipulate objects and 
transfer them around.  It greatly simplifies your API to nothing but the 
object tree.

Please let me know if that makes sense, or helps you out.  I believe the 
only verbs you want are PUT, DELETE, and GET.

Seth







-----------------------------------------------------------------------------------
Post ID:1556
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-18 17:09:43
Subject:Re: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

On Tue, Jun 18, 2002 at 11:55:55AM -0400, Philip Eskelin wrote:
>   CMethod order_parts("http://www.parts-depot.com/parts/01234");
>   CStringTable params;
>   params.addItem("action", "order")
>   order_parts.doPost(params);
> 
> If this is more RESTful, then it would be easy to refactor my method
> concept to
> work this way.  Is there a more RESTful way to approach this example?

Yes.  What you and Joe have been discussing is not REST, it's RPC
with the method in the URI rather than in the body.

With REST, a common way of ordering a part would be by POSTing a
representation of that part to an order-taking container resource
that has previously advertised its role as an order-taker.  Your
approach misses some critically important steps, such as the
aforementioned advertising of roles (the "offer" in "offer-
acceptance").

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1557
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-18 17:32:27
Subject:Re: [rest-discuss] Re: Use verbs in URIs? [was: REST Best Practices]
Message:

As a side note, in HTTP you can provide a header like :
 content-disposition: attachment; filename=suggested_name.ext

for content-types other than octet-stream - this way you can indicate that
the response entity body should be saved rather than rendered if it is a
known content-type.

----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "bhaugen32" <bhaugen32@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Monday, June 17, 2002 11:48 AM
Subject: Re: [rest-discuss] Re: Use verbs in URIs? [was: REST Best
Practices]


> On Sat, Jun 15, 2002 at 12:18:30PM -0400, bhaugen32 wrote:
> > Downloading electronic goods is an action.  Is there a common method?
>
> The one I've seen used most often (mostly on contract agreements
> before downloading, not purchasing) is when a POST button is selected
> to agree, and then the file is returned as an application/octet-stream
> so you automatically get the "save to file" prompt.  Obviously no
> Content-Location header is returned. 8-)
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>






-----------------------------------------------------------------------------------
Post ID:1558
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-18 17:46:45
Subject:Re: [rest-discuss] REST Best Practices
Message:

----- Original Message -----
From: "Jason Diamond" <jason@...>

>
> POST /daemon HTTP/1.1
> Content-Type: application/rpg+xml
>
> <kill using='sword' />
>
> This way new verbs can be created without having to add sub-resources to
> every noun on the server that can be affected by those verbs. Or is this
too
> RPC-ish?

This isn't RPC-ish at the 'network application' level - you are following
the meaning of HTTP POST.
The resource '/daemon' can represent a message queue and you are adding a
message to it.
This works fine, but it'll probably end up hiding some interesting things
that might deserve to have URIs themselves.
For example you could alternatively have:

POST /world-o-hacks/region27/combatant99/ HTTP/1.1
Content-Type: application/rpg+xml

<strike using='sword' />








-----------------------------------------------------------------------------------
Post ID:1559
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-18 17:47:51
Subject:RE: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

Seth Ladd wrote:
> Order order = new Order("http://www.parts-depot.com/orders/32432");
> order.addPart( new PartNumber(01234));
>
> // RESTful magic setting state, /NOT/ calling method
> order.complete();
>
> // The Transfer part of Representational State Transfer
> transfer(order.toXML());
>
> Notice how we just manipulate the state of the object.  We do it twice,
> once when we add Parts and once when we declare this order as complete.
> The server does not get the new state of the order until we transfer
> it (by PUTing the order on top of the old one, using the same URI).

Got it.  I see the difference.

> How does the server know when to process orders?  By checking the state
> of the objects PUT to the server.  The server has a state machine
> looking for particular states of objects.

This is something that will also apply to my topic and queue abstractions.  For
example, when you publish to a topic, rather than calling a "publish" method
(which was my original approach) you either PUT a representation if it's the
entire resource, or POST if the event only includes a delta of change in the
resource.  GET would allow a subscriber to get a snapshot of the topic's state
upon initialization.

> The above URI is clearly *not* a noun resource, unless you see the method as a
> noun resource that can be invoked like a verb.  Bit of a stretch.  In general,
> my aim is to make it easy as possible for programmers to invoke behavior in
> their distributed while being as RESTful as possible.  I guess what people are
> advocating is something more like this:
>
> Actually, I would argue that the above URI
> ("http://www.parts-depot.com/parts/order/34254") *is* a noun, it's
> identifying a particular order.  If your aim is to make it easy for
> programmers, take away method calls and actions all together.  That way,
> there is no API to show them or have them mess up.  All they have to do
> is unstand the object hierarchy of your business domain.

Well, both of us are right.  The original URI I specified as being a verb was
http://www.parts-depot.com/parts/order.  In actuality, whether it is a noun or
verb is ambiguous.  I read it as a verb, you read it as a noun.  What REST does
by enforcing that you only do state transfer of noun-based objects is remove
that ambiguity.  I like that - it's simpler, which is why we are here.

> >   CMethod order_parts("http://www.parts-depot.com/parts/01234");
> >   CStringTable params;
> >   params.addItem("action", "order")
> >   order_parts.doPost(params);
> >
> > If this is more RESTful, then it would be easy to refactor my method concept
to
> > work this way.  Is there a more RESTful way to approach this example?
>
> I believe my example above is more RESTful.  Here you are declaring an
> action to be performed on that order object.  All you really want to do
> is set the state of the object order to something that means "Done".
> Then let the server do to it whatever it wants to.

Now that we've got a concrete example, I see what you mean and see what I need
to change in terms of my own thinking and how it is realized in my framework.
Wouldn't it be a tragedy if some toolkits finally emerged, only to suffer from
the *same* problems that RPC-related initiatives have.

> > The only thing holding me back is making sure it's coherent enough for us to
> > work with.  Then I hope we can really sit down and hash through these
concepts.
>
> I think one of the key things to remember here is that you are just
> transfering objects around the network.  Don't try to send programatic
> instructions along with the object.  Let the server's state machine
> handle what to do.  Let your programmers just manipulate objects and
> transfer them around.  It greatly simplifies your API to nothing but the
> object tree.
>
> Please let me know if that makes sense, or helps you out.  I believe the
> only verbs you want are PUT, DELETE, and GET.

Yes, it makes sense.  Believe it or not, state transfer of objects around the
network is something I remember, because it was a core theme when I began
building this toolkit a few years ago.  What happened to me - and I'm sure this
will be a recurring issue as REST takes hold - is that even when you have the
intention of going REST, there is a tendency to get sucked back into thinking
procedurally.

Thanks,
Philip







-----------------------------------------------------------------------------------
Post ID:1560
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-18 18:00:20
Subject:Re: [rest-discuss] REST Best Practices
Message:

----- Original Message -----
From: "Joe Hsy" <joe.hsy@...>

>
> If you are saying REST is not meant to support a procedural model, I will
> defer that question to the people defined REST and are refining REST.  But
> if that is true, we will need an alternative architecture for the web to
> support the procedural programming model.

This might be a circular argument, but the Web uses/should-use/is-defined-by
REST principles.
The term 'REST' explicitly means 'transfer state' - and if you use an
approach to invoke
arbitrary functions then it is not a 'transfer state' approach - it isn't
REST. (of course, this is only my opinion).

There can be value in invoking functions over a network, and there are a lot
of technologies to do it (rpc, corba, dcom, xml-rpc, soap-rpc, etc.), and
many make it easy to use in many languages. However, the whole REST position
is that transfering state via a small number of functions is a different but
fully functional approach and many believe it is better at large scales.

Building more/better toolkits for invoking functions over a network is fine
and there are interesting things that can be done, but that approach is
fundamentally different than one where your primary goals are to transfer
state and identify resources. It may be that there are some problems that
are hard to cast into a resource-modelling/state-transfer approach, and I've
got no problem shifting to an 'invoke function' approach for those problems,
but I do have a problem with calling that approach 'web compatible' or 'part
of REST' or whatever. There's nothing wrong with having networked
applications 'outside the Web' or not using REST when its too hard to make a
particular problem fit into the Web architecture.








-----------------------------------------------------------------------------------
Post ID:1561
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-18 18:18:11
Subject:Re: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

----- Original Message -----
From: "Philip Eskelin" <philip@...>
>

> This is something that will also apply to my topic and queue abstractions.
For
> example, when you publish to a topic, rather than calling a "publish"
method
> (which was my original approach) you either PUT a representation if it's
the
> entire resource, or POST if the event only includes a delta of change in
the
> resource.  GET would allow a subscriber to get a snapshot of the topic's
state
> upon initialization.
If you are modelling messaging with resources, and the URI identifies the
topic or queue, I'd use POST to 'add' a message.
Doing a PUT  on the topic itself would specify the complete state of the
topic.
If you have the URI of an individual message, then you could PUT the content
of the message directly.
You may want to take a look at
http://www.sourceforge.net/projects/destiny/ - it was an early experiment to
expose JMS via HTTP resources.

An interesting issue I have with modelling queues/topics is whether you
actually /can/ model a 'Queue' with HTTP.
If a Queue implies only one consumer of the message at the head of the
queue, how do you ensure one and only one consumer?
If you made the Queue a collection, and let every consumer get a list of
pending messages (a queue browser) then each consumer can directly access
individual messages and perhaps use some features of HTTP to sort of lock
the message. Perhaps a 'PUT' to a "message-id/lock" sub-resource, or perhaps
a GET with an "if-none-match" header and using etags. I haven't had the
spare time to chase this one down.








-----------------------------------------------------------------------------------
Post ID:1562
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-06-18 19:10:31
Subject:Re: [rest-discuss] REST Best Practices
Message:

> This works fine, but it'll probably end up hiding some interesting things
> that might deserve to have URIs themselves.
> For example you could alternatively have:
>
> POST /world-o-hacks/region27/combatant99/ HTTP/1.1
> Content-Type: application/rpg+xml
>
> <strike using='sword' />

How is this different? You're just posting a different verb to a different
noun. If you wanted to give the verbs URIs (is that what you referring to?)
could you do something like this:

POST /world-o-hacks/region27/combatant99/ HTTP/1.1
Content-Type: application/rpg+xml

<action href='http://word-o-hacks/actions/strike'>
    <param name='weapon' value='sword' />
</action>

That gives URIs to verbs though they don't seem all that verb-y anymore.

Jason








-----------------------------------------------------------------------------------
Post ID:1563
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-18 19:28:45
Subject:Re: [rest-discuss] REST Best Practices
Message:

----- Original Message -----
> > This works fine, but it'll probably end up hiding some interesting
things
> > that might deserve to have URIs themselves.
> > For example you could alternatively have:
> >
> > POST /world-o-hacks/region27/combatant99/ HTTP/1.1
> > Content-Type: application/rpg+xml
> >
> > <strike using='sword' />
>
> How is this different? You're just posting a different verb to a different
> noun. If you wanted to give the verbs URIs (is that what you referring
to?)
> could you do something like this:

I was just contrasting the modeling the resources as a single URI that is a
Queue which accepts 'command' documents, against a resource model with more
fine grained resources - like individual participants.
It was meant to highlight what happens when you model a system as a single
queue - potentially interesting things are not accessed directly via their
own URI.
Not a big deal.








-----------------------------------------------------------------------------------
Post ID:1564
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-18 19:30:05
Subject:verb URIs and RPC [was: Use verbs in URIs?]
Message:

I would have to agree that an application to support parts inventory should
implement a whole set of noun-type resources including parts, orders,
order-takers.

I guess my question is whether we are in fact violating REST if we also
complement these resources with certain verb-resources that are in effect
"short-cuts".  For example, instead of having the client create an order and
POSTing it to the order container, the URI represents a resource that in
fact creates the order and automatically sends it to the order-taker.

I am starting to realize that this may be too much of a conceptual shift to
keep clean because people automatically think RPC when it comes to verbs.
There is a subtle but fine distinction between giving "verbs" URIs and doing
RPC.  RPC requires a explicit binding process to work requiring that the
parties agree on the parameters and procedure call.  Verb URIs do not
require this type of tight coupling.

Giving verbs URIs is still loose coupling.  It is as loose in coupling as
creating properties which has a set of acceptable values that you must set.
Ultimately, the two parties will still need to "understand" each other for
this to work, but this need for understanding is pushed out from the
protocol.  And it allows certain other types of application to manipulate
these URIs without that understanding (which RPC does not support).  This
loose coupling will allow verb URIs to scale in ways that RPC can not.

//Joe

-----Original Message-----
From: Mark Baker [mailto:distobj@...]
Sent: Tuesday, June 18, 2002 10:10 AM
To: Philip Eskelin
Cc: Roger L. Costello; Joe Hsy; Paul Prescod;
rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] Use verbs in URIs? [was: REST Best
Practices]


On Tue, Jun 18, 2002 at 11:55:55AM -0400, Philip Eskelin wrote:
>   CMethod order_parts("http://www.parts-depot.com/parts/01234");
>   CStringTable params;
>   params.addItem("action", "order")
>   order_parts.doPost(params);
> 
> If this is more RESTful, then it would be easy to refactor my method
> concept to
> work this way.  Is there a more RESTful way to approach this example?

Yes.  What you and Joe have been discussing is not REST, it's RPC
with the method in the URI rather than in the body.

With REST, a common way of ordering a part would be by POSTing a
representation of that part to an order-taking container resource
that has previously advertised its role as an order-taker.  Your
approach misses some critically important steps, such as the
aforementioned advertising of roles (the "offer" in "offer-
acceptance").

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1565
Sender:"Jason Diamond" <jason@...>
Post Date/Time:2002-06-18 19:36:31
Subject:Re: [rest-discuss] REST Best Practices
Message:

> I was just contrasting the modeling the resources as a single URI that is
a
> Queue which accepts 'command' documents, against a resource model with
more
> fine grained resources - like individual participants.
> It was meant to highlight what happens when you model a system as a single
> queue - potentially interesting things are not accessed directly via their
> own URI.

Oh. When I typed in /daemon in my previous example I was referring to Joe's
example of "killing a daemon" which I took to mean some sort of malevolent
creature. I see now that it could also be interpreted as some sort of server
process or queue. Your example using combatant99 was much clearer in getting
across what I was trying to.

> Not a big deal.

:-)

Jason








-----------------------------------------------------------------------------------
Post ID:1566
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-06-18 19:45:21
Subject:Re: [rest-discuss] REST Best Practices
Message:

Jason Diamond wrote:
>>This works fine, but it'll probably end up hiding some interesting things
>>that might deserve to have URIs themselves.
>>For example you could alternatively have:
>>
>>POST /world-o-hacks/region27/combatant99/ HTTP/1.1
>>Content-Type: application/rpg+xml
>>
>><strike using='sword' />

Just for the sake of illustration, here are my thoughts:

The statement we want to convey is "Seth is attacking an ogre".  I can't 
say "Seth is striking an ogre" because that is up to the DM (or, the 
server's logic) to determine the outcome of "Seth is attacking an ogre". 
  In fact, in rollplaying, this is pretty much what would happen.

Anyway, the state I am in is Attacking.  If the URI 
http://example.org/world-o-hacks/region27/combatant99 points to Seth 
(The Mighty), then I might PUT myself there, therefor updating my state:

PUT /world-o-hacks/region27/combatant99 HTTP/1.0
Content-Type: application/rpg-character+xml

<character>
    <!-- what is Seth doing now?  could be walking, talking, etc -->
    <performing>
       <attack using="sword">
          <against xlink:href="http://world-o-hacks/region27/ogre/33553"
                   xmlns:xlink="whatever-it-is" />
       </attack>
    </performing>
</character

What's nice about that is the server can send back a representation of 
both my character AND the ogre.  I would look into the representation of 
the ogre to see if damage had been done, if it is fleeing, etc.

It's all about state transfer.  Kinda cool.

Seth







-----------------------------------------------------------------------------------
Post ID:1567
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-18 20:08:36
Subject:RE: [rest-discuss] Use verbs in URIs? [was: REST Best Practices]
Message:

-----Original Message-----
From: Seth Ladd [mailto:seth@...]

> Remember, in REST you are not calling methods.  You are merely 
> transferring the state of objects.  Leave it up to the handler of the 
> resource to do something smart with it.  It's only the client's job to 
> manipulate that object's state and PUT it back.

I don't think calling methods and transferring state are necessarily
mutually exclusive.  Calling a method is a perfectly fine way to transfer
state.  If we define a URI for turning the lamp on, the "on" method
transfers to the client the state of success-on or failure-off.  It is
really no different than POSTing "on" to the lamp's "on-or-off" property.

I certainly agree that transferring state is a must for REST and have URIs
for all important noun resources is a very good thing.  However, to the
extent that loose coupling is respected, having verb URIs (*not* RPC) to
represent important actions that are stable and meaningful can also be
useful as long as the state modeling and transfer is maintained.

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1568
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-18 20:36:57
Subject:RE: [rest-discuss] REST Best Practices
Message:

-----Original Message-----
From: Seth Ladd [mailto:seth@...]

> Anyway, the state I am in is Attacking.  If the URI 
> http://example.org/world-o-hacks/region27/combatant99 points to Seth 
> (The Mighty), then I might PUT myself there, therefor updating my state:
> 
> PUT /world-o-hacks/region27/combatant99 HTTP/1.0
> Content-Type: application/rpg-character+xml
> 
> <character>
>     <!-- what is Seth doing now?  could be walking, talking, etc -->
>     <performing>
>        <attack using="sword">
>           <against xlink:href="http://world-o-hacks/region27/ogre/33553"
>                    xmlns:xlink="whatever-it-is" />
>        </attack>
>     </performing>
> /character
> 
> What's nice about that is the server can send back a representation of 
> both my character AND the ogre.  I would look into the representation of 
> the ogre to see if damage had been done, if it is fleeing, etc.
> 
> It's all about state transfer.  Kinda cool.

Excellent example!  This is certainly a good way to write a RPG application
in REST.  However, I think we can enhance this system by judiciously adding
action oriented verb URIs.

Let say Seth the Mighty wants to "mental blast" all ogres within 1/2 mile.
We can create an order for each ogre in the 1/2 mile radius, or we can
create a temporary Ogre container that represents all ogres in 1/2 mile and
send the order to that container.  Both seems like a bit of work.

But, if the game hoster provided a URI for Seth the Mighty that allows:

 
http://example.org/world-o-hacks/region27/combatant99/mental-blast?radius=.5

This would be pretty convenient.  The returned results could still be
individual states of all the ogres in the 1/2 mile radius (as well as the
current state of Seth).  Of course, you can also create a "noun" URI for
Seth's mental blast capability:

 
http://example.org/world-o-hacks/region27/combatant99/mental-blast-capabilit
y

And then create an order with the radius property set to .5 miles and POST
that order to the mental-blast-capability.  But, why bother defining a
mental blast order format?  Not much value there.  And if
mental-blast-capability has state (e.g. power-level), then having a URI that
point to it would make sense, otherwise we may not need that URI at all.

Ultimately, for concepts for which the act is the most important (as opposed
to the actor or the actee), a verb resource may be more convenient.  Again
it is a matter of convenience and readability -  ultimately, they do still
result in state changes and transfers.  A few other examples may be
"meditate" which could increase strength or "bathe" to increase cleanliness.
8-)

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1569
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-18 21:17:02
Subject:RE: [rest-discuss] REST Best Practices
Message:

-----Original Message-----
From: S. Mike Dierken [mailto:mdierken@...]

> This might be a circular argument, but the Web
uses/should-use/is-defined-by
> REST principles.
> The term 'REST' explicitly means 'transfer state' - and if you use an
> approach to invoke
> arbitrary functions then it is not a 'transfer state' approach - it isn't
> REST. (of course, this is only my opinion).

Whether web and REST is synonymous is a difficult question.  Even Roy admits
that there are many websites that use URIs and implementations that are not
RESTful.  We can encourage REST, but the web is what it is warts and all.

And as I replied to Seth, I don't think invoking a function or method is not
mutually exclusive with transfer of state.

> There can be value in invoking functions over a network, and there are a
lot
> of technologies to do it (rpc, corba, dcom, xml-rpc, soap-rpc, etc.), and
> many make it easy to use in many languages. However, the whole REST
position
> is that transfering state via a small number of functions is a different
but
> fully functional approach and many believe it is better at large scales.

I don't know if it is "fully functional" if it precludes the creation of
procedural applications.  And as for whether procedural applications can
work at the large scale, I think that has more to do with loose coupling vs.
tight coupling as opposed to procedural vs. representational.

> Building more/better toolkits for invoking functions over a network is
fine
> and there are interesting things that can be done, but that approach is
> fundamentally different than one where your primary goals are to transfer
> state and identify resources. It may be that there are some problems that
> are hard to cast into a resource-modeling/state-transfer approach, and
I've
> got no problem shifting to an 'invoke function' approach for those
problems,
> but I do have a problem with calling that approach 'web compatible' or
'part
> of REST' or whatever. There's nothing wrong with having networked
> applications 'outside the Web' or not using REST when its too hard to make
a
> particular problem fit into the Web architecture.

This is fair enough.  But where we run into problems is if want to promote
REST as a better way to do web services, but then we tell people that they
can't write procedural web services in REST and they must go else where if
they want to write procedural web services.

//Joe


This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1570
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-18 21:56:15
Subject:sending orders to order-takers
Message:

Let me try reframe this discussion differently to see if we can shed a
little more light on it.

Many examples of RESTful application use the concept of an "order" which is
posted to an "order-taker".  The parts-depot accepts parts orders.  The RPG
game server accepts "action" orders.

I submit that this is not much different than invoking a method of an
object.  The method is encapsulated in the XML order document which requires
that the order taker understand what the methods mean for this to work.

The reason this is better than RPC is that this mechanism is loosely coupled
at the protocol layer, whereas RPC requires explicit bindings at the
protocol layer.

But, let's not deceive ourselves about the extent of the loose-coupling.  It
is only loosely coupled as far as generic URI manipulation is concerned
(passing a link, sorting links, ranking, etc).  If the RPG server stops
understanding the action "attack", the clients still break.

We simply moved the brittleness or fragility up to the application level
where it belongs.  Certain applications will remain brittle whether it is
RESTful at the protocol level or not - only good design will ameliorate
brittleness.

REST works wonderfully in a document/data retrieval and hyperlinking
application because the methods for documents and data are essentially GET,
PUT, POST, and DELETE.  For this specific application, those are the most
important verbs.

Unfortunately, this is not true for action-oriented services.  Encapsulating
what we want the server to *do* into an order is again simply pushing the
difficulties of application-specific verbs into the application level (where
I agree it belongs).  However, we won't get same complete benefit that the
document/data web enjoys with having the real semantics of GET, PUT, POST,
DELETE be totally applicable and sufficient for that application.

Let's get back to verb URIs.  I think the insistence on not having verbs in
URIs makes total sense for a document/data web.  It doesn't make as much
sense for a services-oriented web.  We are already creating fragility by
using verbs in the orders but we are not getting the benefit of having the
verbs be addressable directly.

Ultimately, if we want to push REST as a way to implement action-oriented
web services, we need to extend REST to support method invocation in a
consistent and convenient way.  If not, we will need to have some other
defining architecture which leverages URIs and loose-coupling as an
alternative to RPC.

//Joe


This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1571
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-18 22:07:17
Subject:Re: [PMX:#] Re: [rest-discuss] Where does the Web community want to go? [Was:Changing relationship between SOAP and REST]
Message:

Seth Ladd wrote:
> 
>...
> 
> I have, luckily, convinced everyone that using REST is the way to go.

Great! Keep us informed about progress and remember to use us as a
resource if you need ideas.

>...
> Anyway, I'm getting to my point.  We needed some libraries to do
> automatic marshalling of objects from the XML.  Guess what libraries do
> that?  You got it:  SOAP.  SOAP libraries will take objects in your
> language and serialize to XML, and back again.  And there are SOAP
> libraries for C++ (we are using gSOAP with pretty good results).

The ironic thing is that the SOAP world is moving away from the SOAP
serialization and moving to XML Schema-based mappings. But you are right
to use what works today and SOAP serialization works in many languages
today.

> ...  We
> have a single method call invoked via SOAP, sync(), that exchanges
> objects wrapped in either a GET, PUT, or DELETE.  We are essentially
> emulating HTTP inside our objects being passed around with SOAP.

Interesting. It's too bad you have to emulate HTTP though. One of the
things we have to push SOAP, WSDL and XML Schema implementors on is
modularity of implementations. You should be able to send the data over
HTTP and then just hand the string to an object that deserializes it.
The SOAP serialization should never have been bound (either in the
specifications nor in the implementation) to the SOAP *protocol*.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1572
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-18 22:18:25
Subject:Re: sending orders to order-takers
Message:

Joe Hsy wrote:
> Many examples of RESTful application use the concept of an "order" 
which is
> posted to an "order-taker".  The parts-depot accepts parts orders.  
The RPG
> game server accepts "action" orders.
> 
> I submit that this is not much different than invoking a method of 
an
> object.  

I'll only speak to the parts-order example.  I really have no 
absolute objection to verbs in URIs, but an order is not the same as 
invoking a method on an object.

There is a reason that purchase orders are documents and not remote 
procedure calls, and that the business protocol is called "offer-
acceptance" and not "download the goods".

The purchase order is an offer to buy.  The seller is not required to 
accept it. Your credit might be bad, the seller might not have enough 
goods, you may want it faster than the seller can deliver, or 
whatever.

You do not have any control over the seller.  All you can do is 
transfer the state of your offer.

I suspect this is similar to some of the other instances of verbs in 
URIs.  A verb is not really the most accurate way to describe the 
situation.

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:1573
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-18 22:41:15
Subject:RE: [rest-discuss] Re: sending orders to order-takers
Message:

-----Original Message-----
From: bhaugen32 [mailto:bhaugen32@...]

> The purchase order is an offer to buy.  The seller is not required to 
> accept it. Your credit might be bad, the seller might not have enough 
> goods, you may want it faster than the seller can deliver, or 
> whatever.
> 
> You do not have any control over the seller.  All you can do is 
> transfer the state of your offer.
> 
> I suspect this is similar to some of the other instances of verbs in 
> URIs.  A verb is not really the most accurate way to describe the 
> situation.

A good point.  In this case the "verb" of this application is "offer".  You
are essentially invoking the "make offer" method for the offer taker.  The
order document is certainly essential, but it is part of the transaction.

Again, I am suggesting that documents/data are important in services, but so
are verbs/actions.

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1574
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-18 23:01:29
Subject:Re: [rest-discuss] sending orders to order-takers
Message:

Joe Hsy wrote:
> 
>...
> 
> Many examples of RESTful application use the concept of an "order" which is
> posted to an "order-taker".  The parts-depot accepts parts orders.  The RPG
> game server accepts "action" orders.
> 
> I submit that this is not much different than invoking a method of an
> object.  The method is encapsulated in the XML order document which requires
> that the order taker understand what the methods mean for this to work.

There are reasons that I feel that posting an proprietaryNamespace:Order
this is different than calling a proprietyNamespace:method. It is
because these differences are subtle that REST is NOT a no-brainer.
There are kind of two phases of REST enlightenment. First you say: "we
all use the same the methods so everything will just work with
everything." Then you say: "No, that won't really work because some
kinds of resources and representations will only work with particular
other kinds of resources and representations." Then you are ready for
the second phase.

In the second phase we acknowledge that the world is a complicated place
and total interoperability will never come for free. REST isn't going to
repeal the laws of the universe and physics. We are shifting
interoperability hassles from the protocol down into the representation.

But this is MUCH BETTER because the representation is *already*
necessarily an interoperability headache. People will quote prices in
Yen, Dollars, Euros. They will use different date formats. They will use
different element type names for the same thing. Adding the
"operational" interoperability issues to all of these "representational"
interoperability issues is a small change. Once we push all of the
interoperability down into one layer (you call it the application layer
but I call it the representation layer) we can use one set of tools. And
the tools we have available are MUCH BETTER than the tools we have
available for mapping between protocols. There is no XSLT for mapping
HTTP to SMTP or vice versa. There is no RDF or DAML for protocols. 

The other reason it is much better to move interoperability into the
representation is because it enables a wide variety of tools that don't
care about the representation. URI-Browsers, caching proxies, encrypting
proxies, method-triggered filters, mirroring tools, etc. You can just
point these things at a set of URIs and they can do something useful
without knowing anything about the XML vocabulary used.

> The reason this is better than RPC is that this mechanism is loosely coupled
> at the protocol layer, whereas RPC requires explicit bindings at the
> protocol layer.

Different people use different definitions of RPC. I think that Mark's
definition is that a protocol is an RPC protocol if the definition of
new methods is something routinely done by the application, rather than
in a networking-specific layer.

> But, let's not deceive ourselves about the extent of the loose-coupling.  It
> is only loosely coupled as far as generic URI manipulation is concerned
> (passing a link, sorting links, ranking, etc).  If the RPG server stops
> understanding the action "attack", the clients still break.

Okay, but in REST, the action will almost always result in a new
resource that can be referenced and discussed. So you might as well call
it the "submit attack request" action. i.e. POST

> We simply moved the brittleness or fragility up to the application level
> where it belongs.  Certain applications will remain brittle whether it is
> RESTful at the protocol level or not - only good design will ameliorate
> brittleness.

Agreed, but we have much better tools for working with brittleness in
the representation layer than we do at the protocol layer. 

> REST works wonderfully in a document/data retrieval and hyperlinking
> application because the methods for documents and data are essentially GET,
> PUT, POST, and DELETE.  For this specific application, those are the most
> important verbs.

REST is about recasting applications *into* document/data retrieval and
hyperlinking applications!

> Unfortunately, this is not true for action-oriented services.  Encapsulating
> what we want the server to *do* into an order is again simply pushing the
> difficulties of application-specific verbs into the application level (where
> I agree it belongs).  However, we won't get same complete benefit that the
> document/data web enjoys with having the real semantics of GET, PUT, POST,
> DELETE be totally applicable and sufficient for that application.

*Except* for performance requirements, I think you'll have a hard time
demonstrating that GET/PUT/POST/DELETE are insufficient for let's say a
video game. All of the same benefits accrue as with any other
application of REST. Thinking about your problem in terms of
document/data forces you to make URIs for objects. Doing that makes
things addressable. Other benefits follow naturally.

> Let's get back to verb URIs.  

One reason to keep verbs out of the URIs is that it then becomes
implicit what object is being acted *upon*. With REST it is explicit:

DELETE /foo/bar/baz

I can (for example) use ACLs to turn off DELETE permission to that URI
or URIs of that resource type.

Now compare to:

POST /foo/bar/baz?action=DELETE

Now you've moved the method up into the application level and a
pure-HTTP tool can't be used to secure it anymore. Now it needs to know
your application semantics. That's a big part of what REST is trying to
get away from.

> ... I think the insistence on not having verbs in
> URIs makes total sense for a document/data web.  It doesn't make as much
> sense for a services-oriented web.  We are already creating fragility by
> using verbs in the orders but we are not getting the benefit of having the
> verbs be addressable directly.

Who said we should use verbs in the order? Yes, the order has a
vocabulary that must be negotiated, as verbs must be negotiated in an
RPC system. But that doesn't mean there are verbs in the actual order.

> Ultimately, if we want to push REST as a way to implement action-oriented
> web services, we need to extend REST to support method invocation in a
> consistent and convenient way.  If not, we will need to have some other
> defining architecture which leverages URIs and loose-coupling as an
> alternative to RPC.

Well, SOAP is moving in that direction. If all you want is to send XML
to URIs, you can just send POSTs of XML. The standardization of the
verbs is a big part of what makes REST REST.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1575
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-18 23:36:19
Subject:Re: sending orders to order-takers
Message:

Joe Hsy wrote:
> 
> In this case the "verb" of this application is "offer".  You
> are essentially invoking the "make offer" method for the offer 
taker.  The
> order document is certainly essential, but it is part of the 
transaction.

No, you're POSTing the offer.  The verb is POST.







-----------------------------------------------------------------------------------
Post ID:1576
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-19 00:16:14
Subject:RE: [rest-discuss] sending orders to order-takers
Message:

-----Original Message-----
From: Paul Prescod [mailto:paul@...]

> In the second phase we acknowledge that the world is a complicated place
> and total interoperability will never come for free. REST isn't going to
> repeal the laws of the universe and physics. We are shifting
> interoperability hassles from the protocol down into the representation.
> ...
> The other reason it is much better to move interoperability into the
> representation is because it enables a wide variety of tools that don't
> care about the representation. URI-Browsers, caching proxies, encrypting
> proxies, method-triggered filters, mirroring tools, etc. You can just
> point these things at a set of URIs and they can do something useful
> without knowing anything about the XML vocabulary used.

I totally agree with this and you've done a great job articulating it as
usual.

> Different people use different definitions of RPC. I think that Mark's
> definition is that a protocol is an RPC protocol if the definition of
> new methods is something routinely done by the application, rather than
> in a networking-specific layer.

Interesting.  I was using a definition of RPC where the call and parameters
must be explicitly agreed-upon.  That may explain the difference in our
discussion.

> Okay, but in REST, the action will almost always result in a new
> resource that can be referenced and discussed. So you might as well call
> it the "submit attack request" action. i.e. POST

This is where I think we need a little flexibility.  I agree with the
benefit of actions always resulting in resources or state changes, but I
don't think we necessarily then have to force people to think of all actions
as posting a request document.  The benefits of a representational layer can
be there without this restriction.  

> Agreed, but we have much better tools for working with brittleness in
> the representation layer than we do at the protocol layer. 

Again, I agree completely.  And I would add that representational tools can
be used to model *actions* just as well as documents.  I think this gives
much more flexibility without sacrificing the benefits of having a
representational layer.

> REST is about recasting applications *into* document/data retrieval and
> hyperlinking applications!

I can see how this is, but I am hesitant to agree simply because I do not
believe that we need to turn every problem into a document/data retrieval
problem in order to enjoy the core benefits of REST.  This may not be the
best analogy, but I get the same feeling about this that I get from
physicist that want to recast every mechanical problems into physics
problems.  Sure, it is possible and there may be some benefits, but it is
often more work than necessary.

> *Except* for performance requirements, I think you'll have a hard time
> demonstrating that GET/PUT/POST/DELETE are insufficient for let's say a
> video game. All of the same benefits accrue as with any other
> application of REST. Thinking about your problem in terms of
> document/data forces you to make URIs for objects. Doing that makes
> things addressable. Other benefits follow naturally.

I have no doubt that we can build video games this way, but the question is
whether we would want to and do we really have to.  If our goals is to
encourage creating URIs for important objects and resources, we should make
that the explicit goal.  Forcing programmers to make everything into
document/data just to accomplish this goal as a side-effect seems to be
overkill.

> One reason to keep verbs out of the URIs is that it then becomes
> implicit what object is being acted *upon*. With REST it is explicit:
> 
> DELETE /foo/bar/baz
> 
> I can (for example) use ACLs to turn off DELETE permission to that URI
> or URIs of that resource type.
> 
> Now compare to:
> 
> POST /foo/bar/baz?action=DELETE
> 
> Now you've moved the method up into the application level and a
> pure-HTTP tool can't be used to secure it anymore. Now it needs to know
> your application semantics. That's a big part of what REST is trying to
> get away from.

This is a very good point, but think a more extensible way to create this
type of benefit is to create explicit action properties for ACLs to filter.
Actions can have other standard properties that may be useful filter
criteria such as "security-level", "does_modify", "no-side-effect".
Limiting ACL controls to only GET, PUT, POST, and DELETE seems to be much
too course-grained.

Furthermore, if we make actions explicit URIs, it is very simple to filter
access to those actions that the administrator wants to keep out.  This
would seem provide more fine-grained control.  In this way, the action is
not being moved to the application level, but rather it creates simple
implicit representation for that action in the from of an identifiable URI.

> Who said we should use verbs in the order? Yes, the order has a
> vocabulary that must be negotiated, as verbs must be negotiated in an
> RPC system. But that doesn't mean there are verbs in the actual order.

It wasn't me. 8-)  But, Seth certainly had no qualms putting verbs into the
order for attacking an ogre.  I don't think there is anything wrong with
that.  BTW, how would you represent an order to attack an ogre without using
any verbs?

> Well, SOAP is moving in that direction. If all you want is to send XML
> to URIs, you can just send POSTs of XML. The standardization of the
> verbs is a big part of what makes REST REST.

I like the fact that SOAP is moving away from SOAP-RPC (with explicit
binding) and I think it would be very good to have SOAP be part of REST in a
standard endorsed way.  As for standardization of verbs, again I don't know
if we're talking about application level verbs.  Protocol verbs are
standardized already with GET, PUT, POST, DELETE.  What you're suggesting
for REST is not standardizing application verbs, but recasting application
verbs into representational documents which can be acted upon by the
protocol verbs.

If the recommendation is to always recast applications verbs into documents,
I would suggest that instead of overloading the semantics of the POST verb,
we explicitly define a new protocol verb called EXECUTE with its own
semantics.  Then it is clear that what we're doing is sending
representations of actions to be executed.

Again, I appreciate the efforts of you and many others on explaining the
benefits.  I do hope this discussion is helpful as opposed to just
distracting.

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1577
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-19 00:21:02
Subject:RE: [rest-discuss] Re: sending orders to order-takers
Message:

-----Original Message-----
From: bhaugen32 [mailto:bhaugen32@...]

> No, you're POSTing the offer.  The verb is POST.

At the protocol level, certainly we are POSTing the purchase order.

But, at the application level, we are making an offer for a purchase.

To use Paul's term, by recasting the offer action into a "purchase order
offer document", then you can use the generic verb POST.  In any case, it
simply means that we can model the same transaction in both a document/data
way or a procedural method-call way.  They use different verbs.

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1578
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-19 00:33:07
Subject:Re: [rest-discuss] Re: sending orders to order-takers
Message:

On Tue, Jun 18, 2002 at 06:41:15PM -0400, Joe Hsy wrote:
> A good point.  In this case the "verb" of this application is "offer".

No, POST is the verb.

It's like this.  If I punch you in the nose, and you bleed as a result,
did I invoke your punch() or bleed() methods.  Answer; I invoked
punch(), and bleed() occurred as a side effect.

punch <-> POST
offer <-> bleed

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1579
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-19 00:29:49
Subject:RE: [rest-discuss] Re: sending orders to order-takers
Message:

-----Original Message-----
From: Mark Baker [mailto:distobj@...]

> No, POST is the verb.
> 
> It's like this.  If I punch you in the nose, and you bleed as a result,
> did I invoke your punch() or bleed() methods.  Answer; I invoked
> punch(), and bleed() occurred as a side effect.
> 
> punch <-> POST
> offer <-> bleed

Interesting analogy. 8-)  I think we're again talking different things.  To
take this analogy completely:

In canonical REST, you would be POSTing a "punch" action document to my nose
(verb = POST)

In simple English, you are *punching* my nose (verb = punch).

My nose may bleeds as a side effect, possibly, but that is hardly the verb
of interest here. 8-)

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1580
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-19 01:04:01
Subject:Re: sending orders to order-takers
Message:

Joe Hsy wrote:
> From: bhaugen
> 
> > No, you're POSTing the offer.  The verb is POST.
> 
> At the protocol level, certainly we are POSTing the purchase order.
> 
> But, at the application level, we are making an offer for a 
purchase.

HTTP *is* the application level.  

> To use Paul's term, by recasting the offer action into a "purchase 
order
> offer document", then you can use the generic verb POST.  In any 
case, it
> simply means that we can model the same transaction in both a 
document/data
> way or a procedural method-call way.  They use different verbs.

Maybe it would be good to look at this on the next layer up. 
There is a business protocol - offer-acceptance - riding on top of 
the HTTP+REST application protocol.  

Offer-acceptance is a conversational protocol.  
An offer is more like a sentence in a conversation than a procedural 
method-call.

I follow that there is more going on in state transfers than just 
GET, POST, PUT, etc.  And that there needs to be more layers of 
agreement than just the standard HTTP methods.

So if that is your main point, I agree.

If your point is that offer-acceptance is really a procedural method 
call, I disagree.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1581
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-19 04:30:49
Subject:Re: [rest-discuss] REST Best Practices
Message:

On Mon, Jun 17, 2002 at 06:08:33PM -0700, Joe Hsy wrote:
> Maybe at the root of what I'm trying to get at is that a method should have
> a URI.  Why should objects get all the benefits of universal addressability
> and not methods?

This has been a very odd conversation.  The answer to your question is
because objects (aka resources) are what the Web chose to center itself
upon.  You can try and give methods URIs if you like, and perhaps you'll
build something useful (I doubt it).  But it won't be REST.

I'm going to drop out of this now, since we've been around it several
times and you still don't appear to be getting it.  But best of luck
figuring this out! 8-)

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1582
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-19 04:53:21
Subject:RE: [rest-discuss] REST Best Practices
Message:

Mark, Joe,

FWIW, this kind of friction reinforces the fact that we need to get more
concrete about the REST architectural style.  More specifically, it reinforces
that we need samples......not just the ones we're sending around on the fly to
each other in this mailing list, but real coherent ones that can be compiled and
tested by people who discover the approach and need them to achieve "REST Zen"
[1].

Thanks,
Philip

[1]: "Michael Champion achieves REST Zen" from http://www.prescod.net

-----Original Message-----
From: Mark Baker [mailto:distobj@...]
Sent: Wednesday, June 19, 2002 12:31 AM
To: Joe Hsy
Cc: rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] REST Best Practices


On Mon, Jun 17, 2002 at 06:08:33PM -0700, Joe Hsy wrote:
> Maybe at the root of what I'm trying to get at is that a method should have
> a URI.  Why should objects get all the benefits of universal addressability
> and not methods?

This has been a very odd conversation.  The answer to your question is
because objects (aka resources) are what the Web chose to center itself
upon.  You can try and give methods URIs if you like, and perhaps you'll
build something useful (I doubt it).  But it won't be REST.

I'm going to drop out of this now, since we've been around it several
times and you still don't appear to be getting it.  But best of luck
figuring this out! 8-)

MB
--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com

To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.







-----------------------------------------------------------------------------------
Post ID:1583
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-19 05:07:08
Subject:Re: [rest-discuss] sending orders to order-takers
Message:

Joe Hsy wrote:
> 
>...
> 
> This is where I think we need a little flexibility.  I agree with the
> benefit of actions always resulting in resources or state changes, but I
> don't think we necessarily then have to force people to think of all actions
> as posting a request document.  The benefits of a representational layer can
> be there without this restriction.

Maybe, but it is seldom a restriction. When the semantic for something
is "here, take this and give it a URI", PUT or POST seems appropriate.
And if we're sending a representation and getting a URI back, then it
seems natural to think of it in this way.

>...
> I have no doubt that we can build video games this way, but the question is
> whether we would want to and do we really have to.  If our goals is to
> encourage creating URIs for important objects and resources, we should make
> that the explicit goal.  Forcing programmers to make everything into
> document/data just to accomplish this goal as a side-effect seems to be
> overkill.

Let's be clear that a video game is a very non-typical example. It is,
after all, all about verbs, because you are trying to communicate
behaviour to an on-screen avatar.

But think about more typical network services. Google is clearly a GET.
When you send an email you are POSTing the mail to a mailbox (or mail
queue). When you send an IM, you are POSTing a message. Newsreading
consists of GETting posts and POSTing new ones. Stock buying, selling
consists of GETting prices and POSTing orders. 

>...
> This is a very good point, but think a more extensible way to create this
> type of benefit is to create explicit action properties for ACLs to filter.

That's fine if you want application-level filtering. But if you
"subclass" the standard methods then you get application-agnostic
filtering "for free" from standard HTTP filtering software. Then you can
implement another level yourself if you want also.

>...
> Furthermore, if we make actions explicit URIs, it is very simple to filter
> access to those actions that the administrator wants to keep out.  This
> would seem provide more fine-grained control.  In this way, the action is
> not being moved to the application level, but rather it creates simple
> implicit representation for that action in the from of an identifiable URI.

My sense is that you more often want to filter on the object-type/method
pair. If they are both in the URI then you need to split the URI to do
that. That isn't hard but again its going to be specific to your
particular application and your particular way of encoding methods in
URIs.

> > Who said we should use verbs in the order? Yes, the order has a
> > vocabulary that must be negotiated, as verbs must be negotiated in an
> > RPC system. But that doesn't mean there are verbs in the actual order.
> 
> It wasn't me. 8-)  But, Seth certainly had no qualms putting verbs into the

> order for attacking an ogre.  

Okay, I thought we were talking ordering as in ordering pizza over the
Internet.

> .. I don't think there is anything wrong with
> that.  BTW, how would you represent an order to attack an ogre without using
> any verbs?

I would use a verb, but use the verb as a noun. I would "POST" an
action-request and the action-request might have an "action" attribute
which was a verb. In that particular case yes, I've pushed a verb into
the representation. But it stays there. I expect a new URI to be created
that *has that verb in it*. If it is a multiplayer game, I will get
everybody else in sync by pointing them at the resource I created. They
will fetch the verb-containing representation and do the right thing on
their screens. 

>...
> I like the fact that SOAP is moving away from SOAP-RPC (with explicit
> binding) and I think it would be very good to have SOAP be part of REST in a
> standard endorsed way.  As for standardization of verbs, again I don't know
> if we're talking about application level verbs.  Protocol verbs are
> standardized already with GET, PUT, POST, DELETE.  What you're suggesting
> for REST is not standardizing application verbs, but recasting application
> verbs into representational documents which can be acted upon by the
> protocol verbs.

Usually there is no need for application verbs. The protocol verbs are
sufficient. Most applications are about data, not actions.

> If the recommendation is to always recast applications verbs into documents,
> I would suggest that instead of overloading the semantics of the POST verb,
> we explicitly define a new protocol verb called EXECUTE with its own
> semantics.  Then it is clear that what we're doing is sending
> representations of actions to be executed.

But you don't have to overload. When you post an order you are really
POSTing an order. When you POST a player action, the player action is
really a bit of state that will be given a URI and persist.

> Again, I appreciate the efforts of you and many others on explaining the
> benefits.  I do hope this discussion is helpful as opposed to just
> distracting.

I think it is helpful to clarify the ideas for everyone.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1584
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-19 06:05:43
Subject:Re: [rest-discuss] sending orders to order-takers
Message:

----- Original Message ----- 
> 
> That's fine if you want application-level filtering. But if you
> "subclass" the standard methods then you get application-agnostic
> filtering "for free" from standard HTTP filtering software. Then you can
> implement another level yourself if you want also.

I think you may have meant override/inherit/reuse rather than "subclass"

Mike "I'm not so much pedantic as I am precise" D.








-----------------------------------------------------------------------------------
Post ID:1585
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-19 06:10:24
Subject:RE: [rest-discuss] REST Best Practices
Message:

> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> 
> This has been a very odd conversation.  The answer to your question is
> because objects (aka resources) are what the Web chose to 
> center itself
> upon.  You can try and give methods URIs if you like, and 
> perhaps you'll
> build something useful (I doubt it).  But it won't be REST.

Mark, I just reread the relevant URI chapter of Roy's thesis on REST and no
where does it indicate that a resource must be an object.  I still don't see
a real solid reason that giving methods URIs is a bad thing, but if it is
simply not REST for no particular reason other than that REST is defined to
not allow it, I guess so be it.

> I'm going to drop out of this now, since we've been around it several
> times and you still don't appear to be getting it.  But best of luck
> figuring this out! 8-)

Will miss your input.  I will need to spend more time on other things as
well. 8-)

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1586
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-19 06:14:44
Subject:RE: [rest-discuss] REST Best Practices
Message:

-----Original Message-----
From: Philip Eskelin [mailto:philip@...]

> Mark, Joe,
> 
> FWIW, this kind of friction reinforces the fact that we need to get more
> concrete about the REST architectural style.  More specifically, it
reinforces
> that we need samples......not just the ones we're sending around on the
fly to
> each other in this mailing list, but real coherent ones that can be
compiled and
> tested by people who discover the approach and need them to achieve "REST
Zen"
> [1].

Not sure friction is the best word for it, but I am learning from the
discussion and it has helped clarified why I thought a certain way.  More
solid examples of real applications would certain be useful!  Would be great
to see a RPG game implemented in REST.  A kind of REST Zen and the art of
web maintenance. 8-)

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1587
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-19 06:26:46
Subject:RE: [rest-discuss] sending orders to order-takers
Message:

 -----Original Message-----
From: Paul Prescod [mailto:paul@...]

> I would use a verb, but use the verb as a noun. I would "POST" an
> action-request and the action-request might have an "action" attribute
> which was a verb. In that particular case yes, I've pushed a verb into
> the representation. But it stays there. I expect a new URI to 
> be created
> that *has that verb in it*. If it is a multiplayer game, I will get
> everybody else in sync by pointing them at the resource I 
> created. They
> will fetch the verb-containing representation and do the 
> right thing on
> their screens. 

Paul, I agree with pretty much everything on this post, especially the
example outline in the above paragraph.  It is essentially the special type
of example where a verb can be useful (not required, but useful).  It allows
the representation of the action-request to have a URI.  This is kind of
what I've been trying to get at from the beginning.  Maybe I'm getting
closer to REST Zen. 8-)

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1588
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-19 06:34:34
Subject:RE: [rest-discuss] REST Best Practices
Message:

Joe Hsy wrote:
> Not sure friction is the best word for it, but I am learning from the
> discussion and it has helped clarified why I thought a certain way.
> More solid examples of real applications would certain be useful!
> Would be great to see a RPG game implemented in REST.  A kind of REST
> Zen and the art of web maintenance. 8-)

Maybe 'friction' is too harsh - how about 'disconnect' or 'initial
misconception'.  What I'm getting at is this: I can imagine that if/when REST
really catches on, this topic will be a very popular one, since people (like
myself) seem to have such a tendency to regress back to a procedural approach.

In your last message, you mentioned that you re-read some of the dissertation
and can't find any references to methods/objects.  I've been re-reading it too.
One thing I noticed was that in REST you have resources, and then you have
representations of resources that are transferred between components.

One type of component is a gateway (aka reverse proxy).  This is just like CGI.
Which is the source of many "verb" based designs on the web.  The implication I
get in this section of the document (sect 5.2.3) is that while representations
of resources are transferred to user agents directly from the origin server,
method invocation is encapsulated away from the origin server and behind a
gateway.  Do you get that implication as well?

I'll keep reading and see if I can find something that more explicitly clarifies
it.

-Philip







-----------------------------------------------------------------------------------
Post ID:1589
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-19 08:58:09
Subject:Re: [rest-discuss] REST Best Practices
Message:

Philip Eskelin wrote:
> 
>...
> 
> One type of component is a gateway (aka reverse proxy).  This is just like CGI.
> Which is the source of many "verb" based designs on the web.  The implication I
> get in this section of the document (sect 5.2.3) is that while representations
> of resources are transferred to user agents directly from the origin server,
> method invocation is encapsulated away from the origin server and behind a
> gateway.  Do you get that implication as well?

I agree. And in fact a CGI is more REST-y if it is used to expose
resources rather than used as an endpoint target for method invocations.

One strong indication that Fielding et al. did not anticipate that
resources would be methods is that resources are things with state. The
combination of state and behaviour is commonly called an "object": "In
object-oriented programming, objects include data and the procedures
necessary to operate on that data." -- geez I love dictionary.com.

In REST, resources have state and the procedures associated with them
are exposed as HTTP methods. The state is updated or retrieved through
representations.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1590
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-19 09:09:40
Subject:HTTP and Routing
Message:

HTTP allows for proxying but once the message has gone to the first
proxy the client has no more say about where it goes. SOAP Routing
allows a message to be directed hop by hop from one machine to another.
Rohit Khare has made the case that this is a new mechanism for
assembling software. Given an existing service you can add encryption,
or logging or reliable delivery or whatever by routing it.

One way to do this in HTTP is to POST an HTTP message which has as its
representation another HTTP message. This feels like it would work but
it also feels like tunnelling HTTP over HTTP. It isn't entirely
comfortable to me that I might have to POST a GET.

You can do all of this at the application level, and in fact this has
been done many times. For instance I can encrypt a GET by doing this:

http://www.encryptionservice.com/GET=http://www.someotheruri.com

And I could then add a translation service like this:

http://www.encryptionservice.com/GET=http://www.translate.com/GET=http://www.sometotheruri.com

(assume proper levels of escaping)

But is it really right to do it all at the application level?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1591
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-19 12:18:59
Subject:Re: [rest-discuss] HTTP and Routing
Message:

On Wed, Jun 19, 2002 at 05:09:40AM -0400, Paul Prescod wrote:
> But is it really right to do it all at the application level?

The problem is that there's no convention for chaining URIs like that.
But chaining URIs for routing is just one very specific way to route.
There are much more general ways, several of which our software uses.

One is specifying a path as a header, and using SOAP/RFC2774 to
make the header mandatory for processing (or not, if you don't care).
Another is to have the route specified hop-by-hop so that the initial
sender doesn't have complete knowledge; pub/sub routing does this.
There's a handful of other types, each specified in different ways
(a good thing).

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1592
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-19 13:33:28
Subject:RE: [rest-discuss] HTTP and Routing
Message:

Paul Prescod wrote:
> HTTP allows for proxying but once the message has gone to the first
> proxy the client has no more say about where it goes. SOAP Routing
> allows a message to be directed hop by hop from one machine to another.
> Rohit Khare has made the case that this is a new mechanism for
> assembling software. Given an existing service you can add encryption,
> or logging or reliable delivery or whatever by routing it.

One of the things that Fielding notes in section 5.3.1 of his dissertation is
that REST's style of layered system constraints help you introduct
intermediaries dynamically.  If you included routing semantics for multiple hops
in the body of a message, doesn't that imply that the message then relies upon
the arrangement of the network to be in a certain state?

It almost seems like Rohit has expanded the scope of routing to include
filtering and other transformational sematics; I personally would rather keep
them separate.  If a client has knowledge of multiple hops of routing (in order
to "route" through logging or encryption intermediaries), then you are taken
away from routing being controlled hop-by-hop and handled below the application
level.

> One way to do this in HTTP is to POST an HTTP message which has as its
> representation another HTTP message. This feels like it would work but
> it also feels like tunnelling HTTP over HTTP. It isn't entirely
> comfortable to me that I might have to POST a GET.

I'm sure you already know this, but Fielding includes the tunnel as a type of
connector.  This was an explicit decision based on the fact that REST components
should be free to switch from active component behavior to that of a tunnel.  I
like this approach, but I don't think routing semantics should be specified
and/or controlled at the application level because it would seem to
over-complicate dynamic rearrangement of services.

Regardless of message flow, in REST I think it is important to preserve that 1)
the origin server is the ultimate recipient of requests to modify the value of
its resources, and 2) that the user agent is the ultimate recipient of the
response.

-Philip







-----------------------------------------------------------------------------------
Post ID:1593
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-06-19 14:02:32
Subject:Re: [PMX:#] Re: [rest-discuss] Where does the Web community want to go? [Was:Changing relationship between SOAP and REST]
Message:

> The ironic thing is that the SOAP world is moving away from the SOAP
> serialization and moving to XML Schema-based mappings. But you are right
> to use what works today and SOAP serialization works in many languages
> today.

Yes.  There are fancy XML data binding libraries for perl, python, 
java... but not for C++.  ugh.

> Interesting. It's too bad you have to emulate HTTP though. One of the
> things we have to push SOAP, WSDL and XML Schema implementors on is
> modularity of implementations. You should be able to send the data over

We'd love to use HTTP actually (because lots of libraries exist for 
that).  But we have other issues that prevent us from using HTTP (as it 
works today).  Our remote devices are all behind firewalls.  When our 
central system wants to communicate with those devices, we have to place 
that message (a Request (hello HTTP)) into a store and forward system 
(currently a tuple space, another RESTful idea).  The remote devices 
connects to us and downloads all pending Requests.  We've basically made 
HTTP's Request and Response asynchronous here.  And our Request object 
looks just like an HTTP Request, only modeled as an object.  We are just 
PUTing things and GETing things.  Really sweet, actually.  More work on 
the server side because we have to introspect the incoming object and 
determine its state and what that means, but this leaves us open to 
great extensibility.  It's easier to modify the way we look at objects 
and their state than to upgrade an API.

Next up: using RDF to markup the incoming objects so we can start to 
infer things and become even more flexible about what we can accept. 
C'mon C++ XML toolkits!  We're waiting for you! :)

Seth







-----------------------------------------------------------------------------------
Post ID:1594
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-06-19 14:15:56
Subject:Re: [rest-discuss] Re: sending orders to order-takers
Message:

> A good point.  In this case the "verb" of this application is "offer".  You
> are essentially invoking the "make offer" method for the offer taker.  The
> order document is certainly essential, but it is part of the transaction.

I believe you want to be free of methods in a REST world.  REST talks 
about transferring state, not requesting a service to change a state for 
you.

The fact that a new purchase order is created (via PUT) triggers 
certains events on the server.  You don't call "make offer" you just PUT 
your offer.  The server then runs that offer through its state machine, 
giving it to listeners, etc, etc.  It will then return to you a document 
describing the result (hopefully, a Receipt document).

> Again, I am suggesting that documents/data are important in services, but so
> are verbs/actions.

The verbs, or actions, exist as business logic in the server.  They 
should be called directly by clients.  Two systems should not 
communicate via actions.  They should communicate via objects/documents. 
  That's what REST wants.  Eliminate the API from the protocol.  It will 
be easier to communicate objects (things) to other systems, not actions.

Seth







-----------------------------------------------------------------------------------
Post ID:1595
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-06-19 14:36:58
Subject:Re: [rest-discuss] sending orders to order-takers
Message:

>>Who said we should use verbs in the order? Yes, the order has a
>>vocabulary that must be negotiated, as verbs must be negotiated in an
>>RPC system. But that doesn't mean there are verbs in the actual order.
> 
> 
> It wasn't me. 8-)  But, Seth certainly had no qualms putting verbs into the
> order for attacking an ogre.  I don't think there is anything wrong with
> that.  BTW, how would you represent an order to attack an ogre without using
> any verbs?

hehe Right, I believe that Seth The Mighty would have a state of 
Running, or Attacking.  That is what the object Seth The Mighty is doing 
at that point.

I guess it comes down to object ownership.  My idea of REST is that a 
system (X) can request an object (via GET) from system (Y) and receive a 
representation of the state of that object.  That system (X) is then 
allowed to make changes to the object, therefor changing its state.  To 
save that state, the system (X) then transfers the object back to the 
system (Y) it got it from (via PUT) thereby changing its state.

In the above model, the object can be changed by (X).  (Y) merely 
/reacts/ to any state changes of that object.

In a verb centric world, where system (X) would explicitly ask system 
(Y) to make Seth The Mighty attack, the object is owned and controlled 
by system (Y).  No objects were transfered, no state traveled across the 
network.  Therefor, no REST.


> If the recommendation is to always recast applications verbs into documents,
> I would suggest that instead of overloading the semantics of the POST verb,
> we explicitly define a new protocol verb called EXECUTE with its own
> semantics.  Then it is clear that what we're doing is sending
> representations of actions to be executed.

Ahh... excelent way to phrase what you are talking about.  While that 
makes me understand what you want to do (think the Action pattern from 
GoF patterns book) I don't quite gel with that.  To me, it's worked out 
much better to just move objects around in the space and network.  So 
far, we've been able to have the server do things when objects meet 
certain states.  It keeps the coupling of our different systems WAY down 
  because now all we have to agree upon is our object hierarchy.  I 
don't have to get on the phone and talk through our list of 
actions/methods/etc and the right order to call them in, etc.  I just 
have to show them a UML diagram and say "You can send me representations 
of these objects.  I'll do the right thing."

Seth







-----------------------------------------------------------------------------------
Post ID:1596
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-06-19 14:42:11
Subject:Re: [rest-discuss] Re: sending orders to order-takers
Message:

Wow, good analogies as of late! :)

>>punch <-> POST
>>offer <-> bleed
> 
> 
> Interesting analogy. 8-)  I think we're again talking different things.  To
> take this analogy completely:
> 
> In canonical REST, you would be POSTing a "punch" action document to my nose
> (verb = POST)
> 
> In simple English, you are *punching* my nose (verb = punch).
> 
> My nose may bleeds as a side effect, possibly, but that is hardly the verb
> of interest here. 8-)

Ahh... reverse your thinking.  In REST, you are all about transfering 
state.  So, when you want to punch me, what are you changing?  Are you 
changing the state of my nose to bleed, or are you changing the state of 
your fist to "thrust"?

I would say you are PUTing a new state of your fist to the server.  The 
server then responds with a document describing the new state of my nose 
(bleeding).

Since you don't control me, you can only change the state of your object 
(to one of attacking).  The server can then run through what "Joe is now 
attacking" means to the world.  The server would then run through some 
business logic, and determine that you indeed hit me and I am bleeding. 
  That is a server induced state change, which can be communicated back 
to you.

Seth







-----------------------------------------------------------------------------------
Post ID:1597
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-19 15:49:20
Subject:Re: [rest-discuss] REST Best Practices
Message:

----- Original Message ----- 
From: "Joe Hsy" <joe.hsy@...>

> Would be great
> to see a RPG game implemented in REST.  A kind of REST Zen and the art of
> web maintenance. 8-)
I agree - an RPG would be a fun & engaging example.






-----------------------------------------------------------------------------------
Post ID:1598
Sender:"Leigh Dodds" <ldodds@...>
Post Date/Time:2002-06-19 15:49:44
Subject:RE: [rest-discuss] REST APIs
Message:

> I have been keeping tabs on Cocoon (http://xml.apache.org/cocoon/) as a possible 
> framework with which to build my next app. Has anyone any experience with how well Cocoon 
> and REST fit together in real life?

I've worked with Cocoon a fair bit recently, there are 3 tutorials on developerWorks 
that I wrote if you want some more background on it.

I've been thinking along the same lines, that Cocoon and REST might go well 
together, but haven't had time to explore this further.

It'd be nice to work through a sample REST application, nothing complex, 
and see how easy it is to implement in various frameworks.

Cheers,

L.






-----------------------------------------------------------------------------------
Post ID:1599
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-19 15:54:25
Subject:Re: [rest-discuss] REST Best Practices
Message:

----- Original Message -----
From: "Joe Hsy" <joe.hsy@...>

>
> I still don't see
> a real solid reason that giving methods URIs is a bad thing, but if it is
> simply not REST for no particular reason other than that REST is defined
to
> not allow it, I guess so be it.
If you transfer the state of the verb or method, then that is REST. If you
invoke the verb, then it is RPC-ish.
Hey, having a resource which is a script on a server & doing a PUT to set
its contents isn't 'wrong'. Associating that script resource with a schedule
or event via other HTTP methods isn't a bad idea - but I think to get the
actual behavior specified by the script text to be performed, you will need
a different URI.
One URI for messages that act upon the content of the script and one URI for
the messages that the script acts upon.

I know this isn't what you mean by a URI representing a verb, but that's as
close as I can get with REST.






-----------------------------------------------------------------------------------
Post ID:1600
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-06-19 16:10:49
Subject:Re: [rest-discuss] REST APIs
Message:

> I've worked with Cocoon a fair bit recently, there are 3 tutorials on developerWorks 
> that I wrote if you want some more background on it.
> 
> I've been thinking along the same lines, that Cocoon and REST might go well 
> together, but haven't had time to explore this further.
> 
> It'd be nice to work through a sample REST application, nothing complex, 
> and see how easy it is to implement in various frameworks.

We Cocoon a lot here, and it can accept XML documents in a POST.  The 
one thing that is nice about Cocoon is the sitemap, which is a mapping 
of logical URIs to physical resources.  But, as of about a month ago, 
you couldn't use the sitemap to look at the incoming XML to make decisions.

You can match on the URI string to direct to certain physical things on 
the web server, but you can't use XPath on the incoming document to make 
those decisions.  Once that happens, Cocoon will be very powerful.

I'm also not sure on Cocoon's support of PUT and DELETE.  I think it 
only handles GET and POST (since it's all build on Servlets, and they 
have a doService(), doGet() and a doPost()).

Seth







-----------------------------------------------------------------------------------
Post ID:1601
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-19 16:22:43
Subject:Fw: [rest-explore] Heads up on REST Birds-of-a-feather gathering at SDExpo.
Message:

Forwarding...

----- Original Message -----
From: "wsmeans" <smeans@...>
To: <rest-explore@yahoogroups.com>
Sent: Wednesday, June 19, 2002 6:13 AM
Subject: [rest-explore] Heads up on REST Birds-of-a-feather gathering at
SDExpo.


> Since I'm unable to post to the rest-discuss list (or even find out
> why I can't post), I'll post this here and hope that some of the
> interested parties read it.
>
> The CMP Media Software Development East Conference & Expo will be
> putting a REST birds-of-a-feather gathering on its calendar. I'll be
> hosting it, though due more to my own desire to learn more rather
> than to any particularly deep knowledge of REST lore on my part. The
> precise time hasn't been set yet, but as soon as it is, I'll post it
> here (assuming that I'm still able to.) The conference will be in
> Boston from November 18-22.
>
> I'm really hoping that this will be a chance for REST advocates to
> get their message a little further into the industry mainstream.
> Please make a note if you're planning to attend the conference or if
> you'll be in the Boston area in that timeframe.
>
>
>
> To unsubscribe from this group, send an email to:
> rest-explore-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>






-----------------------------------------------------------------------------------
Post ID:1602
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-06-19 18:08:52
Subject:Re: [rest-discuss] REST APIs
Message:

At 02:10 AM 20/06/2002, Seth Ladd wrote:


>I'm also not sure on Cocoon's support of PUT and DELETE.  I think it 
>only handles GET and POST (since it's all build on Servlets, and they 
>have a doService(), doGet() and a doPost()).

Servlet v2.x also has doDelete() and doPut(). Cocoon requires v2.2 so it should be able to be supported, but I don't know to what extent it actually is supported by Cocoon.

Robert







-----------------------------------------------------------------------------------
Post ID:1603
Sender:"Dana Cherkas"<newhgh1000@...>
Post Date/Time:2002-06-19 23:33:55
Subject:ressurec1,HGH Myth(s)
Message:

Hello, ressurec1@...

As seen on NBC, CBS, and CNN, and even Oprah! The health
discovery that actually reverses aging while burning fat,
without dieting or exercise! This proven discovery has even
been reported on by the New England Journal of Medicine.
Forget aging and dieting forever! And it's Guaranteed!


* Reduce body fat and build lean muscle WITHOUT EXERCISE!
* Enhace sexual performance
* Remove wrinkles and cellulite
* Lower blood pressure and improve cholesterol profile
* Improve sleep, vision and memory
* Restore hair color and growth
* Strengthen the immune system
* Increase energy and cardiac output
* Turn back your body's biological time clock 10-20 years
in 6 months of usage !!!

FOR FREE INFORMATION AND GET FREE 1 MONTH SUPPLY OF HGH CLICK HERE















You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here




-----------------------------------------------------------------------------------
Post ID:1604
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-20 13:52:01
Subject:Re: [rest-discuss] Re: REST transaction idea
Message:

I've finally read through this thread.

I think that I come down in between Paul and Bob here; not that there
is much of a "middle", since they're pretty close.

> Paul Prescod wrote:
> > Okay, let's first define transactions in the context of this 
> discussion
> > because people often mean different things. You do not mean 
> transaction
> > in the sense of requiring "a group of operations on (distributed)
> > resources be treated as one unit of work. In a unit of work, all the
> > participating operations should either succeed or fail and recover
> > together." 
> 
> Oh, but I *do* mean a unit of work, in the sense of two trading 
> partners coming to agreement on advancing a business deal to the next 
> state.  Each business transaction succeeds or fails as a whole.

Exactly right.  I do consider this a transaction.  The problem with it
as discussed so far, is that it isn't composable with itself, so it
will only ever be good for this one task.

So I think what's here is a useful start, but isn't yet the kind of
thing I would call a "building block".  It needs something more.

Unfortunately I'm no transaction guru.  But I've got an email from
Mark Little in my inbox that I should get to - perhaps he has some
ideas.

> > > In cases where the Response document says "Accept" but has an 
> error,
> > > and the error message from the requesting business service cannot 
> be
> > > delivered, the transaction model specifies a separate 
> Notification of
> > > Failure to be sent from the requesting business service via 
> another
> > > channel.  Otherwise the responding activity may think incorrectly
> > > that the transaction succeeded.
> > 
> > I see, so otherwise it is to assume the transaction succeeded if it
> > returns an Accept, whether it gets a receipt or not?
> 
> Well, it would be a bad assumption, but the end state is ambiguous, 
> and ambiguities are what sometimes end up in court.

I don't understand this yet.  How can a response document say "Accept"
but have an error?  And if, for the sake of argument we assume that's
ok, then shouldn't it be part of the contract that the "Acceptee"
catch up to state (GET) prior to proceeding with any further work?

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1605
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-20 15:38:58
Subject:Re: REST transaction idea
Message:

Mark Baker wrote:
> I've finally read through this thread.

Thanks.  It's just a starting place.  
The implications could spawn several other threads.

> > Oh, but I *do* mean a unit of work, in the sense of two trading 
> > partners coming to agreement on advancing a business deal to the 
next 
> > state.  Each business transaction succeeds or fails as a whole.
> 
> Exactly right.  I do consider this a transaction.  The problem with 
it
> as discussed so far, is that it isn't composable with itself, so it
> will only ever be good for this one task.
> 
> So I think what's here is a useful start, but isn't yet the kind of
> thing I would call a "building block".  It needs something more.

How do you mean "composable", and what more does it need?
I'm not disagreeing. The idea was meant as a toe in the door, to see 
if any kind of conversation-like interaction would be acceptable to 
the REST gurus.  If so, then we'll see where it can go.

Here are some possible dimensions of composability.  
Do you mean one of these, or something else?

1. This thread focused on offer-acceptance.  But almost every 
business protocol I can think of has a similar kind of interaction, 
where both trading partners must explicitly agree on the next state 
of the business deal.  The interaction pattern could be exactly the 
same.  See also #2:

2. Offer-acceptance is only the beginning of a longer conversation.  
For example, an offer to buy, when accepted, is intended to be 
fulfilled and paid for. 
So at least two other transactions will be forthcoming:  
* Deliver the committed goods or services, which I will call "Notify-
Comfirm".  Notify is where the seller notifies the buyer that the 
goods or services have been delivered, to the seller's best 
understanding.  Confirm is where the buyer either agrees or disagrees.
Notify-Confirm is actually the same as offer-acceptance.
Notify is equivalent to Offer, Confirm equivalent to Accept.
* Pay - also a Notify-Confirm transaction.

3. The longer conversation (an economic exchange) has its own 
patterns.  It can be orchestrated or choreographed based on the 
states of the resources representing the economic commmitments and 
fulfillment events of the business deal.  In other words, when all 
the commitments have been fulfilled, the order is complete.
(That's what a lot of business people mean by "a transaction".)

4. The whole economic exchange between two trading partners may be 
hyperlinked into a network of economic exchanges - a value system or 
supply chain.  For example, if I order a computer from Dell, my 
economic exchange with Dell may be hyperlinked to a slot on Dell's 
assembly schedule, which in turn may be hyperlinked to economic 
exchanges with Dell's suppliers for components, etc., turtles all the 
way down.

> Unfortunately I'm no transaction guru.  

Nor am I, I'm just following my nose.

> But I've got an email from
> Mark Little in my inbox that I should get to - perhaps he has some
> ideas.

If so, please pass them on.
 
> I don't understand this yet.  How can a response document 
say "Accept"
> but have an error?  

Lots of ways, for example:
1. Could be too late.  Offers are not good forever.  The buyer needs 
to be able to move on to a different seller.
2. The seller could have tried to change the offer in the response 
document or in some other way violate the rules of the deal.
3. There could have been authorization or certificate or signature 
problems.

Thanks for the feedback, I know you've been very busy.
-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1606
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-20 16:06:05
Subject:Re: [rest-discuss] Re: REST transaction idea
Message:

On Thu, Jun 20, 2002 at 11:38:58AM -0400, bhaugen32 wrote:
> How do you mean "composable", and what more does it need?

I mean that it should be possible to build up more complex business
level coordination from whatever we decide is a good building
block.

So for example, we'd be able to build a three-way
producer/supplier/subordinate-supplier transaction by composing two
instances of the two-party version.

Give/take, and all that. P-)

> 1. This thread focused on offer-acceptance.  But almost every 
> business protocol I can think of has a similar kind of interaction, 
> where both trading partners must explicitly agree on the next state 
> of the business deal.  The interaction pattern could be exactly the 
> same.  See also #2:
> 
> 2. Offer-acceptance is only the beginning of a longer conversation.  
> For example, an offer to buy, when accepted, is intended to be 
> fulfilled and paid for. 
> So at least two other transactions will be forthcoming:  
> * Deliver the committed goods or services, which I will call "Notify-
> Comfirm".  Notify is where the seller notifies the buyer that the 
> goods or services have been delivered, to the seller's best 
> understanding.  Confirm is where the buyer either agrees or disagrees.
> Notify-Confirm is actually the same as offer-acceptance.
> Notify is equivalent to Offer, Confirm equivalent to Accept.
> * Pay - also a Notify-Confirm transaction.
> 
> 3. The longer conversation (an economic exchange) has its own 
> patterns.  It can be orchestrated or choreographed based on the 
> states of the resources representing the economic commmitments and 
> fulfillment events of the business deal.  In other words, when all 
> the commitments have been fulfilled, the order is complete.
> (That's what a lot of business people mean by "a transaction".)
> 
> 4. The whole economic exchange between two trading partners may be 
> hyperlinked into a network of economic exchanges - a value system or 
> supply chain.  For example, if I order a computer from Dell, my 
> economic exchange with Dell may be hyperlinked to a slot on Dell's 
> assembly schedule, which in turn may be hyperlinked to economic 
> exchanges with Dell's suppliers for components, etc., turtles all the 
> way down.

I think the type of composition I have in mind could be used for all
of these, though I'd focus on building more generic patterns as I
described above, with the hopes that it would cover off what you've
written there.

When I think of this stuff, I inevitably think back to Bill Mcarthy's
presentation at OOPSLA '97 Business Object workshop, about REA and
the various interaction patterns seen in business;

http://jeffsutherland.com/oopsla97/oo97final.html

Unfortunately the content of that presentation isn't available, but I
remember the gist quite clearly.

> > I don't understand this yet.  How can a response document 
> say "Accept"
> > but have an error?  
> 
> Lots of ways, for example:
> 1. Could be too late.  Offers are not good forever.  The buyer needs 
> to be able to move on to a different seller.
> 2. The seller could have tried to change the offer in the response 
> document or in some other way violate the rules of the deal.
> 3. There could have been authorization or certificate or signature 
> problems.

Ah, I see.  So what I described would apply then; that the expectation
that a fault might happen should be part of the contract, and that
the sides should synch up in some manner, before proceeding past a
point of no return if it turns out that this error condition did
occur.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1607
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-20 16:13:15
Subject:Re: REST transaction idea
Message:

Mark Baker wrote:
> On Thu, Jun 20, 2002 at 11:38:58AM -0400, bhaugen32 wrote:
> > How do you mean "composable", and what more does it need?
> 
> I mean that it should be possible to build up more complex business
> level coordination from whatever we decide is a good building
> block.
> 
> So for example, we'd be able to build a three-way
> producer/supplier/subordinate-supplier transaction by composing two
> instances of the two-party version.
> 
> Give/take, and all that. P-)

See 
http://jeffsutherland.org/oopsla2000/mccarthy/mccarthy.htm
A little out of date, but still valid.  
You're describing an input-process-output-exchange-input-process-etc. 
chain.  It's the same as case #4:

> > 4. The whole economic exchange between two trading partners may 
be 
> > hyperlinked into a network of economic exchanges - a value system 
or 
> > supply chain.  For example, if I order a computer from Dell, my 
> > economic exchange with Dell may be hyperlinked to a slot on 
Dell's 
> > assembly schedule, which in turn may be hyperlinked to economic 
> > exchanges with Dell's suppliers for components, etc., turtles all 
the 
> > way down.
> 
> I think the type of composition I have in mind could be used for all
> of these, though I'd focus on building more generic patterns as I
> described above, with the hopes that it would cover off what you've
> written there.

See below.

> When I think of this stuff, I inevitably think back to Bill 
Mcarthy's
> presentation at OOPSLA '97 Business Object workshop, about REA and
> the various interaction patterns seen in business;
> 
> http://jeffsutherland.com/oopsla97/oo97final.html
> 
> Unfortunately the content of that presentation isn't available, but 
I
> remember the gist quite clearly.

Yes, I'm still working closely witb Bill, and everything I'm talking 
about here has his basic REA give-take pattern right in the middle of 
it.  We also collaborated in a UN/CEFACT project entitled Business 
Collaboration Patterns and Monitored Commitments.  My goal was to 
start to define the patterns you request above.

The project had some problems, including my lacks of time and 
resources, but I think I know how to define the stuff now, although 
the work of clearly writing the patterns remains.  

One of the missing pieces was REST.  I was not happy with the way 
ebXML did some things.  REST is better.

Onward!

And have fun,
Bob Haugen








-----------------------------------------------------------------------------------
Post ID:1608
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-20 16:40:07
Subject:Re: [rest-discuss] Re: REST transaction idea
Message:

On Thu, Jun 20, 2002 at 12:13:15PM -0400, bhaugen32 wrote:
> One of the missing pieces was REST.  I was not happy with the way 
> ebXML did some things.  REST is better.

Absolutely.  So do you agree that the basic interaction pattern you
described wasn't easily composable into more complex patterns?  I'm
still thinking this through, so I may have missed something.  Was it a
goal of that description you provided to be composable in that way?

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1609
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-20 17:44:44
Subject:Re: REST transaction idea
Message:

Mark Baker wrote:
> On Thu, Jun 20, 2002 at 12:13:15PM -0400, bhaugen32 wrote:
> > One of the missing pieces was REST.  I was not happy with the way 
> > ebXML did some things.  REST is better.
> 
> Absolutely.  

I should add, in case any of my ebXML buddies read this, ebXML did a 
lot of things right, too.  That's where I learned this transaction 
pattern.

> So do you agree that the basic interaction pattern you
> described wasn't easily composable into more complex patterns?  I'm
> still thinking this through, so I may have missed something.  Was 
it a
> goal of that description you provided to be composable in that way?

I think the transaction pattern is composable.  But you do need to 
surround it with the resources.  In other words, the transaction 
pattern is all about getting agreement on the state(s) of the resource
(s).  The resource states are the composable elements on the next 
layer.  REA defines all the necessary resources, by the way.

In this document:
http://www.gefeg.com/tmwg/files/Chapter%209%20PatternsR10.pdf
UN/CEFACT lists 6 transaction patterns:
1. Commercial Transaction (of which Offer-Acceptance is an instance)
2. Request/Confirm
3. Query/Response
4. Request/Response
5. Notification
6. Information Distribution
...and a bunch of interaction patterns.

If you look at those in detail, you'll think "EDI-mailbox-style", and 
you'll be right.  But I learned all this stuff from yet another guy 
named Jim Clark, one of the designers of RosettaNet.  And his goal 
was always to get these patterns in a way that was technology-
neutral, because he did not think EDI-mailbox-style was the end of 
the line.  

Am I speaking to your composability issue adequately yet?
If not, please give me more guidance.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1610
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-20 17:47:34
Subject:RE: [rest-discuss] HTTP and Routing
Message:

Hi Paul,

This is an interesting idea, but I think embedding the routing into the URI
removes the ease of adding new "itilities" as Khare poses as one of the
advantages of routing.  It forces the a priori lock-in of the route upon
creation of the URI.  It seems to me that one of the main ideas is that you
can change the route and add other interesting processing later.

//Joe


-----Original Message-----
From: Paul Prescod [mailto:paul@...]
Sent: Wednesday, June 19, 2002 2:10 AM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] HTTP and Routing


HTTP allows for proxying but once the message has gone to the first
proxy the client has no more say about where it goes. SOAP Routing
allows a message to be directed hop by hop from one machine to another.
Rohit Khare has made the case that this is a new mechanism for
assembling software. Given an existing service you can add encryption,
or logging or reliable delivery or whatever by routing it.

One way to do this in HTTP is to POST an HTTP message which has as its
representation another HTTP message. This feels like it would work but
it also feels like tunnelling HTTP over HTTP. It isn't entirely
comfortable to me that I might have to POST a GET.

You can do all of this at the application level, and in fact this has
been done many times. For instance I can encrypt a GET by doing this:

http://www.encryptionservice.com/GET=http://www.someotheruri.com

And I could then add a translation service like this:

http://www.encryptionservice.com/GET=http://www.translate.com/GET=http://www
.sometotheruri.com

(assume proper levels of escaping)

But is it really right to do it all at the application level?

Paul Prescod

To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1611
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-06-20 18:30:09
Subject:Re: [rest-discuss] HTTP and Routing
Message:

Short version:  this is a horrible idea.  Anybody else on this list been
around long enough to remember the bad old days of grotty mail addresses
like 

   research!ucbvax!dagobah!td

and similar?  Explicit path-based addressing was a bad idea then in that
context, it's a bad idea now in the context of SOAP Routing, and it's an
absolutely horrendous idea to do it in the context of embedding this kind of
information in URI.

Also note that in *all* current successful examples of routing (at least
that I can think of) there is a clear distinction between addressing and
routing.  It's a bad idea to embed routing information explicitly in names /
addresses for all kinds of reasons, and a moments reflection on successful
routing schemes will demonstrate that it's just not done.  In fact, this
isn't really routing at all:  it's "path-based addressing."

Arguments have been offered elsewhere against SOAP Routing that generally
apply here as well.  The short version is that path-based addressing an
administrative nightmare and a reliability black hole.  There are perhaps a
few new arguments as well, re: the philosophy of the Web, e.g.:  what
exactly are you naming when you write a URI like that?

There's no reason to truly "route" at *any* level (much less the application
level) unless physical connectivity / topology demands it.  Now, a more
abstract "routing" in the sense of iterative hand-offs via 3xx and dynamic
name resolution are a great idea at the application level, but that's a
different beast.

I'm happy to drill down on this if necessary, but I really think that can be
avoided with just a bit of thought about what things would look like if this
kind of idea was deployed.  Ick, yuck, gag.

Jb







-----------------------------------------------------------------------------------
Post ID:1612
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-06-20 19:09:35
Subject:Re: [rest-discuss] HTTP and Routing
Message:

Jeff Bone wrote:
> Short version:  this is a horrible idea.  Anybody else on this list been
> around long enough to remember the bad old days of grotty mail addresses
> like 
> 
>    research!ucbvax!dagobah!td 

+1

Seth







-----------------------------------------------------------------------------------
Post ID:1613
Sender:Lucas Gonze <lgonze@...>
Post Date/Time:2002-06-20 19:51:38
Subject:Re: [rest-discuss] HTTP and Routing
Message:

A RESTy design for routing is to model the forward path as a resource and
*not* to model the forward path as message-in-message.  Aside from being
ideologically correct, you get clean separation and development
simplicity.

for example, to forward to Jeff via Joe:

PUT or POST to joe://messages/jeff/
...message body here as xm...

From there Joe can figure out for himself how to assemble the headers.

- Lucas








-----------------------------------------------------------------------------------
Post ID:1614
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-06-20 20:11:50
Subject:Re: [rest-discuss] HTTP and Routing
Message:

On 6/20/02 2:51 PM, "Lucas Gonze" <lgonze@...> wrote:

> 
> A RESTy design for routing is to model the forward path as a resource and
> *not* to model the forward path as message-in-message.  Aside from being
> ideologically correct, you get clean separation and development
> simplicity.
> 
> for example, to forward to Jeff via Joe:
> 
> PUT or POST to joe://messages/jeff/
> ...message body here as xm...
> 
>> From there Joe can figure out for himself how to assemble the headers.
> 
> - Lucas

Right.  Actually, that's not just a RESTy design, that's the right way to do
addressing / routing, period.  The address states where you want to get to,
not how you're going to get there --- that's a different job, appropriately
and best handled by a different mechanism.  If we've all learned anything in
20+ years of protocol design, hopefully we've learned that information
spaces should be abstracted as far away as possible from the details of
navigating them.

Random thought:  that's probably the best argument for the Axiom of Opacity
that I've yet encountered, oops. ;-)

Jb







-----------------------------------------------------------------------------------
Post ID:1615
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-20 20:34:06
Subject:Re: [rest-discuss] HTTP and Routing
Message:

Call me naive, but I have no problem with this sort of routing.  We use
it a *lot* here, and it works great.  I think you just have to
understand the limited context in which it is used/useful.

Our use case is basically, I want to send a HTTP message to some server,
and I specify a proxy (or proxies) through which the message first
traverses.  Each of those proxies has to be trusted by the party that
specifies them.

So, for example, we use it from our wireless browser to specify a path
that includes an intermediary that converts from RIM base station ids
to the soon-to-be-standardized GEO headers (http://geotags.org).
We also use it for security, so that the user can "turn on" security,
which basically sends messages through a proxy that wraps them up
with S/MIME.

"Static routing", as we refer to this, is certainly not a general
routing solution.  We support 3 other types of routing, for different
types of integration problems.  But static routing definitely has its
space - it's the most common form of routing that we use, which I think
says something for the needs of wireless.  Other domains may use other
types of routing more commonly.  No surprise there, I hope.

Lucas wrote;
> PUT or POST to joe://messages/jeff/
> ...message body here as xm...

BTW, what the heck does that mean?  Are you really suggesting using a
URI scheme to identify people, or am I misreading?

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1616
Sender:Lucas Gonze <lgonze@...>
Post Date/Time:2002-06-20 20:21:51
Subject:Re: [rest-discuss] HTTP and Routing
Message:

> "Static routing", as we refer to this, is certainly not a general
> routing solution.  

You're a special case here.  If HTTP proxies can do the job, why not.  
But if you think you need a protocol gateway, stop and think twice.

> Lucas wrote;
> > PUT or POST to joe://messages/jeff/
> > ...message body here as xm...
> 
> BTW, what the heck does that mean?  Are you really suggesting using a
> URI scheme to identify people, or am I misreading?

It's not identifying people so much as labelling resources by their
purpose.  Jeff's mailbox/ messages bound for Jeff.

- Lucas








-----------------------------------------------------------------------------------
Post ID:1617
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-06-20 21:01:27
Subject:Re: [rest-discuss] HTTP and Routing
Message:

On 6/20/02 3:34 PM, "Mark Baker" <distobj@...> wrote:

> Call me naive, 

Okay. ;-)

Ugh, I had hoped that invoking the spectre of "research!ucbvax!dagobah!td"
would be sufficient, but apparently not.  BTW:  I'm all for composition of
Web-based services, but the venerable pipeline isn't the right compositional
metaphor for the distributed / cross-administrative-domain case.

I'll stipulate the following:  "static routing" i.e. path-based addressing
may well have its appropriate uses, but only in the context where the entire
path is within a single administrative domain / context and only when the
entire chain represents a single, synchronous end-to-end interaction.  Let's
drill down, using the following two analogous examples

  http://foo.com/GET=http://bar.com/GET=http://baz.com/stuff
  rsh foo.com rsh bar.com rsh baz.com cat stuff

Think about all the ways these can break...

(1)  BRITTLE.  As soon as you cross an administrative boundary, you've
rendered your application hopelessly brittle.  You're entirely at the mercy
of the downstream hops -wrt- namespace continuity, connectivity,
environment, reporting and management of your failure modes, etc.  What
happens if the originating client has connectivity the the third hop, but
the second hop does not for some reason?

(2)  FAILURE MODES and SEMANTICS.  What happens if the second "hop" fails?
The third "hop?"  What should the client see?  What *can* the client know
about those failures?  What are the semantics of chained HTTP responses?
One might argue that this is nothing more than the current chained proxy
scenario, but once you introduce additional filtering / operational
semantics in the intermediaries it becomes much more (IMO untenably)
complex.  Proxies work because they're (more or less) transparent;  the
entire purpose of the intermediaries in the above is to perform some
function.

(3)  ADMINISTRATIVE / CONFIG COMPLEXITY.  The administrative picture is
extremely complex.  You are assuming that whatever appropriate
administrative relationships, etc. have been established between each
intermediary and its downstream for any give pipeline.  For example, you
assume that bar.com knows how to transform the representation it gets from
baz.com, as well as any other representation it gets.  That's not a safe
assumption;  it will only be true with a priori arrangement / communication
between baz.com and bar.com.  You could automate this by way of schemas,
RDDL, etc. --- but I don't see how it's realistic or desirable to embed
*that* information in URI...

Those comments are really just the tip of the iceberg...  I *will* admit
that the problems aren't as many or as serious in the case of synchronous
HTTP pipelining as they are in the async case e.g. SOAP Routing.  In the
latter, not only have you surrendered all control of reliability, failure
modes, etc. but you ALSO have *absolutely* no way of guaranteeing that you
know anything at all about the state of your request once it's handed off to
the first hop!

Multilevel pipes just aren't appropriate in the distributed / cross-domain
case.  Much better to maintain local control of your app *and* your failure
modes by having pairwise interactions with the services you need to interact
with:

Not  

  foo | bar | baz | baf > out

Rather

  foo > 1
  bar < 1 > 2
  baz < 2 > 3
  baf < 3 > out

With the latter, you have visibility to and control the entire execution
flow and intermediate states, and can accommodate and respond to failures
and exceptional conditions yourself, rather than relying on someone else to
do what needs to be done.

But all this is just explanatory overkill:  just think

  research!ucbvax!dagobah!td

and *shudder.*


Jb







-----------------------------------------------------------------------------------
Post ID:1618
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-20 21:25:42
Subject:Re: [rest-discuss] HTTP and Routing
Message:

I don't have time today to get into debates about this stuff in detail.
Jeff, you should probably see if you can pick a fight with Rohit because
he has thought about this stuff more than I have. Nevertheless, I'll
point out that this technique has been used effectively.

http://web.lfw.org/math/ 
 e.g.
http://web.lfw.org/math/nph-pmpm.cgi/http://web.lfw.org/math/alvirne-28.html
http://web.shodouka.com/
 e.g. http://web.lfw.org/shodouka/http://www.yahoo.co.jp/
http://crit.org/ 
 e.g. http://crit.org/http://www.erights.org/

There are basically only a few ways to compose a service and a GET. You
can either do a GET that triggers another GET, or you can do the GET and
then feed the data from the get into the service. The former can be done
in a declarative, addresable way. The latter cannot.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1619
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-06-20 21:33:31
Subject:Re: [rest-discuss] HTTP and Routing
Message:

On 6/20/02 4:25 PM, "Paul Prescod" <paul@...> wrote:

> I don't have time today to get into debates about this stuff in detail.
> Jeff, you should probably see if you can pick a fight with Rohit

I'm certainly not out to pick a fight with anybody;  rather, my visceral
reaction to this stuff stems from some really, really, really unpleasant
experiences with analogous addressing / routing schemes (e.g., UUCP, e-mail)
back in the day.  I see no reason to believe that it will work any better in
this arena than it did back then.

Jb







-----------------------------------------------------------------------------------
Post ID:1620
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-06-20 21:51:11
Subject:Re: [rest-discuss] Two other bits... re: HTTP and Routing
Message:

On 6/20/02 4:25 PM, "Paul Prescod" <paul@...> wrote:

> Nevertheless, I'll
> point out that this technique has been used effectively.
> 
> http://web.lfw.org/math/
> e.g.
> http://web.lfw.org/math/nph-pmpm.cgi/http://web.lfw.org/math/alvirne-28.html
> http://web.shodouka.com/
> e.g. http://web.lfw.org/shodouka/http://www.yahoo.co.jp/
> http://crit.org/ 
> e.g. http://crit.org/http://www.erights.org/

It's worth noting that there's a BIG difference between just embedding a URI
within another URI and assuming that doing so in some particular way results
in chained GETs.  I'm all for the former; in none of the cases you mention
above is it safe to assume anything like the latter.  In each of these
cases, you're referring to a resource in the top-level namespace.  The fact
that the URI contains an embedded URI is both coincidental *and* meaningless
to you --- the URI is opaque, and you can't assume that it represents a
pipeline construction.

> There are basically only a few ways to compose a service and a GET. You
> can either do a GET that triggers another GET, or you can do the GET and
> then feed the data from the get into the service. The former can be done
> in a declarative, addresable way. The latter cannot.

This is a bit mom-and-apple-pie;  sure, declarative is great, we all love
declarative.  But the fact that you're embedding order-dependent procedural
semantics in what is otherwise a declarative medium (URI) doesn't make it
any more or less declarative than if the pipeline is locally controlled /
exists in some medium other than a URI.  (Consider:  the pipeline could be
just as declaratively constructed in some XML form that is interpreted and
managed locally.)

I'm not opposed to pipes, Paul --- I just think it's important to realize
that you need to locally control all the transitions between intermediates,
rather than assume that some third party will correctly and reliably do that
for you.  Consider:  even in the shell case of foo | bar | baz, in fact the
shell is arranging the connections between them by twiddling file
descriptors.  Control isn't handed down the pipe.

Jb







-----------------------------------------------------------------------------------
Post ID:1621
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-21 03:13:21
Subject:Re: [rest-discuss] HTTP and Routing
Message:

On Thu, Jun 20, 2002 at 04:01:27PM -0500, Jeff Bone wrote:
> (1)  BRITTLE.  As soon as you cross an administrative boundary, you've

Yes, that's why I said that for us, the entire chain is "trusted".

> (2)  FAILURE MODES and SEMANTICS.  What happens if the second "hop" fails?
> The third "hop?"  What should the client see?  What *can* the client know
> about those failures?  What are the semantics of chained HTTP responses?
> One might argue that this is nothing more than the current chained proxy
> scenario, but once you introduce additional filtering / operational
> semantics in the intermediaries it becomes much more (IMO untenably)
> complex.  Proxies work because they're (more or less) transparent;  the
> entire purpose of the intermediaries in the above is to perform some
> function.

No, it's actually quite straightforward.  We spent lots of time checking
this.  It works great, with very simple rules.  A client only cares
about the request, but debugging can occur with the Via header if
required.

Basically, if you use the SOAP processing model, which encapsulates
proper behaviour for any intermediary, you're good.

> But all this is just explanatory overkill:  just think
> 
>   research!ucbvax!dagobah!td
> 
> and *shudder.*

The implementation was crappy, but the theory was good.  I'm with Rohit
on this.  I think you'll see bang paths again.

Mark "uunet|tsltor!markb" Baker
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1622
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-06-21 03:12:46
Subject:Re: [rest-discuss] HTTP and Routing
Message:

On 6/20/02 10:13 PM, "Mark Baker" <distobj@...> wrote:

> 
> The implementation was crappy, but the theory was good.  I'm with Rohit
> on this.  I think you'll see bang paths again.

Would somebody mind providing a pointer to Rohit's utterances on this?  No
longer on FoRK, and a cursory examination of the archive (subject lines
only) yielded nada...

As for bang paths, all I can say is I hope *you* have to administer a
machine that lots of folks try to "route" through... :-P ;-)

Jb







-----------------------------------------------------------------------------------
Post ID:1623
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-21 03:31:38
Subject:Re: [rest-discuss] HTTP and Routing
Message:

On Thu, Jun 20, 2002 at 10:12:46PM -0500, Jeff Bone wrote:
> Would somebody mind providing a pointer to Rohit's utterances on this?  No
> longer on FoRK, and a cursory examination of the archive (subject lines
> only) yielded nada...

Ack.  I couldn't tell you if it was said on FoRK, in private email, or
in person.

Basically, each name in the path would be a key fingerprint.  Oh wait,
I remember a FoRK email talking about "Rohit's Adam", aka
<adams-fingerprint>!<rohits-fingerprint>.  Relative naming.

> As for bang paths, all I can say is I hope *you* have to administer a
> machine that lots of folks try to "route" through... :-P ;-)

I used to co-administer such a machine, snarfing maps from can.uucp.maps
Ah, the good old days.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1624
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-21 03:33:14
Subject:Re: [rest-discuss] HTTP and Routing
Message:

On Thu, Jun 20, 2002 at 11:31:38PM -0400, Mark Baker wrote:
> Basically, each name in the path would be a key fingerprint.  Oh wait,
> I remember a FoRK email talking about "Rohit's Adam", aka
> <adams-fingerprint>!<rohits-fingerprint>.  Relative naming.

Oops, obviously got that backwards.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1625
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-06-21 03:33:17
Subject:Re: [rest-discuss] Namespace composition, not path-based addressing was re: HTTP and Routing
Message:

On 6/20/02 10:12 PM, "Jeff Bone" <jbone@...> wrote:

> On 6/20/02 10:13 PM, "Mark Baker" <distobj@...> wrote:
> 
>> 
>> The implementation was crappy, but the theory was good.

Actually, my gut tells me that it's the theory that's crappy, and undermines
some of the goodness of the Web...  It seems to me that, like generic
interfaces, the separation of naming and "routing" and client-local control
of all interactions are essential features of the Web.  I need to think more
about it, though, if I'm going to make a more compelling argument than
analogy to bang paths.

Now, having said that, I'm *all for* composition.  IMO, tho, compositional
metaphors need to leave the request originator in control of the whole
end-to-end interaction.  I think this is essential for loose coupling,
independent development, etc.  All the stuff we've come to know and love.

Or, if intermediaries are to control interaction, they should have *full*
control of the interaction and this should be invisible to clients.  I've
long wanted a mechanism by which the owner of, say, foo.com could "mount up"
remote pieces of URI address space in his own space, ala:

http://foo.com/
  bar/ --> http://bar.com
  baz/ --> http://baz.com

Further, if foo.com provided an interface by which bar.com and baz.com could
"register" themselves in foo.com's space, then you'd have some enabling
technology that could help solve many problems, namely the "publish from
behind the firewall" problem.  Cf. old rants about "SUDS," etc.

$0.02,

Jb







-----------------------------------------------------------------------------------
Post ID:1626
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-21 04:41:13
Subject:Re: [rest-discuss] HTTP and Routing
Message:

Jeff Bone wrote:
> 
> On 6/20/02 10:13 PM, "Mark Baker" <distobj@...> wrote:
> 
> >
> > The implementation was crappy, but the theory was good.  I'm with Rohit
> > on this.  I think you'll see bang paths again.
> 
> Would somebody mind providing a pointer to Rohit's utterances on this?  

http://www.ics.uci.edu/~rohit/ETcon-SOAProuting.ppt

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1627
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-06-21 08:52:39
Subject:Re: [rest-discuss] REST and travel agents revisited
Message:

I was just re-visiting this and I had a question:

At 05:45 PM 1/06/2002, S. Mike Dierken wrote:

>Here's how I would do it:....
>
>== Create a new trip ===
>POST http://services.travelagents.com/trips/ HTTP/1.1....
>
>== Acknowledgement of submission (with location of trip) ==
>HTTP/1.1 202 Accepted
>Location: http://services.travelagents.com/trips/0173/

Why use 202 Accepted and not 201 Created ? 
RFC2616 says of a 202 - "The request has been accepted for processing, but the 
processing has not been completed.  The request might or might not 
eventually be acted upon...The entity returned with this response SHOULD 
include an indication of the request's current status and either a pointer 
to a status monitor or some estimate of when the user can expect the request 
to be fulfilled."

If you do use 202, should the returned location should be something like 
http://services.travelagents.com/status/0173/ or 
http://services.travelagents.com/trips/0173/status/ ? 
Is it acceptable to return the actual location of the trip as you have done 
and then have the representation at that URI initially be a status saying 
'processing x% complete' and then when processing is completed the 
representation changes to be the actual trip? 
Given that this is REST then a URI is a representation of the current state 
of a resource, so it sounds reasonable that if the current state IS 'x% 
complete'  then it is reasonable to return THAT as a representation, does it not?

Robert







-----------------------------------------------------------------------------------
Post ID:1628
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-06-21 13:28:55
Subject:etags and state
Message:

I'm thinking of using a scheme prompted by something S. Mike Dierken said 
regarding using etags and "if-none-match" headers. The scheme is as follows:

1. Allow subscriptions to a resource http://foo.com/bar
2. When bar changes, publish notifications to all the subscriber containing 
the link to bar or the diff, etc and an entity tag to be used to identify 
bar at that particular instance of time (i.e. the state of bar when the 
notification was sent).
3. If a subscriber is only interested when bar is in that particular state 
(think along the lines of a lock on bar as suggested by Mike) it uses the 
etag and an "if-match" header to ensure that a GET is only successful if bar 
is still in the required state (e.g. if bar is not locked).

Does this sound like a reasonable strategy? The reason I ask is that it 
makes me feel uneasy that the client has to know that the etag is overloaded 
to represent state and whether to use it or not.

Robert







-----------------------------------------------------------------------------------
Post ID:1629
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-06-21 15:21:48
Subject:"Correlation" - kludge to make up for hiding resources?
Message:

I'm seeing more symptoms on the part of message-oriented Web services 
that hide their actual resources behind a single service access point 
and a dispatcher, that now they need to construct elaborate 
mechanisms for addressing those hidden resources.  The popular name 
for these mechanisms seems to be "correlation".  I think the name was 
coined by MSFT, but now seems to be taken up by SUN.

Doesn't this smell like a kludge?

Here we have a proposal for adding something called "Correlation" to 
ebXML Business Process Specs:
http://lists.ebtwg.org/archives/ebtwg-bps/200206/msg00035.html

Excerpt:
"The purpose of the project is to formalize the semantics that allows 
two BPSS users to unambiguously carry out multiple instances of the 
same ... collaboration [script] with each other. Correlation is an 
acknowledged concept within message based collaborations, and BPSS 
does not currently have the capability to specify correlation. In the 
absence of such capability the partners are left to either operate 
ambiguously (and therefore inefficiently), or to devise their own way 
of agreeing on the correlation rules."

MSFT XLang has something similar, I quote:
"11. Correlation and Port References

We have so far maintained the illusion that the target for the 
delivery of messages between XLANG services is just the WSDL port of 
the recipient service. The reason this is an illusion is that by 
their very nature, stateful services are instantiated in order to act 
in accordance with the history of an extended interaction. Therefore, 
messages sent to such services need to be delivered not only to the 
correct destination port, but to the correct instance of the service 
that defines the port. The infrastructure hosting the service needs 
to be able to do this in a fairly generic manner, so as to avoid 
burdening every service implementation with the need to implement a 
custom mechanism for instance routing.

"Consider the usual supply chain situation where a buyer sends a 
purchase order to the seller. Let us suppose that the buyer and 
seller have a stable business relationship and are statically 
configured to send documents related to the purchasing interaction to 
the URLs associated with the relevant WSDL ports. The seller needs to 
return an acknowledgement for the order, and the acknowledgement must 
be routed to the correct service instance at the buyer. The obvious 
and standard mechanism to do this is to carry a token or "cookie" in 
the order message that is copied into the acknowledgement for 
correlation."

I mean, if the purchase order is a Web resource with a URI, can't you 
just address it directly?  And if you can directly address the 
resource you are trying to hit, would you ever need something 
like "correlation"?  Am I missing something here?


[Aside: if you can't do conversations RESTfully, or if there is some 
reason that you want to hide the actual resources being addressed, 
then you need Correlation.  But of course I'm assuming here that you 
can and you don't.]

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1630
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-06-21 16:32:55
Subject:App-level Routing
Message:

On 6/20/02 11:41 PM, "Paul Prescod" <paul@...> wrote:

> http://www.ics.uci.edu/~rohit/ETcon-SOAProuting.ppt

Thanks, Paul.

Having now had an opportunity to parse through this presentation, it appears
to me that this is consistent with Rohit's (any my own) long-time advocacy
of app-level routing in general, not specifically or just Henrik's
path-based addressing proposal.  I've pinged Rohit to confirm this, will
report back with his response.  (I.e., there's a big difference between the
kind of "routing" that e.g. KN does and Henrik's path-based addressing
proposal.)

It's important to understand that there are many and different possible
formulations of app-level routing in general and HTTP routing in particular,
and that the latter does not imply or require path-based addressing and
route transparency on the client.  Further, there are many other potential
compositional metaphors, declarative and otherwise, that do not imply or
require "routing" in any meaningful sense.  Considering only traditional
"synchronous" HTTP, some of the alternatives (non-exclusive) are:

Proxying
--------

The standard proxy scheme can be considered a form of routing, indeed a
truly static form.  While clients must have explicit knowledge of the first
proxy in the chain, the proxy is otherwise transparent and their is no
impact on the addressing scheme.


Path-based addressing
---------------------

Path-based addressing is the "bang path" style we've been discussing;  the
client explicitly specifies a series of intermediaries by embedding the path
in an address (URI) construction.  This is both inflexible and problematic,
particularly when considering the issues of crossing administrative domains.
Note that this *REQUIRES* URI construction and is a form of "generative
naming," therefore violating the Axiom of Opacity.  (For what that's worth.)
On the upside, its implementation is trivial:  it is merely a form of
proxying where the proxy chain is explicitly specified in the URI.


Destination-based addressing
----------------------------

The alternative to path-based addressing to drive routing decisions is using
the destination address and assuming some underlying machinery to resolve
the address route the message.  HTTP currently employs this sort of scheme;
the underlying machinery is DNS and the assumption, modulo "static" routes
through transparent proxy chains, is direct connection between client and
server.


3xx + Topology
--------------

Another possible routing scheme arranges servers in a graph topology such as
a Plaxton mesh, and distributes partial information (e.g. Bloom filters on
per-server object hash tables) about contents across the topology to be used
in routing decisions.  A client is "routed" across the graph by means of 3xx
redirect from each intermediate server acting on their partial routing
information.


Namespace Composition
---------------------

Namespace composition can be considered a form of proxying where the client
has no idea that proxies are involved.  In this scenario, some server A
"mounts" a portion of server B's namespace into A's own namespace.  Requests
to A for objects in that portion of its namespace are --- transparently to
the client --- proxied to B, with reponses (possibly filtered or
transformed) flowing back through A to the client.


These are just a few of the possibilities.  When you introduce asynchrony,
the possibilities get even richer.  My $0.02:  let's not jump to the
conclusion that SOAP routing == "SOAP Routing" / "WS-ROUTING" in the Henrik
et. al. sense, or that routing HTTP requires path-based addressing...

Jb







-----------------------------------------------------------------------------------
Post ID:1631
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-21 17:06:10
Subject:Re: App-level Routing
Message:

Yup, agree 100%.  FWIW, we have some words on this on our web site;

http://www.idokorro.com/routing.html

We have another type since that was written last year; reverse static
and dynamic routing, like WS-Refer(?), and HTTP 305 response code.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1632
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-21 17:04:57
Subject:Re: App-level Routing
Message:

Jeff Bone wrote:
> 
> On 6/20/02 11:41 PM, "Paul Prescod" <paul@...> wrote:
> 
> > http://www.ics.uci.edu/~rohit/ETcon-SOAProuting.ppt
> 
> Thanks, Paul.
> 
> Having now had an opportunity to parse through this presentation, it appears
> to me that this is consistent with Rohit's (any my own) long-time advocacy
> of app-level routing in general, not specifically or just Henrik's
> path-based addressing proposal.  

Sure, that doesn't mean that he disavows Henrik's proposal, which I
presume came out of work the two of them did together. Path-based
routing is the version that takes the most new syntax so it is what I
had trouble envisioning as part of REST. I already know how the other
stuff (proxies, namespace remapping, redirection, etc.) work.

>...
> These are just a few of the possibilities.  When you introduce asynchrony,
> the possibilities get even richer.  My $0.02:  let's not jump to the
> conclusion that SOAP routing == "SOAP Routing" / "WS-ROUTING" in the Henrik
> et. al. sense, or that routing HTTP requires path-based addressing...

It isn't a quesion of whether "routing HTTP requires path-based
addressing." It doesn't. It's a question of whether there are problems
that require routing where the client specifies the list of nodes in
advance and then waits for the completion of hte action. If so, what is
the syntax for supporting that.

If Rohit is not enamored of WS-Routing then I don't know what he sees in
SOAP at all.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1633
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-06-21 17:34:50
Subject:Re: [rest-discuss] Re: App-level Routing
Message:

On 6/21/02 12:04 PM, "Paul Prescod" <paul@...> wrote:

> It isn't a quesion of whether "routing HTTP requires path-based
> addressing." It doesn't. It's a question of whether there are problems
> that require routing where the client specifies the list of nodes in
> advance and then waits for the completion of hte action. If so, what is
> the syntax for supporting that.

Note that "client specifies list of nodes [to process intermediate states of
some request]" doesn't imply or require path-based addressing, or indeed any
URI syntactic solution.  PBA has this insidious problem:  the client
specifies A/B/C and hands off to A, counting on A to hand B/C to B, and
counting on B to handoff to C, and counting on the reverse.  That is
different from" "client calls A, gets representation Ra.  Client calls B
with representation Ra, getting representation Rb.  Client calls C with
representation Rb, getting representation Rc."  It's not necessary for any
"intermediary" to know about or interact with any of the others, and if you
want a way to declaratively specify or refer to such a sequence of handoffs,
invent and XML dialect for it.  (In fact, IIRC, this is what XML Pipes etc.
do, more or less.)  Don't overload URIs with operational semantics.

Note that the first, in addition to the problems already mentioned an in
addition to introducing new syntax *and* semantics, also means that there
are now not one but *two* types of HTTP URI addressible resources:  the
traditional kind *and* an "addressable proxy" type.  Lots of new complexity,
and for what purpose?

There's nothing you can do with the former that you can't do with the latter
--- lots of costs with the former and no clear benefits in the synchronous
case.  In the async / Henrik sense, it's a different story and a different
argument, but with the same conclusion IMHO.

> 
> If Rohit is not enamored of WS-Routing then I don't know what he sees in
> SOAP at all.

I dunno.  A nice envelope?

Jb







-----------------------------------------------------------------------------------
Post ID:1634
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-21 17:47:15
Subject:Re: [rest-discuss] Re: App-level Routing
Message:

Jeff Bone wrote:
> 
> On 6/21/02 12:04 PM, "Paul Prescod" <paul@...> wrote:
> 
> > It isn't a quesion of whether "routing HTTP requires path-based
> > addressing." It doesn't. It's a question of whether there are problems
> > that require routing where the client specifies the list of nodes in
> > advance and then waits for the completion of hte action. If so, what is
> > the syntax for supporting that.
> 
> Note that "client specifies list of nodes [to process intermediate states of
> some request]" doesn't imply or require path-based addressing, or indeed any
> URI syntactic solution.  

That's why I finished the sentence. By the way, chained URI-syntax was
just one possible solution. As Mark said, he uses XML-based routing.

> ... PBA has this insidious problem:  the client
> specifies A/B/C and hands off to A, counting on A to hand B/C to B, and
> counting on B to handoff to C, and counting on the reverse.  That is
> different from" "client calls A, gets representation Ra.  Client calls B
> with representation Ra, getting representation Rb.  Client calls C with
> representation Rb, getting representation Rc."  It's not necessary for any
> "intermediary" to know about or interact with any of the others, and if you
> want a way to declaratively specify or refer to such a sequence of handoffs,
> invent and XML dialect for it.  (In fact, IIRC, this is what XML Pipes etc.
> do, more or less.)  Don't overload URIs with operational semantics.

I think that this issue of operational semantics is a red herring. Do
you agree that a site could offer a service like this:

http://www.math.com/sum?x=5&y=9

It returns 11. How could it then be wrong to have something like

http://www.math2.com/power?x=5&y=http://www.math.com/sum?x=2+y=7

As soon as you open the door to "generative" URIs (which we agree is
necessary sometimes), it becomes clear that a reference to another
resource is a valid input to the first resource. If I express this in
XPipe or something, I have a declarative form the result but I don't
have a *globally accessible URI* for the result unless I can write the
XPipe to some file somewhere.

> Note that the first, in addition to the problems already mentioned an in
> addition to introducing new syntax *and* semantics, also means that there
> are now not one but *two* types of HTTP URI addressible resources:  the
> traditional kind *and* an "addressable proxy" type.  Lots of new complexity,
> and for what purpose?

No extra complexity. It follows as naturally as:

a * b

a * (b + c)

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1635
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-06-21 18:02:14
Subject:Re: [rest-discuss] Re: App-level Routing
Message:

On 6/21/02 12:47 PM, "Paul Prescod" <paul@...> wrote:

> I think that this issue of operational semantics is a red herring.

Nope, it's the meat of the matter.

> Do you agree that a site could offer a service like this:
> 
> http://www.math.com/sum?x=5&y=9
> 
> It returns 11. How could it then be wrong to have something like
> 
> http://www.math2.com/power?x=5&y=http://www.math.com/sum?x=2+y=7

Nothing wrong with that at all, as long as (a) math2 explicitly tells the
client how to construct that URI, and (b) the client assumes nothing more
about URI construction than what math2 tells it.
> 
> As soon as you open the door to "generative" URIs (which we agree is
> necessary sometimes),

Wow, that's new --- I thought we disagreed about that. :-)

> it becomes clear that a reference to another
> resource is a valid input to the first resource. If I express this in
> XPipe or something, I have a declarative form the result but I don't
> have a *globally accessible URI* for the result unless I can write the
> XPipe to some file somewhere.
> 

We're *almost* in agreement.  The subtle but important point that I'd like
to call attention to is the fact that

http://www.math2.com/power?x=5&y=http://www.math.com/sum?x=2+y=7

...means whatever www.math2.com states / wants it to mean, whereas the
"dangerous" proposal is to assume that it's "safe" to do:

http://www.math2.com/power?x=5&y=GET&GET=http://www.math.com/sum?x=2+y=7

...(or invent your own syntax) and have the client assuming that math2 is
going to do the right thing.  I.e., you really don't want to open the door
to embedding arbitrary URIs in the query strings of other URIs and assume
that the receipient is going to do the right thing.

> 
> No extra complexity. It follows as naturally as:
> 
> a * b
> 
> a * (b + c)
>

Well, there's your problem...  (* a b), (* a (+ b c))

;-)

Jb








-----------------------------------------------------------------------------------
Post ID:1636
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-21 18:43:05
Subject:Re: [rest-discuss] Re: App-level Routing
Message:

Jeff Bone wrote:
> 
>...
> 
> Nothing wrong with that at all, as long as (a) math2 explicitly tells the
> client how to construct that URI, and (b) the client assumes nothing more
> about URI construction than what math2 tells it.

Fine.

> > As soon as you open the door to "generative" URIs (which we agree is
> > necessary sometimes),
> 
> Wow, that's new --- I thought we disagreed about that. :-)

Nope, we disagreed on whether it was sufficient to use "?" for
generative URIs or whether the all sorts of URIs should be up for
"generation".

>...I.e., you really don't want to open the door
> to embedding arbitrary URIs in the query strings of other URIs and assume
> that the receipient is going to do the right thing.

Well, duh. ;) It won't work unless the server is set up to allow it to
work.

That's why I said in the first message of this thread that this is an
*application level* convention (negotiated between applications). But
clearly I wasn't clear. Mark didn't understand either. He responded
"there is no standard way to do this" which to me is the same as saying
it must negotiated at the application level. I'll try to be more
explicit next time.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1637
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-21 19:10:46
Subject:XML's "Big Idea" and how it relates to REST
Message:

Consider this argument about how "documente-oriented web services" are
better than RPC interfaces (after the stuff about UDDI). If you look
closely I think you'll see an inadvertent argument for REST in there....

-------- Original Message --------
Subject: RE: [e-lang] web services taking off
Date: Fri, 21 Jun 2002 11:37:57 -0700
From: "Karp, Alan" <alan_karp@...>
Reply-To: e-lang@...-os.org
To: "'e-lang@...-os.org'" <e-lang@...-os.org>

Paul Prescod wrote:
> 
> In case you'll be working on UDDI version 3, 

Thankfully, no.

> I hope you'll look at my
> critique of UDDI here: 
> 
>  * http://www.xml.com/pub/a/2002/02/06/rest.html?page=2
> 
> That's not all I have to say about UDDI but its a start.

The question of URI versus GUID came up in every meeting I attended. 
There were very good reasons for not using URIs, but I'd have to dredge
up my notes from 2 years ago since I can't recall the reasons now.

> 
> Okay, but this isn't really much more than you can do with 
> COM -- unless
> the discovery is better. Which so far it isn't but okay maybe it could
> be someday.
> 

The major difference between NOM (CORBA/DCOM/RMI) and DEM (XML based web
services) is that the former is designed to encapsulate data and the
latter is meant to expose it.  The object model gives me access to the
methods, not the data; the document model gives me access to the data,
not the methods.

Kevin Smathers described the difference very nicely.

  While you can probably think of an OO design more quickly than you can
  a distributed document design, (and I do agree that any good designer
  could do so), that view completely neglects what you are trying to get
  from a loosely coupled design.  Data/method encapsulation is what you
  are trying to avoid, not what you are trying to acheive.

  That is because you are trying to avoid making assumptions about how
your
  data is going to be used, and encapsulation is the means by which you 
  create those assumptions in the semantics of the methods that modify
the
  data.  Someone providing a MIDI object for example might give it a
method
  to load data from a stream, play the data to an instrument, and write
it 
  to disk.

  Since I don't own a General MIDI keyboard, I would really like to
translate
  instrument numbers before playing them on my keyboard.  With a
document
  format it is easy for me to use stream tools like 'sed' or 'perl' to 
  manipulate the data with minimal coding.  With data encapsulation I 
  wouldn't be able to actually get at the data except through the
methods
  that the original programmer provided.  If the programmer didn't
expect
  me to have to modify the Instrument set, then I can't do it.

  The rule of XML is that I can never even guess all of the uses to
which
  my data might be put.  Loosely coupled design is about showing data, 
  not data hiding.

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1141
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
 
_______________________________________________
e-lang mailing list
e-lang@...-os.org
http://www.eros-os.org/mailman/listinfo/e-lang






-----------------------------------------------------------------------------------
Post ID:1638
Sender:Joe Hsy <joe.hsy@...>
Post Date/Time:2002-06-21 20:16:13
Subject:RE: [rest-discuss] XML's "Big Idea" and how it relates to REST
Message:

-----Original Message-----
From: Paul Prescod [mailto:paul@...]

> Kevin Smathers described the difference very nicely.
> 
>   While you can probably think of an OO design more quickly than you can
>   a distributed document design, (and I do agree that any good designer
>   could do so), that view completely neglects what you are trying to get
>   from a loosely coupled design.  Data/method encapsulation is what you
>   are trying to avoid, not what you are trying to achieve.

I've always thought this this type of characterization of OO is rather
unfair.  Encapsulation can be both a good thing and a bad thing depending on
what you're encapsulating and the nature of the application.  REST uses
encapsulation to good use as well.  Per Roy's thesis chapter 5.2.1 (Data
Elements):

    REST therefore gains the separation of concerns of the client-server
style without
    the server scalability problem, allows information hiding through a
generic interface
    to enable encapsulation and evolution of services, and provides for a
diverse set
    of functionality through downloadable feature-engines.

I've never viewed OO as method oriented.  Objects are data as well as
associated methods.  Exposing data and methods appropriately are matters of
design (good designs expose the right set).  Exposing all the data all the
time isn't the point and isn't always a good idea.  Likewise, I still don't
understand why just because we are dealing with a super-scale distributed
system that we should not allowing *any* object methods to be exposed.

I think having an internet-scale OO system would be a very good thing and
would quite useful.  I've been trying to see if REST or some of the core
concepts of REST can be the basis of such an OO system and I still think it
can.  But, if we keep insisting REST as incompatible with OO, I guess it is
a hopeless cause.

//Joe

This email message, and any attachments to it, are for the sole use of the
intended recipients, and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or distribution of
this email message or its attachments is prohibited.  If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message. 






-----------------------------------------------------------------------------------
Post ID:1639
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-22 05:40:27
Subject:Re: [rest-discuss] REST and travel agents revisited
Message:

I'm not sure 202 Accepted really is the best way to do this.
I'm unclear whether HTTP status codes reflect the semantics of the business
document - 'add trip please' - or whether they are like a message queue -
'request added... you'll need to get the response later...'

My working assumptions are that the HTTP response codes should reflect the
business-level meaning.
If the business-level meaning is not currently available - and there is no
business level content-type indicating this, then I'd bump it down into the
response code.

But this is not a one-size-fits-all solution & needs to be put to practice
to determine whether it is a workable solution or not.

----- Original Message -----
From: "Robert Leftwich" <robert@...>
To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com>
Sent: Friday, June 21, 2002 1:52 AM
Subject: Re: [rest-discuss] REST and travel agents revisited


> I was just re-visiting this and I had a question:
>
> At 05:45 PM 1/06/2002, S. Mike Dierken wrote:
>
> >Here's how I would do it:....
> >
> >== Create a new trip ===
> >POST http://services.travelagents.com/trips/ HTTP/1.1....
> >
> >== Acknowledgement of submission (with location of trip) ==
> >HTTP/1.1 202 Accepted
> >Location: http://services.travelagents.com/trips/0173/
>
> Why use 202 Accepted and not 201 Created ?
> RFC2616 says of a 202 - "The request has been accepted for processing, but
the
> processing has not been completed.  The request might or might not
> eventually be acted upon...The entity returned with this response SHOULD
> include an indication of the request's current status and either a pointer
> to a status monitor or some estimate of when the user can expect the
request
> to be fulfilled."
>
> If you do use 202, should the returned location should be something like
> http://services.travelagents.com/status/0173/ or
> http://services.travelagents.com/trips/0173/status/ ?
> Is it acceptable to return the actual location of the trip as you have
done
> and then have the representation at that URI initially be a status saying
> 'processing x% complete' and then when processing is completed the
> representation changes to be the actual trip?
> Given that this is REST then a URI is a representation of the current
state
> of a resource, so it sounds reasonable that if the current state IS 'x%
> complete'  then it is reasonable to return THAT as a representation, does
it not?
>
> Robert
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>






-----------------------------------------------------------------------------------
Post ID:1640
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-22 05:45:02
Subject:Re: [rest-discuss] Re: App-level Routing
Message:

> 
> If Rohit is not enamored of WS-Routing then I don't know what he sees in
> SOAP at all.

Money?







-----------------------------------------------------------------------------------
Post ID:1641
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-23 10:47:05
Subject:RE: [rest-discuss] REST and travel agents revisited
Message:

Mike, Robert,

I would think that the simplest approach to this example (and ones like it)
would be to have the response be at the semantic scope of the protocol, not at
the semantic scope of any kind of business requirement.  It will follow the REST
philosophy better if 201 or 202 means created or accepted *at the
resource/representation level* and nothing more.

Given the example we're discussing here [1], the first POST is sending a
representation of a new trip that is to be subordinate to the 'trip' resource ,
and up to the server to process accordingly.  If generically (in the REST sense)
a subordinate resource was created, then 201 seems most appropriate.  202 would
be more appropriate if the subordinate resource was accepted by the server, but
not created at the time the response was sent to the user agent.

Is that a clear way of seeing it?

-Philip

[1] http://conveyor.com/RESTwiki/moin.cgi/RestGoesToMaui for people new to this
discussion.

-----Original Message-----
From: S. Mike Dierken [mailto:mdierken@...]
Sent: Saturday, June 22, 2002 1:40 AM
To: rest-discuss@yahoogroups.com; Robert Leftwich
Subject: Re: [rest-discuss] REST and travel agents revisited


I'm not sure 202 Accepted really is the best way to do this.
I'm unclear whether HTTP status codes reflect the semantics of the business
document - 'add trip please' - or whether they are like a message queue -
'request added... you'll need to get the response later...'

My working assumptions are that the HTTP response codes should reflect the
business-level meaning.
If the business-level meaning is not currently available - and there is no
business level content-type indicating this, then I'd bump it down into the
response code.

But this is not a one-size-fits-all solution & needs to be put to practice
to determine whether it is a workable solution or not.

----- Original Message -----
From: "Robert Leftwich" <robert@...>
To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com>
Sent: Friday, June 21, 2002 1:52 AM
Subject: Re: [rest-discuss] REST and travel agents revisited


> I was just re-visiting this and I had a question:
>
> At 05:45 PM 1/06/2002, S. Mike Dierken wrote:
>
> >Here's how I would do it:....
> >
> >== Create a new trip ===
> >POST http://services.travelagents.com/trips/ HTTP/1.1....
> >
> >== Acknowledgement of submission (with location of trip) ==
> >HTTP/1.1 202 Accepted
> >Location: http://services.travelagents.com/trips/0173/
>
> Why use 202 Accepted and not 201 Created ?
> RFC2616 says of a 202 - "The request has been accepted for processing, but
the
> processing has not been completed.  The request might or might not
> eventually be acted upon...The entity returned with this response SHOULD
> include an indication of the request's current status and either a pointer
> to a status monitor or some estimate of when the user can expect the
request
> to be fulfilled."
>
> If you do use 202, should the returned location should be something like
> http://services.travelagents.com/status/0173/ or
> http://services.travelagents.com/trips/0173/status/ ?
> Is it acceptable to return the actual location of the trip as you have
done
> and then have the representation at that URI initially be a status saying
> 'processing x% complete' and then when processing is completed the
> representation changes to be the actual trip?
> Given that this is REST then a URI is a representation of the current
state
> of a resource, so it sounds reasonable that if the current state IS 'x%
> complete'  then it is reasonable to return THAT as a representation, does
it not?
>
> Robert
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

Yahoo! Groups Sponsor
ADVERTISEMENT




To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.







-----------------------------------------------------------------------------------
Post ID:1642
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-23 11:02:06
Subject:RE: [rest-discuss] REST and travel agents revisited
Message:

Mike, Robert,

I think we should keep it at the semantic scope of the REST style, not cast it
at the semantic scope of any kind of business domain.  So 201 or 202 should
indicate status relating to the resource/represtation that was created or
accepted, and nothing more.

Specfically, in the example [1], the user agent is POSTing a 'new trip'
representation that will be subordinate to the 'trips' resource located at node
'services.travelagents.com'.  What the origin server does while processing the
'new trip' representation is none of the user agent's business, above and beyond
whether the subordinate resource was created or accepted by the superordinate
resource.

(If I'm representing (pun intended) this right, the exact details of what
'create' and/or 'accept' mean is something that, at this level, is only known by
the origin server.)

Now, if the subordinate resource was created, then I would think a 201 should be
returned, and the Location header field should contain the URI of newly created
resource.

Thoughts?

-Philip

[1] For people new to this discussion:
http://conveyor.com/RESTwiki/moin.cgi/RestGoesToMaui

-----Original Message-----
From: S. Mike Dierken [mailto:mdierken@...]
Sent: Saturday, June 22, 2002 1:40 AM
To: rest-discuss@yahoogroups.com; Robert Leftwich
Subject: Re: [rest-discuss] REST and travel agents revisited


I'm not sure 202 Accepted really is the best way to do this.
I'm unclear whether HTTP status codes reflect the semantics of the business
document - 'add trip please' - or whether they are like a message queue -
'request added... you'll need to get the response later...'

My working assumptions are that the HTTP response codes should reflect the
business-level meaning.
If the business-level meaning is not currently available - and there is no
business level content-type indicating this, then I'd bump it down into the
response code.

But this is not a one-size-fits-all solution & needs to be put to practice
to determine whether it is a workable solution or not.

----- Original Message -----
From: "Robert Leftwich" <robert@...>
To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com>
Sent: Friday, June 21, 2002 1:52 AM
Subject: Re: [rest-discuss] REST and travel agents revisited


> I was just re-visiting this and I had a question:
>
> At 05:45 PM 1/06/2002, S. Mike Dierken wrote:
>
> >Here's how I would do it:....
> >
> >== Create a new trip ===
> >POST http://services.travelagents.com/trips/ HTTP/1.1....
> >
> >== Acknowledgement of submission (with location of trip) ==
> >HTTP/1.1 202 Accepted
> >Location: http://services.travelagents.com/trips/0173/
>
> Why use 202 Accepted and not 201 Created ?
> RFC2616 says of a 202 - "The request has been accepted for processing, but
the
> processing has not been completed.  The request might or might not
> eventually be acted upon...The entity returned with this response SHOULD
> include an indication of the request's current status and either a pointer
> to a status monitor or some estimate of when the user can expect the
request
> to be fulfilled."
>
> If you do use 202, should the returned location should be something like
> http://services.travelagents.com/status/0173/ or
> http://services.travelagents.com/trips/0173/status/ ?
> Is it acceptable to return the actual location of the trip as you have
done
> and then have the representation at that URI initially be a status saying
> 'processing x% complete' and then when processing is completed the
> representation changes to be the actual trip?
> Given that this is REST then a URI is a representation of the current
state
> of a resource, so it sounds reasonable that if the current state IS 'x%
> complete'  then it is reasonable to return THAT as a representation, does
it not?
>
> Robert







-----------------------------------------------------------------------------------
Post ID:1643
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-24 16:32:12
Subject:Re: [rest-discuss] "Correlation" - kludge to make up for hiding resources?
Message:

On Fri, Jun 21, 2002 at 11:21:48AM -0400, bhaugen32 wrote:
> Doesn't this smell like a kludge?

Most definitely.  In the WSAWG, WS-Inspection was recently discussed;
it's another complete kludge, attempting to solve the bootstrapping
problem when you haven't agreed to any application semantic a priori
(but of course, it only lets you find out what you have no possibility
of discovering for yourself - the methods in the WSDL - unless you
already expected it).

FWIW, my rule of thumb for Web services specs is, if Henrik's name is
on it, it's good, otherwise it's crap.  So far, that's held up every
time I've applied it. 8-)

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1644
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-25 15:20:15
Subject:Re: [rest-discuss] Open Archives Initiative Releases Version 2.0 of the Protocol for Metadata Harvesting (fwd)
Message:

On Fri, Jun 14, 2002 at 06:43:58AM -0400, Dan Brickley wrote:
> REST folk should find this interesting, imho...

Yay, verbs in POST bodies *and* URIs.  Woohoo!

One of the "good" things about SOAP - or so I thought - was that it
would act as a magnet for everybody wanting to do RPC, permitting their
stuff to be nicely isolated from the rest of the Web (for later
extermination, of course 8-).

Let's hope that this practice of not using SOAP for all your RPC needs,
doesn't catch on. 8-)

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1645
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-25 21:17:32
Subject:Re: [rest-discuss] Open Archives Initiative Releases Version 2.0 of the Protocol for Metadata Harvesting (fwd)
Message:

Mark Baker wrote:
> 
> On Fri, Jun 14, 2002 at 06:43:58AM -0400, Dan Brickley wrote:
> > REST folk should find this interesting, imho...
> 
> Yay, verbs in POST bodies *and* URIs.  Woohoo!

I think that people who do this sort of thing are often trying to do the
right thing and just need a little direction. The REST world has not
provided sufficient direction yet so we can't really blame them.

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1646
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-26 01:27:38
Subject:Re: [rest-discuss] Open Archives Initiative Releases Version 2.0 of the Protocol for Metadata Harvesting (fwd)
Message:

On Tue, Jun 25, 2002 at 02:17:32PM -0700, Paul Prescod wrote:
> I think that people who do this sort of thing are often trying to do the
> right thing and just need a little direction. The REST world has not
> provided sufficient direction yet so we can't really blame them.

Oh, of course.  I'm just mocking them.  But FWIW, I'm sure Web services
folks are trying to do the right thing too, but that doesn't mean you'll
be met with open arms when you try to tell them how to do it properly
(especially if you phrase it that way 8-).

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1647
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-06-26 20:55:54
Subject:Book recommendations
Message:

The title says it all really - what is the list of books that no REST-er should be without?

Robert







-----------------------------------------------------------------------------------
Post ID:1648
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-06-27 06:56:07
Subject:Http Events spec
Message:

I was reading the Http Events spec (http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents) again and went looking on rest-discuss for clarification of the 'Watched-URI: (URI of the watched resource)' and 'Subscription-URI: URI of the subscription object ' notification message headers. I found the discussion starting at http://groups.yahoo.com/group/rest-discuss/message/704 which ends up with Paul suggesting the following changes, among others:

"A notification message MAY have the following headers: 

Watched-URI: (URI of the watched resource) 

The Watched-URI may be any valid URI for the resource that generated the
notification. It need not be the original URI but it must refer to the
same resource. If the client wants to retrieve a representation of the
resource it SHOULD use this URI, not the original one. This will allow
publishers to do a simple form of load balancing."

What is the status of these changes and is the 'Subscription-URI: URI of the subscription object '  the URI of the subscription resource returned as a 'Location' header in the subscription response?

Robert







-----------------------------------------------------------------------------------
Post ID:1649
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-27 10:44:05
Subject:Re: [rest-discuss] Http Events spec
Message:

Yes, those changes just never got added because I got busy with another
project. Please feel free to add them.

Robert Leftwich wrote:
> 
> I was reading the Http Events spec (http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents) again and went looking on rest-discuss for clarification of the 'Watched-URI: (URI of the watched resource)' and 'Subscription-URI: URI of the subscription object ' notification message headers. I found the discussion starting at http://groups.yahoo.com/group/rest-discuss/message/704 which ends up with Paul suggesting the following changes, among others:
> 
> "A notification message MAY have the following headers:
> 
> Watched-URI: (URI of the watched resource)
> 
> The Watched-URI may be any valid URI for the resource that generated the
> notification. It need not be the original URI but it must refer to the
> same resource. If the client wants to retrieve a representation of the
> resource it SHOULD use this URI, not the original one. This will allow
> publishers to do a simple form of load balancing."
> 
> What is the status of these changes and is the 'Subscription-URI: URI of the subscription object '  the URI of the subscription resource returned as a 'Location' header in the subscription response?
> 
> Robert
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/






-----------------------------------------------------------------------------------
Post ID:1650
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-06-27 17:54:18
Subject:Re: [rest-discuss] Re: App-level Routing
Message:

(sorry, had email troubles and just got this one)

On Sat, Jun 22, 2002 at 01:45:02AM -0400, S. Mike Dierken wrote:
> > 
> > If Rohit is not enamored of WS-Routing then I don't know what he sees
> in
> > SOAP at all.
> 
> Money?

Heh.  Well, WS-Routing is just a small piece of the bigger routing
picture with REST/ALIN.  For the kinds of things Rohit wants to do,
WS-Routing is mostly inappropriate.  But the other types of ad-hoc
routing (pub/sub, primarily) is what he's interested in (me too,
actually).

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1651
Sender:"rdilipk" <rdilipk@...>
Post Date/Time:2002-06-28 00:36:15
Subject:REST and idempotency
Message:

HI

I saw this[1] in one of the weblogs I constantly watch.  thought i'd 
post here...

--Dilip

[1] http://www.dotnetremoting.cc/DotNetCentric/2002/06/24.html#a222








-----------------------------------------------------------------------------------
Post ID:1652
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-06-28 04:18:47
Subject:Example of industry mag discussing correct usage of HTTP
Message:

Here's an example of industry mag discussing correct usage of HTTP GET .vs.
POST - but in the end is foiled by poor implementation.

This is from an XML/MS-SQL column.

--
http://www.ntsecurity.net/Articles/Index.cfm?ArticleID=19852

"[...] The method attribute's values on the form tag specify the HTTP verb
to use when you're sending the request to the Web server. You use the GET
verb for requests to the server that don't involve changes to data-or, more
generally, state-on the server. You use POST when data-or state-changes.
When you're performing database operations, you use GET when you're querying
data and POST when you're inserting, updating, or deleting data."

[...]
"SQL Server 2000's ISAPI DLL incorrectly interprets an HTML form that uses
method="POST" as posting a template or updategram. Instead, the ISAPI DLL
should allow this type of message if you've enabled the Allow template
queries setting. The best workaround is to use the GET method, although this
approach limits the amount of data that someone can post to the server to
the length of a URL (2083 characters if you're using Microsoft Internet
Explorer-IE-5.0). Another workaround is to use the Allow POST setting, but
you would need to make sure that you carefully controlled permissions on the
virtual root to ensure that a posted template couldn't damage your system.

Microsoft recently released XML for SQL Server 2000 Web Release 1, which
includes additional configuration options to the ISAPI DLL that fix this
bug. "







-----------------------------------------------------------------------------------
Post ID:1653
Sender:"oldieshome2002" <bill.oldroyd@...>
Post Date/Time:2002-06-28 10:45:52
Subject:Re: Open Archives Initiative Releases Version 2.0 of the Protocol for Me
Message:

--- In rest-discuss@y..., Mark Baker <distobj@a...> wrote:
 On Fri, Jun 14, 2002 at 06:43:58AM -0400, Dan Brickley wrote:
> REST folk should find this interesting, imho...
 
> Yay, verbs in POST bodies *and* URIs.  Woohoo!
 
Having a very peripheral involvement in developing this protocol, I
would welcome the group's help in proposing changes to make it more
REST like.

This paper , http://arxiv.org/abs/cs.DL/0205071 , indicates the
direction in which this protocol is heading. The establishment of a
separate architecture for proxies and caching doesn't seem to make
sense to me at all.

Bill Oldroyd
The British Library







-----------------------------------------------------------------------------------
Post ID:1654
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-06-28 11:46:28
Subject:Re: [rest-discuss] Book recommendations
Message:

Robert Leftwich wrote:
> 
> The title says it all really - what is the list of books that no REST-er should be without?

A good understanding of HTTP I think is important.  Here's a wonderful
book on HTTP:

HTTP Essentials, Protocols for Secure, Scalable Web Sites

You need some language to implement your Web services.  If you are using
Java then I highly recommend this book:

Inside Servlets, 2nd Edition by Dustin R. Calloway

/Roger







-----------------------------------------------------------------------------------
Post ID:1655
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-28 13:50:58
Subject:WebDAV or HTTP as foundation for REST
Message:

Let's imagine the perfect REST toolkit. Would it be built upon an HTTP
infrastructure or upon a WebDAV infrastructure? I do not know WebDAV as
well as I should or will. But I'm thinking that for instance it could be
useful for all REST applications to support WebDAV's notion of
collections so that you would get compatibility with WebDAV collection
management tools "for free". If a REST app has to do locking, it might
as well use WebDAV locking. If it has to do object versioning, it might
as well use WebDAV versioning.

Opinions?

Let's presume I'm right. If you were building a REST app today, is there
a good WebDAV toolkit out there that is especially designed to be really
easy to extend? Zope? 4Suite? Something in Java? mod_dav?

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1656
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-28 18:06:10
Subject:What would email look like if it were REST?
Message:

Some rough thoughts about a question I got from a client:

 * http://www.prescod.net/rest/restmail/

 Paul






-----------------------------------------------------------------------------------
Post ID:1657
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-06-28 19:01:29
Subject:Re: [rest-discuss] What would email look like if it were REST?
Message:

On 6/28/02 1:06 PM, "Paul Prescod" <paul@...> wrote:

> Some rough thoughts about a question I got from a client:
> 
> * http://www.prescod.net/rest/restmail/
> 
> 

Paul,

This is good stuff.  I've been thinking about this problem off and on for a
while (cf. Old FoRKposts, etc.) and am very much in line with your
suggestion.  Let me toss out a couple of additional ideas / extensions:

1.  Security

It's trivially possible to achieve a MUCH higher level of security and
authentication / authorization with this scheme than with existing mail
protocols.  A simple extension suffices:  the principal who sends a mail
cryptographically signs it;  this signature is attached both to the message
stashed in the outbox *and* to the notification that is sent to the
recipient's inbox.  The fetch operation performed by the recipient to fetch
the message is also signed.  Both parties verify the other's identities at
appropriate points in the process.

2.  Groups / Lists / List Archives

This scheme subsumes much of the functionality of today's newsgroups,
mailing lists, and list archives.  If you assume that multiple principals
may be associated with a given inbox, then that's all you need for the
latter;  a newsgroup is merely an inbox that's open to anybody.

3.  Retractable E-mail

It is possible to regard inboxes as caches of the contents of other parties'
outbox contents.  If to be the case, it becomes possible to consider the
ability of a sender to "retract" a message after it has been sent.  A sender
may mark a message as being non-cacheable;  it stays in his outbox as the
authoritative copy of the message no matter how many times the recipient
fetches it.  If the sender wishes to retract, he merely deletes it.  This of
course does not prevent any recipient from saving a persistent copy, but
well-behaved clients should honor caching hints.

4.  Principals

While not strictly necessary for any of the things discussed above, this
(like most collaborative communication schemes / tools) simply begs for the
definition of and integration with a reified notion of principal.  If we can
create a reasonable HTTP resource model for principals and their presence
information, many interesting things become possible:

  * Presence-enabled "smart" mail delivery and feedback
  * Subsumption of IM functionality
  * Tight end-user control over inbound communication

In general, a resource model for principals is useful in a huge variety of
contexts...  An application-neutral mechanism / model is something worthy of
consideration.

5.  Lifestreams-like Information Architecture / Management Metaphor

It's already the case that many people tend to "live out of their
mailboxes," i.e., use e-mail as both storage and organizational metaphor for
most important information.  Lifestreams and similar systems take this
notion to its logical conclusion, and in the process provides a pleasantly
simple yet powerful metaphor for personal information management.  In
addition, though not much has been said about this in the lit, IMO the
"addressable journal stream + views" model provides a general information
architecture that can be used to build loosely-coupled systems of
communicating agents / components.  The mail mechanism proposed above is
very close to something that could be used as the basis for the above.

Just some thoughts, cheers...

Jb







-----------------------------------------------------------------------------------
Post ID:1658
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-06-28 19:07:32
Subject:RE: [rest-discuss] WebDAV or HTTP as foundation for REST
Message:

Paul,

Personally, I've considered this issue.  My understanding is that it extends
HTTP, so I believe a good approach would be to build a REST toolkit based on
HTTP and layer an application framework on top of it that supplies WebDAV-based
authoring.  But like you, I have less knowledge about WebDAV than I do about
HTTP, and wish I had more.

Actually, Paul, I think I was with you at an XML conference done by DataChannel
in San Jose back in 1999.  We were in a WebDAV workshop, but I can't remember
who conducted it.  Jim Whitehead maybe?

-Philip

-----Original Message-----
From: Paul Prescod [mailto:paul@...]
Sent: Friday, June 28, 2002 9:51 AM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] WebDAV or HTTP as foundation for REST


Let's imagine the perfect REST toolkit. Would it be built upon an HTTP
infrastructure or upon a WebDAV infrastructure? I do not know WebDAV as
well as I should or will. But I'm thinking that for instance it could be
useful for all REST applications to support WebDAV's notion of
collections so that you would get compatibility with WebDAV collection
management tools "for free". If a REST app has to do locking, it might
as well use WebDAV locking. If it has to do object versioning, it might
as well use WebDAV versioning.

Opinions?

Let's presume I'm right. If you were building a REST app today, is there
a good WebDAV toolkit out there that is especially designed to be really
easy to extend? Zope? 4Suite? Something in Java? mod_dav?

Paul Prescod







-----------------------------------------------------------------------------------
Post ID:1659
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-28 19:17:10
Subject:Re: [rest-discuss] What would email look like if it were REST?
Message:

Thanks, excellent generalizations. I'll add those and credit you! Funny
how cool stuff just seems to fall out of REST designs. You try to
improve on an existing system by a little bit and you almost
accidentally improve upon it by a ton, just chasing the possibilities
offered by the fact that everything has a URI. The concept of "web
archives" of discussions would be quaint: the discussion *would be* its
own web archive!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1660
Sender:Lucas Gonze <lgonze@...>
Post Date/Time:2002-06-28 20:35:53
Subject:Re: [rest-discuss] What would email look like if it were REST?
Message:

Good stuff.

One comment -- Any HTTP event system that caches events for
pickup/deletion/etc will have almost exactly the same features.  So doing
a subscription protocol will have HTTP email as a side-effect and vice
versa.

What I mean is that you establish sessions, resource holders, etc.








-----------------------------------------------------------------------------------
Post ID:1661
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-29 02:24:38
Subject:Re: [rest-discuss] WebDAV or HTTP as foundation for REST
Message:

Philip Eskelin wrote:
> 
> Paul,
> 
> Personally, I've considered this issue.  My understanding is that it extends
> HTTP, so I believe a good approach would be to build a REST toolkit based on
> HTTP and layer an application framework on top of it that supplies WebDAV-based
> authoring.  

My point is that WebDAV seems more "reusable" than just for authoring
just as HTTP is more reusable than just for web pages.

> .... But like you, I have less knowledge about WebDAV than I do about
> HTTP, and wish I had more.

There should be a WebDAV tutorial or book.

> Actually, Paul, I think I was with you at an XML conference done by DataChannel
> in San Jose back in 1999.  We were in a WebDAV workshop, but I can't remember
> who conducted it.  Jim Whitehead maybe?

Yep, Jim. One of the points he made was that WebDAV is sort of the
uber-protocol and could replace FTP, many uses of NNTP, SMTP, etc. In
other words what I might call the "strong REST hypothesis". But I didn't
catch the significance then. I also recall that he was very suspicious
of XML RPC protocols and I was ambivalent back then.

Also, I just coincidentally read a message where he said:

"I think we would have created far more problems for ourselves if we had
tried to bite off the problem of creating a general-purpose remote
proceedure call marshalling syntax.  Since there are currently several
competing proposals in this space, and given their dependency on XML
efforts
to add data typing to XML, I think it was a wise decision to not base
our
efforts on these other efforts, since it allows us to finish before,
say,
the year 2002."

Another good prediction!

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1662
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-06-29 21:24:06
Subject:Re: [rest-discuss] Re: Open Archives Initiative Releases Version 2.0 of the Protocol for Me
Message:

oldieshome2002 wrote:
> 
>...
> 
> Having a very peripheral involvement in developing this protocol, I
> would welcome the group's help in proposing changes to make it more
> REST like.

I suspect that as at many other organizations, there would need to be a
kind of mindset change. The mindset which makes REST evangelism
difficult is that of "protocol independence." This is a sort of trendy
buzzword today. Unfortunately it is in competition with actually
achieving interoperability. REST concentrates first and foremost on
interoperability.

Nevertheless, if you want to understand what they did "wrong" from a
REST point of view, this list of "REST mistakes" might be a start: 

http://www.prescod.net/rest/mistakes

> This paper , http://arxiv.org/abs/cs.DL/0205071 , indicates the
> direction in which this protocol is heading. The establishment of a
> separate architecture for proxies and caching doesn't seem to make
> sense to me at all.

Agreed! If they did HTTP right they wouldn't need that! 

 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:1663
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-06-30 00:27:56
Subject:Re: [rest-discuss] WebDAV or HTTP as foundation for REST
Message:

At 11:50 PM 28/06/2002, Paul Prescod wrote:

>Let's presume I'm right. If you were building a REST app today, is there
>a good WebDAV toolkit out there that is especially designed to be really
>easy to extend? Zope? 4Suite? Something in Java? mod_dav?

I don't have any experience with it, but Apache's Slide project (http://jakarta.apache.org/slide/index.html) might be useful here. The front page says in part :

"Welcome to the Jakarta Slide project ! Slide is a project composed of multiple modules tied together using WebDAV (see below for more details about WebDAV). 
It includes : 
�       A content management system with a Java API 
�       A servlet implementing the WebDAV protocol on top of the content management system 
�       A Java WebDAV and HTTP client library 
�       A WebDAV command line client 
�       WebDAV enabled Swing components 

Main Features
 
  WebDAV Servlet
    �WebDAV Level 2 
    �DAV ACL support 
    �Delta V support 
    �DASL support 

  WebDAV Client Library
    �100% Pure Java 
    �HTTP/1.1 support 
    �Easy to use object model 
    �WebDAV Level 2 support 
    �DAV ACL support 
    �Delta V support 
    �DASL support"

Anyone know more about the WebDAV side of Slide?

Robert







-----------------------------------------------------------------------------------
Post ID:1664
Sender:Chris Croome <chris@...>
Post Date/Time:2002-06-30 20:43:37
Subject:Practical problems with HTTP Authentication
Message:

Hi

I think that using HTTP Authentication over cookies is more elegant
and is a good thing. However one of the guys I work with, who
actually gets to do the implementation, is bascially so fed up with
it that he is probably going to revert to using cookies -- has
anyone got any positive advice / argumnents in favour HTTP
Authentication that might convince him not to give up?

The details can be found on the mod_perl list:

  http://mathforum.org/epigone/modperl

These are the two threads concerned:

  http://mathforum.org/epigone/modperl/brumkraibix

  http://mathforum.org/epigone/modperl/lyrglazhoi

Chris 








-----------------------------------------------------------------------------------
Post ID:1665
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-02 03:46:35
Subject:Protocol hourglass
Message:

Interesting talk. He says that IP is the "waist" of the Internet. Many
protocols below it (Ethernet, ATM, PPP) many above it. But only one IP
(well, two with IPv6). What most REST people want is to have HTTP be the
"neck" -- the only protocol at its level. What do the IP level and the
HTTP level have in common? Addressing. You want universal protocols at
levels that do addressing so that any object can talk to any other
object.

http://www.iab.org/iab/DOCUMENTS/hourglass-london-ietf.pdf

---
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002,
conferences.oreillynet.com/os2002/
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1666
Sender:"Asynch Messaging" <asynch_messaging@...>
Post Date/Time:2002-07-02 04:10:05
Subject:HyperREST
Message:

Get yer gear here...

http://www.cafepress.com/cp/store/productdetail.aspx?prodno=rest.2592837








-----------------------------------------------------------------------------------
Post ID:1667
Sender:Mikael Andersson <mikael@...>
Post Date/Time:2002-07-02 16:33:50
Subject:Re: [rest-discuss] XML's "Big Idea" and how it relates to REST
Message:

Joe Hsy wrote:
> -----Original Message-----
> From: Paul Prescod [mailto:paul@...]
> 
> 
>>Kevin Smathers described the difference very nicely.
>>
>>  While you can probably think of an OO design more quickly than you can
>>  a distributed document design, (and I do agree that any good designer
>>  could do so), that view completely neglects what you are trying to get
>>  from a loosely coupled design.  Data/method encapsulation is what you
>>  are trying to avoid, not what you are trying to achieve.
> 
> 
> I've always thought this this type of characterization of OO is rather
> unfair.  Encapsulation can be both a good thing and a bad thing depending on
> what you're encapsulating and the nature of the application.  REST uses
> encapsulation to good use as well.  Per Roy's thesis chapter 5.2.1 (Data
> Elements):
> 
>     REST therefore gains the separation of concerns of the client-server
> style without
>     the server scalability problem, allows information hiding through a
> generic interface
>     to enable encapsulation and evolution of services, and provides for a
> diverse set
>     of functionality through downloadable feature-engines.
> 
> I've never viewed OO as method oriented.  Objects are data as well as
> associated methods.  Exposing data and methods appropriately are matters of
> design (good designs expose the right set).  Exposing all the data all the
> time isn't the point and isn't always a good idea.  Likewise, I still don't
> understand why just because we are dealing with a super-scale distributed
> system that we should not allowing *any* object methods to be exposed.
> 
> I think having an internet-scale OO system would be a very good thing and
> would quite useful.  I've been trying to see if REST or some of the core
> concepts of REST can be the basis of such an OO system and I still think it
> can.  But, if we keep insisting REST as incompatible with OO, I guess it is
> a hopeless cause.

Okay i'll have a go at this one :)

1) Object-Object interactions (semantics)
OO systems have interactions between object and the
semantic meaning of these methods is hard to encode in
a form that a machine can understand.

2) State and side effects
Does a call to getMethod() alter the state ?
Do i need to persist the Object after getMethod() to preserve the state ?
Should the Object device when to persist ? This isn't always what you want.
How far does the side effects of this method call reach ?
Will the call return in 0.01s or in 10days ?
Can ignore the answer ?

The problem doesn't lie in associating the operations with data as being
done in OO, but rather in the fact that the information is hidden so an application
cannot choose how to process the information itself.  Whoever builds the object
must anticipate the future uses for the system if it is to be scalable and
extensible.

If a Object representing an image is to be anything more than data.
It must encode operations. And as describing behaviour of methods is
very hard. Actually the method itself is the only _exact_ description we can get.

If we use methods and hide data we can only have one implementation of each method
if the system as a whole is to be reliable.And the behaviour must be exactly the
same regardless of where you use the Object/methods. So we need exact platform
independence for it to work. And still, in large scale distributed systems you
can easily get almost uncontrollable interactions when different parts of the
systems starts sending messages(method invocations) back and forth. These situations
aren't easily avoided.

But in a massively distributed system we must assume nodes in that system might be of
different kinds. Not all information processing units are created equal :)

A data structure is much easier to describe because it doesn't generate interactions
that may be sequence dependend. init(),release() and release(),init() can have wildly
different interaction patterns. So we can describe data in fever dimensions.
And this make it simpler.

Each node can implement it's own (or use some library) operations for whatever
data types it is interested in. The errors that may arise is more easily handled
because fewer (entirely unknown) interactions will occur. Formatting errors in
data is often quite easy to detect. So we can validate input to a higher degree.
We can not easily validate how a method works, mainly because of that we cannot
se the side effects (as all side effects are hidden
until we detect them)

What i think one should strive for in distributed systems is to avoid side effects
as much as possible.
This make the system much more robust against timing differences. It is even so that
the ordering of events is irrelevant if we have _no_ side-effects.

OO is almost _purely_ side-effects, you use methods to alter the state of an object.
And you never know how far these side effects reach. You are at the mercy of whoever
made that particular object. You never know the state of the object, it's lika
quantum-mechanics. Unless you look, you don't know what you have. And when you've
looked you still don't know :)

Comments and criticism are welcome ...

I will not attempt to describe the REST architecture, many has done it before me
and succeded well.


> 
> //Joe

/Mikael Andersson







-----------------------------------------------------------------------------------
Post ID:1668
Sender:Seth Johnson <seth.johnson@...>
Post Date/Time:2002-07-02 16:44:40
Subject:Re: [rest-discuss] Protocol hourglass
Message:

I think of REST as the set of principles that assure the
end-to-end principle at the HTTP protocol level.

Seth Johnson

Paul Prescod wrote:
> 
> Interesting talk. He says that IP is the "waist" of the Internet. Many
> protocols below it (Ethernet, ATM, PPP) many above it. But only one IP
> (well, two with IPv6). What most REST people want is to have HTTP be the
> "neck" -- the only protocol at its level. What do the IP level and the
> HTTP level have in common? Addressing. You want universal protocols at
> levels that do addressing so that any object can talk to any other
> object.
> 
> http://www.iab.org/iab/DOCUMENTS/hourglass-london-ietf.pdf

-- 

[CC] Counter-copyright:
http://cyber.law.harvard.edu/cc/cc.html







-----------------------------------------------------------------------------------
Post ID:1669
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-03 00:37:36
Subject:Re: [rest-discuss] XML's "Big Idea" and how it relates to REST
Message:

I think you've got some important ideas in there! REST (especially HTTP
GET) is about "give me the data and don't tell me what to do with it."
OOP is designed primarily to "tell you what to do with it" (to the
extent of rules like the law of Demeter that strongly council against
showing your hand)

 * http://www.ccs.neu.edu/home/lieber/LoD.html

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002,
conferences.oreillynet.com/os2002/
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1670
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-03 10:21:46
Subject:Re: [rest-discuss] XML's "Big Idea" and how it relates to REST
Message:

At 02:33 AM 3/07/2002, Mikael Andersson wrote:

>OO is almost _purely_ side-effects, you use methods to alter the state of an object.

How is this any different from a description of REST, you still use methods (albeit standardized HTTP methods) to alter the state of a resource, with the exception that GET allows side-effect free access? Refer to Mark Bakers 'An Abstract Model for HTTP Resource State' (http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model). 

>And you never know how far these side effects reach. You are at the mercy of whoever
>made that particular object. 

Why is this any different for a resource?

>You never know the state of the object, it's lika
>quantum-mechanics. Unless you look, you don't know what you have. And when you've
>looked you still don't know :)

This is where REST is advantageous, however, you can still only see a 'representation' of the state of the resource, i.e. you only see what the resource provider wants you to see, so you can never truly know the state of the resource?

Continuing on with the whole no side-effects approach, I'm having a hard time reconciling this notion, i.e. being purely functional (in the programming language sense) and being able to change the state of a resource via HTTP methods. Am I understanding what you mean when you say side-effect free and if so should we be looking more at FP rather than OOP for implementing REST-like systems?

Robert







-----------------------------------------------------------------------------------
Post ID:1671
Sender:Mikael Andersson <mikael@...>
Post Date/Time:2002-07-03 11:33:12
Subject:Re: [rest-discuss] XML's "Big Idea" and how it relates to REST
Message:

First i'd like to state this:
One can call (almost) any system 'OO' if you look har enough. In the same way as all systems
is procedureal to the core (as machinecode is procedural in some sense)

We must try to look at how different techniques is used. Not how they are specified.
Distributed systems is about realy more than about theory. People make mistakes.

Robert Leftwich wrote:
> At 02:33 AM 3/07/2002, Mikael Andersson wrote:
> 
> 
>>OO is almost _purely_ side-effects, you use methods to alter the state of an object.
> 
> 
> How is this any different from a description of REST, you still use methods 
 > (albeit standardized HTTP methods) to alter the state of a resource, with
 >  the exception that GET allows side-effect free access? Refer to Mark Bakers
 > 'An Abstract Model for HTTP Resource State' (http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model).
> 

GET,POST,PUT has very clear meanings (esp. as describe in that draft). Most OO systems
contain 1000's of methods with different semantics, and it's hard for a system to know
what they mean. And they cannot explore, for doing so may alter the state unpredictably.

Using GET you can (or you should be able to atleast...) explore quite freely. POST
otoh, may alter state.

> 
>>And you never know how far these side effects reach. You are at the mercy of whoever
>>made that particular object. 
> 
> 
> Why is this any different for a resource?
> 

When you have the 'object' (the page/whatever). The information in it will
not change until you request it again. If you act on a local(or remote) object
in a fullt distributed system, it may change.

I feel the wholeness of a resource is important. All that is guaranteed
in an OO system is that every object is consistent to it's own rules at all times.
And the object is the rules, so we don't know them.
But if i call one method, and then another. The result from the first and second
is subject to timing issues with other systems involved.

> 
>>You never know the state of the object, it's lika
>>quantum-mechanics. Unless you look, you don't know what you have. And when you've
>>looked you still don't know :)
> 
> 
> This is where REST is advantageous, however, you can still only see a 'representation' 
 > of the state of the resource, i.e. you only see what the resource provider wants you
 > to see, so you can never truly know the state of the resource?
> 

Matter is built by atoms whose state we cannot know. But on a macroscopic scale it's predictable.
But an atom here, won't affect something somewhere entirely different (sans entanglement, but
that's another story :) ).

But we get some view of the state in a format we can understand. In OO the view is composite. We must
call many methods to get a 'view'. And during that time we're at risk of timing issues.


> Continuing on with the whole no side-effects approach, I'm having a hard time 
 > reconciling this notion, i.e. being purely functional (in the programming language sense)
 > and being able to change the state of a resource via HTTP methods. Am I understanding what
 > you mean when you say side-effect free and if so should we be looking more at FP rather
 > than OOP for implementing REST-like systems?

I don't think we can be functional. But i think there is some important ideas there. A purely
functional  system can be executed in arbitrary order and yield the same result.
This behaviour would do wonders for any distributed system. But we should strive to reduce
the points where side effects can happen and also to reduce the impact they may have.

Being resilient to timing problems is very hard. And when doing something in a distributed
environment timing can be a nightmare.

Btw i'm not an expert of functional languages. What i know is what a friend has showed me which
is very good at these things and what i've read from a few sources. So don't think i can give
a very  deep insight on functional programming idioms and how it possibly relates to REST
like systems.

I have some more things on my mind here. But i'll try to keep myself from wandering to far
astray. As i have a tendency to do so. I easily get too philosophical :)

> 
> Robert
> 


/Mikael Andersson







-----------------------------------------------------------------------------------
Post ID:1672
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-04 00:18:53
Subject:RE: [rest-discuss] XML's "Big Idea" and how it relates to REST
Message:


> -----Original Message-----
> From: Mikael Andersson [mailto:mikael@xpedio.com]
> Sent: 03 July 2002 12:33
>
> First i'd like to state this:
> One can call (almost) any system 'OO' if you look har enough.

Here's a working guide to various definitions of OO: 

 <http://www.paulgraham.com/reesoo.html>

Bill de hra
..
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:1673
Sender:"Jack Gilbert"<ultimatehgh1000services@...>
Post Date/Time:2002-07-04 04:59:26
Subject:ressources.humaines,Introducing HGH: The Most Powerful Anti-Obesity Drug Ever
Message:

Hello, ressources.humaines@...

As seen on NBC, CBS, and CNN, and even Oprah! The health
discovery that actually reverses aging while burning fat,
without dieting or exercise! This proven discovery has even
been reported on by the New England Journal of Medicine.
Forget aging and dieting forever! And it's Guaranteed!


* Reduce body fat and build lean muscle WITHOUT EXERCISE!
* Enhace sexual performance
* Remove wrinkles and cellulite
* Lower blood pressure and improve cholesterol profile
* Improve sleep, vision and memory
* Restore hair color and growth
* Strengthen the immune system
* Increase energy and cardiac output
* Turn back your body's biological time clock 10-20 years
in 6 months of usage !!!

FOR FREE INFORMATION AND GET FREE 1 MONTH SUPPLY OF HGH CLICK HERE















You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here




-----------------------------------------------------------------------------------
Post ID:1674
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-04 19:03:06
Subject:Top dog
Message:

Mark Baker wrote in 
http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0042.html

> What's special about the application layer, 
> is that it is the "top dog".
> You can't layer on top of it and still call 
> yourself a valid use of that protocol.  
> You can only extend it.

How about the case we discussed previously about implementing the 
offer-acceptance business protocol in REST?

There is clearly something else going on that seems to be to 
be "above" the HTTP protocol.  As ISO says, you're not just 
exchanging data, you're making business commitments.

Rohit Khare had an interesting diagram in his recent Soap Routing 
slide show where he added two layers on top the application protocol:
Layer 8 - Economic (which is where business commitments cd go)
Layer 9 - Political.

What do you think?

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1675
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-04 20:04:41
Subject:Re: [PMX:#] [rest-discuss] Top dog
Message:

bhaugen32 wrote:
> 
> Mark Baker wrote in
> http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0042.html
> 
> > What's special about the application layer,
> > is that it is the "top dog".
> > You can't layer on top of it and still call
> > yourself a valid use of that protocol.
> > You can only extend it.
> 
> How about the case we discussed previously about implementing the
> offer-acceptance business protocol in REST?
> 
> There is clearly something else going on that seems to be to
> be "above" the HTTP protocol.  As ISO says, you're not just
> exchanging data, you're making business commitments.

There is something else going on, but it is an extension of HTTP. I
think of things like WebDAV and Offer/Acceptance as plugins. You should
be able to trivially build an application using a mix of WebDAV and
Offer/Acceptance at the same time. Individual resources should be able
to mix bits of WebDAV and Offer/Acceptance in the same message (if they
make logical sense together in a particular message). Whereas, HTTP and
SMTP are really layered on top of TCP so you can't have a single TCP
connection being both HTTP and SMTP at the same time. As usual, it is
impossible to say anything authoritative about how SOAP would fit in.
You can use it as a layer above HTTP (bad programmer!) or as an
extension to HTTP (but what does it add?) 

> Rohit Khare had an interesting diagram in his recent Soap Routing
> slide show where he added two layers on top the application protocol:
> Layer 8 - Economic (which is where business commitments cd go)
> Layer 9 - Political.

I was at the talk and in that context it was clear that he meant it more
as a joke. Not "economic protocols" like ebXML but "economic protocols"
like -- how do I con venture capitalists into giving me money?

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1676
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-04 21:34:07
Subject:Security, REST and resources
Message:

I'm currently looking at how a REST approach handles security and would
value some feedback. As has been described elsewhere the resource-centric
approach allows the use of existing ACL-based security - I'm interested in
the influence this has on the resource model. A concrete example, as always,
is a good thing....

Lets say our requirements for a medical system include the ability to attach
documents to a patient record e.g. specialists reports, police and social
workers investigations, etc. This is quite a natural thing for a REST-based
system to handle, with each of the documents being linked to from the main
patient record. Adding attachments would simply be a matter of a POST to the
patient record URI of an xml-structure containing the link to where the
document resides. A similar approach can be taken to change or delete the
link (i.e. PUT & DELETE). (Note that attachments are not identified as a
sub-resource in their own right as they are simply links and as such it is
not really necessary to expose them separately).

Now the security issues come into play. Suppose that for obvious reasons you
want to be able to restrict who can add, update or delete particular types 
of attachments.
Without having individual sub-resources for each of the types in question
there appears to be no way to setup this style of security using ACL. If you
do choose the sub-resources approach, what happens when your security
requirements change? Do you then have to change your resources to match?

Is there something I am missing in my understanding of the use of ACL in
REST, as this approach appears too fragile and inter-dependant for my liking?

Robert








-----------------------------------------------------------------------------------
Post ID:1677
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-05 00:05:25
Subject:Re: [xml-dev] ANN: Building Web Services the REST Way
Message:

Don Park wrote:
> 
>...
> 
> I can say the same about REST.  Web came about because everyone added to
> it.  Much of current focus on web services came about because Dave Winer
> evangelized XML-RPC and everyone started adding to it.

Really? What large-scale services depend on XML-RPC to the extent that
they do HTTP, FTP or SMTP? I don't think I have any mainstream software
using XML-RPC (or SOAP) on my computer at all.

> Unfortunately, I can't say the same about REST.  All I see is a few
> whitepapers describing an abstraction of HTTP protocol which does not
> address the full range of web service applications.  Where are the REST
> equivalent of WSDL, UDDI, and XKMS specs?  

Don, first you have to step back and ask whether WSDL, UDDI and XKMS are
good things. Then once you've decided that, it makes sense to ask for
equivalents. They aren't so there isn't. The issue should be a
no-brainer for UDDI. Who do you know who is using UDDI? For what? 

For WSDL, it is more subtle. Some days I think it might add to REST a
little bit, but most days it doesn't seem to add much. I don't see it as
a flaw of REST that it simplifies problems to the extent that WSDL
becomes marginally useful at best.

XKMS might be useful. I don't know anyone using XKMS so haven't had
reason to reinvent it as REST yet. It looks like it uses as little of
SOAP as possible.

> ... Where are the REST tools and
> libraries?  

J2EE and Expat are all you need for a "REST toolkit and library." I'm
sorry to be so anticlimatic but the basic REST tools have been deployed
for around eight years now. It's pretty hard to do better when the
industry has already spent a *billion dollars* on REST toolkits.

When Rael Dornfest wanted to build Meerkat he didn't go to Microsoft and
ask them for a toolkit. He just said: "XML + RSS + HTTP = great app".
The same goes for other REST apps like pkg_add in OpenBSD or Microsoft
Exchange Server or Outlook Express. If the fact that people will build
apps without making a big deal about it means REST is a "failure" then
you're right, maybe it is doomed to fail.

>...
> While it disturbs me to see complex SOAP messages bearing very little
> resemblance to the simple XML-RPC messages, I prefer SOAP over REST.

I'm curious, have you read the SOAP spec?

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1678
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-05 02:24:48
Subject:Re: [rest-discuss] Re: [xml-dev] ANN: Building Web Services the REST Way
Message:

At 10:05 AM 5/07/2002, Paul Prescod wrote:
>Don Park wrote:
> > ... Where are the REST tools and
> > libraries?
>
>J2EE and Expat are all you need for a "REST toolkit and library."

Are you serious?
J2EE has almost  the same level of complexity as SOAP and it
is a single vendor set of pseudo-standards (JCP not withstanding) that
*only* runs on that same vendors proprietary platform!

How much mainstream s/w do you have on your computer that uses J2EE?


Robert







-----------------------------------------------------------------------------------
Post ID:1679
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-05 04:08:54
Subject:Re: [rest-discuss] Re: [xml-dev] ANN: Building Web Servicesthe REST Way
Message:

Robert Leftwich wrote:
> 
>...
> >J2EE and Expat are all you need for a "REST toolkit and library."
> 
> Are you serious?
> J2EE has almost  the same level of complexity as SOAP and it
> is a single vendor set of pseudo-standards (JCP not withstanding) that
> *only* runs on that same vendors proprietary platform!

J2EE is a particular instance of a SOAP toolkit. Zope is another.
PHP/Apache is another. ASP/IIS is another. J2EE just has the most hype
right now so I mentioned it.

> How much mainstream s/w do you have on your computer that uses J2EE?

Well presumably a lot of HTTP software I have talks to J2EE servers. But
I have no particular attachment to that one toolkit.

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1680
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-05 04:36:55
Subject:Re: [rest-discuss] Re: [xml-dev] ANN: Building Web Servicesthe REST Way
Message:

At 02:08 PM 5/07/2002, Paul Prescod wrote:
>Robert Leftwich wrote:
> >
> >...
> > >J2EE and Expat are all you need for a "REST toolkit and library."
> >
> > Are you serious?
> > J2EE has almost  the same level of complexity as SOAP and it
> > is a single vendor set of pseudo-standards (JCP not withstanding) that
> > *only* runs on that same vendors proprietary platform!
>
>J2EE is a particular instance of a SOAP toolkit. Zope is another.
                                                                ^^^^^^
Was that a Freudian slip :-)

>PHP/Apache is another. ASP/IIS is another. J2EE just has the most hype
>right now so I mentioned it.

Given your history I guess I expected a bit more of a Python push :-)

Robert







-----------------------------------------------------------------------------------
Post ID:1681
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-05 05:43:55
Subject:Re: [rest-discuss] Re: [xml-dev] ANN: Building Web ServicestheREST Way
Message:

Robert Leftwich wrote:
> 
>...
> >
> >J2EE is a particular instance of a SOAP toolkit. Zope is another.
>                                                                 ^^^^^^
> Was that a Freudian slip :-)

SOAP and Zope. For entirely non-technical reasons it is hard to think of
one without the other!

> >PHP/Apache is another. ASP/IIS is another. J2EE just has the most hype
> >right now so I mentioned it.
> 
> Given your history I guess I expected a bit more of a Python push :-)

Well if someone was asking my opinion of what to use...

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1682
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-05 08:39:58
Subject:RE: [rest-discuss] Re: [xml-dev] ANN: Building Web Services the REST Way
Message:


> -----Original Message-----
> From: Robert Leftwich [mailto:robert@leftwich.info] 
>
> At 10:05 AM 5/07/2002, Paul Prescod wrote:
> >J2EE and Expat are all you need for a "REST toolkit and library."
> 
> Are you serious?
> J2EE has almost  the same level of complexity as SOAP 

J2EE is way (waayy) more complicated than SOAP;
EJB+Servlets+JDBC+JAAS+RMI-IIOP+JNDI+JMS...

> a single vendor set of pseudo-standards (JCP not withstanding) 

In fairness, a good amount of the J2EE stuff goes through the JCP. But I
do think that that calling expat+J2EE a REST toolkit is vaguely bogus.

Bill de hra

..
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:1683
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-05 11:52:24
Subject:Re: [rest-discuss] Re: [xml-dev] ANN: Building Web Services the REST Way
Message:

Bill de h�ra wrote:
> 
>....
> 
> > a single vendor set of pseudo-standards (JCP not withstanding)
> 
> In fairness, a good amount of the J2EE stuff goes through the JCP. But I
> do think that that calling expat+J2EE a REST toolkit is vaguely bogus.

I don't see the problem. REST is the architecture of the Web and a REST
toolkit would be a piece of software that helps you build the mediating
layer between your application and the Web. AFAIK, that's what (e.g.)
J2EE and Zope are used for. Now that XML has come along it makes sense
to want to extend these things. Just as they had native knowledge of
HTML, you might want to give them native knowledge of XML and RDF. And
maybe newer toolkits could better enforce best practices. But overall, I
see no problem calling any web development platform a REST toolkit. REST
is not something new.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1684
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-05 13:05:27
Subject:RE: [rest-discuss] Re: [xml-dev] ANN: Building Web Services the REST Way
Message:


> -----Original Message-----
> From: Paul Prescod [mailto:paul@...t] 
>
> Bill de hra wrote:
> > 
> > I do think that that calling expat+J2EE a REST toolkit is vaguely 
> > bogus.
> 
> I don't see the problem. 

The problem is that is not a meaningful distinction to make; at best
it's just co-opting systems by rebadging them. Along these lines, GNU
Linux is a REST toolkit and Bash/Vi are client tools. Now if you agree
with that, it's fine and we can stop there: what we call things is
largely a mater of taste in any case. Personally, I like my definitions
to define things not blur them together. There's a difference between
saying you can use J2EE to do REStful stuff and saying that it is for
RESTful stuff. I'm sure you know this, so I'm wondering where you're
coming from. 


> REST is the architecture of the Web 
 
I know.

> and a REST toolkit would be a piece of software that helps 
> you build the mediating layer between your application and 
> the Web. AFAIK, that's what (e.g.) J2EE and Zope are used 
> for. 

J2EE was not designed to do that any more than CORBA and DCOM were. That
they're being refactoring to do this class of work or even that you can
use J2EE for that class of work is incidental; that's aside from the
fact that J2EE system encompasses more than a pair of EJB and Servlets
containers.

Bill de hra

..
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:1685
Sender:"Don Park" <donpark@...>
Post Date/Time:2002-07-05 13:21:51
Subject:RE: [xml-dev] ANN: Building Web Services the REST Way
Message:

> Don, first you have to step back and ask whether WSDL, UDDI 
> and XKMS are good things. Then once you've decided that, it 
> makes sense to ask for equivalents. They aren't so there 
> isn't. The issue should be a no-brainer for UDDI. Who do you 
> know who is using UDDI? For what?

Paul,

Why do you insist on arguing over the individual trees instead of
looking at the forest?  I didn't bother replying when you casually filed
away my previous comments as not being relevant to Rich's specific
problem.  Now you insist on examining the value  of individual SOAP
specs when I was pointing out that REST doesn't seem to be catching fire
unlike SOAP.

> J2EE and Expat are all you need for a "REST toolkit and 
> library." I'm sorry to be so anticlimatic but the basic REST 
> tools have been deployed for around eight years now. It's 
> pretty hard to do better when the industry has already spent 
> a *billion dollars* on REST toolkits.

This display of trivialization and delusion does not become you.

> I'm curious, have you read the SOAP spec?

I have read 1.1 and earlier specs.  I have not yet read the 1.2 drafts.

Best,

Don Park

PS: I find this sudden and unilateral shift to REST mailing list
distasteful, Paul.







-----------------------------------------------------------------------------------
Post ID:1686
Sender:Ed Lucas <ejl@...>
Post Date/Time:2002-07-05 14:14:45
Subject:Re: [rest-discuss] Re: [xml-dev] ANN: Building Web Services the REST Way
Message:

Hmmm, I'm a bit hesitant to chime in here, because this forum is 
generally a bit over my head, so apologies if I am OT...

Many young script-monkeys (like myself) that pass for programmers these 
days tend to like things to have been done for us;
We don't write our own device drivers and suchlike, because we often 
don't have the time or the skill. We just use an existing library, and 
cut and paste from the sample code that came with the library documentation.

SOAP/XML-RPC/CORBA etc. all come as pre-packaged bundles, both 
physically and conceptually. You import the library, read +cut+paste the 
docs, and return a nicely massaged array or whatever. Then you and your 
boss go home, on time, happy.

With REST, you have to independently research all the pieces and grok 
the concepts, then find an appropriate library that provides 
GET,POST,PUT etc. e.g. a default PHP install will *probably* only 
include GET functionality (unless you build something up from the basic 
socket functions, or include something like CURL - which doesn't mention 
REST anywhere in it's docs). Then you have to parse the page returned, 
which might mean having to learn DOM/SAX/REGEXP.

No, it isn't really hard (except the 'groking REST' part ;), but it 
requires more time, more initiative and more brave, independent thought 
(explain to your boss why you don't want to use this 'Industry Standard' 
SOAP thing and want to 'make up' your own interface)

I'm not trying to get into a debate on the state of the industry/IT 
training, just observing human nature as I see it. If people have the 
option of being spoon-fed, they will go for it, regardless of what is on 
the spoon.

Based on this, the idea of creating a sample "REST Library" might be a 
good one?
1, It would theoretically be very simple to implement - just wrappers 
round existing functions (the debate would probably take longer than the 
writing ;)
2, It would be a point of focus for all the young whippersnappers like 
myself who like to see concrete examples
3, As you have already pointed out Paul, most platforms will have the 
components needed anyway, so after reading the docs, a programmer should 
be able to implement the concepts, from the tools they already have.
4, Maybe REST is more of a concept than a specific implementation, but 
that doesn't mean that a few provocative demos wouldn't help inspire the 
troops.
5, I find there is nothing like actually building something to show up 
the potential holes and pitfalls that people might fall into. Very Useful!

Just my two cents. Should I ask for a refund?

    Ed Lucas


 Paul Prescod wrote:

>Bill de h�ra wrote:
>  
>
>>....
>>
>>    
>>
>>>a single vendor set of pseudo-standards (JCP not withstanding)
>>>      
>>>
>>In fairness, a good amount of the J2EE stuff goes through the JCP. But I
>>do think that that calling expat+J2EE a REST toolkit is vaguely bogus.
>>    
>>
>
>I don't see the problem. REST is the architecture of the Web and a REST
>toolkit would be a piece of software that helps you build the mediating
>layer between your application and the Web. AFAIK, that's what (e.g.)
>J2EE and Zope are used for. Now that XML has come along it makes sense
>to want to extend these things. Just as they had native knowledge of
>HTML, you might want to give them native knowledge of XML and RDF. And
>maybe newer toolkits could better enforce best practices. But overall, I
>see no problem calling any web development platform a REST toolkit. REST
>is not something new.
>  
>








-----------------------------------------------------------------------------------
Post ID:1687
Sender:Paul Sandoz <Paul.Sandoz@...>
Post Date/Time:2002-07-05 14:20:28
Subject:Re: [rest-discuss] WebDAV or HTTP as foundation for REST
Message:

Paul Prescod wrote:
> Let's imagine the perfect REST toolkit. Would it be built upon an HTTP
> infrastructure or upon a WebDAV infrastructure? I do not know WebDAV as
> well as I should or will. But I'm thinking that for instance it could be
> useful for all REST applications to support WebDAV's notion of
> collections so that you would get compatibility with WebDAV collection
> management tools "for free". If a REST app has to do locking, it might
> as well use WebDAV locking. If it has to do object versioning, it might
> as well use WebDAV versioning.
> 
> Opinions?
> 

I have been lurking on this list for a while and have come to similar 
conclusions about WebDAV. I don't claim to fully understand all the 
ideas of REST and WebDAV, or if all parts of WebDAV are compliant to 
RESTs architectural style, but i might as well throw caution to the wind 
and jot down some opinions/hunches on WebDAV!

PROPFIND: I presume this has the same non-side-effects as GET. Maybe 
some of the resources defined as metadata could be compressed into or be 
referenced as properties of a resource e.g. service descriptions. The 
problem of 'what does this resource do?' may be partially resolved if 
there was a standard property on the resource defining a link to WSDL or 
RDF document.

PROPPATCH: Could be used to prime a resource with appropriate meta-data 
before commiting it for processing.

Namespace manipulation: Once a resource has been primed it could be 
commited for processing by simply moving it to another collection.

ACLS: May solve some of the issues discussed about principles. Could it 
allow for the use of one collection resource for all users viewing their 
purchase orders? Users would only get resources for the purchase orders 
they have permision to view.

Bindings and redirection (a bit like resource symbolic links): Could 
allow for multiple views of the collections e.g. allowing for 'Cabinets' 
concept you mention in the 'Reinventing Email using REST' article.


> Let's presume I'm right. If you were building a REST app today, is there
> a good WebDAV toolkit out there that is especially designed to be really
> easy to extend? Zope? 4Suite? Something in Java? mod_dav?
>

I have had experience with neon (prototyping WebDAV support for 
StarOffice) and Slide (adding rysnc and rproxy support for HTTP GET to 
the Slide HTTP/WebDAV layer and client). My view is that the WebDAV bits 
are simply extentions to the HTTP bits. With Slide the WebDAV and HTTP 
bits, encapsulated in a servlet, sit on top of a content management 
system which is capable of supporting most the WebDAV features such as 
locking, ACLs and basic versioning in addition to supporting features 
not in WebDAV (AFAIK) like transactions (although the WebDAV DeltaV may 
offer some aspects of this since i think it deals with sets of resources 
and is designed to offer functionality similar to that of CVS).



I really liked you article about email and REST. When i was implementing 
an IPP (Internet Printing Protocol) client i thought this type of thing 
could be done using WebDAV. Print queues and jobs all fit nicely in the 
resource and collection concepts and properties can be accessed using 
PROPFIND and PROPPATCH; i rekon the IPP model can be represented as a 
set of properties on resources (IPP does have distinct URIs for queues 
and jobs but binary messages are POSTed, with methods encapsulated in 
the message). The perhaps thorny issue of IPP print job notification 
fits nicely into the unification of news/email ideas that you presented.

With hindsite it annoys me that i had to implement a binary protocol on 
top of HTTP that tunneled through HTTP using POST. There were extentions 
to HTTP that i think could of done the job just as well, if not better, 
that reused existing, well proven, resources and concepts and could gain 
from their future advances.

Some speculation: perhaps if the IPP group used WebDAV and the REST 
style then this alternative way of printing could of achieved a faster 
time to market.

All the other nice features sort of fall in place, just like for REST 
email; it kind of makes me smile when i see how elegent these systems 
could be :-) and also makes me frustrated that they are currently not :-(

Maybe REST printing could become another use case along side REST email.

Thanks,
Paul.

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x19219
+353-1-8199219








-----------------------------------------------------------------------------------
Post ID:1688
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-05 17:10:53
Subject:Re: [rest-discuss] Security, REST and resources
Message:

----- Original Message -----
From: "Robert Leftwich" <robert@...>

> Adding attachments would simply be a matter of a POST to the
> patient record URI of an xml-structure containing the link to where the
> document resides. A similar approach can be taken to change or delete the
> link (i.e. PUT & DELETE). (Note that attachments are not identified as a
> sub-resource in their own right as they are simply links and as such it is
> not really necessary to expose them separately).
Without an independent URI for the added link, you can't DELETE the link
(since you can't identify the link you want to delete).
You'd have to PUT the full patient record with a list of all the links minus
the one you don't want.


> Now the security issues come into play. Suppose that for obvious reasons
you
> want to be able to restrict who can add, update or delete particular types
> of attachments.
> Without having individual sub-resources for each of the types in question
> there appears to be no way to setup this style of security using ACL. If
you
> do choose the sub-resources approach, what happens when your security
> requirements change? Do you then have to change your resources to match?
>
> Is there something I am missing in my understanding of the use of ACL in
> REST, as this approach appears too fragile and inter-dependant for my
liking?
>
Can you provide a concrete example of ACL as it applies to these resources
so we know what you are seeing from your perspective.

If I had an ACL system that was aware of HTTP messages, I could filter on
portion of the message - method, content-type, user-id, etc.:

<acl>
<ace>
<grant>
 <principal>/robert</principal>
 <method>POST</method>
 <content-type>*</content-type>
</grant>
<deny>
 <principal>/mike</principal>
 <method>POST</method>
 <content-type>application/vnd.leftwitch.billing+xml</content-type>
</deny>
</ace>
</acl>










-----------------------------------------------------------------------------------
Post ID:1689
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-05 17:17:10
Subject:Re: [rest-discuss] Re: [xml-dev] ANN: Building Web Services the REST Way
Message:

----- Original Message -----
From: "Bill de h�ra" <dehora@...>

> J2EE is way (waayy) more complicated than SOAP;
> EJB+Servlets+JDBC+JAAS+RMI-IIOP+JNDI+JMS...
That's because it's doing different things.
I wouldn't include IIOP (from Corba) or RMI (from Java) - optional & usually
available but not required in J2EE.

JNDI, JMS, JDBC and servlets are the main dish in J2EE for me & they are
simple and very powerful.
JAAS is probably just as core - I just don't happen to have any experience
with it.

As a note, JNDI may be interesting to the REST crowd because it is an API
that talks to different datasources, has addressing and has a minimal set of
common methods over those disparate types of data sources.






-----------------------------------------------------------------------------------
Post ID:1690
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-05 17:29:48
Subject:Re: [rest-discuss] Re: [xml-dev] ANN: Building Web Services the REST Way
Message:

----- Original Message -----
From: "Ed Lucas" <ejl@...>

>
> Based on this, the idea of creating a sample "REST Library" might be a
> good one?

It is a very good idea in my opinion. And I think it is /required/ to get
applications built to the REST approach.
I'd like to use existing HTTP software - clients and servers - as a base,
but there are a lot of landmines left from the Browser Wars.
Even so, many existing software tools can be used as is and the ones that
have 'issues' usually can be adjusted.

The push I'd like to make is for an 'Automatable Web'. I'm not into the
Semantic Web, and the existing 'Visual Web' just doesn't cut it - the tools
have led people down the path exposing user interface via resources (rather
than exposing the information) and handling messages in a "one resource, one
method" approach (rather than full function get/put/post/delete). Simple RPC
tools help scripters achieve some amount of networked automation, but to go
to the next level you need to build on a strong foundation - the Web - and
the features that give it strength.



There has been talk in the past about APIs that are REST friendly - we
should start a page on the Wiki.

Here is one page that has psedo-code to describe REST ideas - but a new page
is needed for full API discussions.
http://internet.conveyor.com/RESTwiki/moin.cgi/PseudoCodeForRest?action=high
light&value=api










-----------------------------------------------------------------------------------
Post ID:1691
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-05 17:30:40
Subject:Re: [rest-discuss] Re: [xml-dev] ANN: Building Web Services theREST Way
Message:

Ed Lucas wrote:
> 
>...
> 
> Many young script-monkeys (like myself) that pass for programmers these
> days tend to like things to have been done for us;
> We don't write our own device drivers and suchlike, because we often
> don't have the time or the skill. We just use an existing library, and
> cut and paste from the sample code that came with the library documentation.

Aha! So what you are lacking is sample code and documentation. That's
very different than a toolkit.

> SOAP/XML-RPC/CORBA etc. all come as pre-packaged bundles, both
> physically and conceptually. You import the library, read +cut+paste the
> docs, and return a nicely massaged array or whatever. Then you and your
> boss go home, on time, happy.

SOAP doesn't work that way if you actually want to get any of the
benefits described for it (loose coupling, asynchronous sends, etc.).
But if you just want to use it as a new-fangled, less-powerful CORBA,
then sure. Against the recommendations of everyone who understands SOAP
you can use the Visual Studio wizards out of the box and get
tightly-coupled web service without support for references or pointers.

> With REST, you have to independently research all the pieces and grok
> the concepts, then find an appropriate library that provides
> GET,POST,PUT etc. e.g. a default PHP install will *probably* only
> include GET functionality (unless you build something up from the basic
> socket functions, or include something like CURL - which doesn't mention
> REST anywhere in it's docs). 

I don't believe that PHP is really that limited. The method that comes
in should be encoded as a CGI environment variable. And PHP can make
outbound HTTP requests out with any method.

> .... Then you have to parse the page returned,
> which might mean having to learn DOM/SAX/REGEXP.

If you want the benefits of XML you have to learn some XML processing
technology. I have some ideas about XML serialization/deserializtin
techniques that are easier in some ways than the stanard techniques, but
it doesn't save you from learning anything whatsoever. In Web Services
technology that hides the XML from you (XML-RPC, VS.NET) is hiding your
best hope for extensibility.

> No, it isn't really hard (except the 'groking REST' part ;), but it
> requires more time, more initiative and more brave, independent thought
> (explain to your boss why you don't want to use this 'Industry Standard'
> SOAP thing and want to 'make up' your own interface)

There's no doubt. REST will not be easy to sell to your boss until it is
clear that SOAP is either easy or extensible, but not both, and scarcely
interoperable.

> I'm not trying to get into a debate on the state of the industry/IT
> training, just observing human nature as I see it. If people have the
> option of being spoon-fed, they will go for it, regardless of what is on
> the spoon.

I certainly agree.

> Based on this, the idea of creating a sample "REST Library" might be a
> good one?
> 1, It would theoretically be very simple to implement - just wrappers
> round existing functions (the debate would probably take longer than the
> writing ;)

I have a few concerns with your proposal:

 1. Duplicating the "toolkit" in .NET, Java, PHP, etc. is a bunch of
work. They all have their own ways of dealing with XML and HTTP. And
wrapping them consistently will hide whatever virtues each platform has.

 2. Whatever environment we left out would feel like it "couldn't do"
REST until they were given a toolkit. I'd rather teach people that they
are not dependent.

 3. I don't have a clear picture of what the toolkit looks like because
it really is the sum of the platform's HTTP capabilities plus the
platform's XML capabilities.

>...
> 5, I find there is nothing like actually building something to show up
> the potential holes and pitfalls that people might fall into. Very Useful!

Sure, we need more demos and documentation. We need people using many
different platforms to make wildly varying REST apps, using wildly
varying tools and techniques. There was no one toolkit for the HTML web
and I don't think there will be one for the XML Web.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1692
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-07-05 17:51:52
Subject:Re: [rest-discuss] RE: [xml-dev] ANN: Building Web Services the REST Way
Message:

On Fri, Jul 05, 2002 at 06:21:51AM -0700, Don Park wrote:
> > Don, first you have to step back and ask whether WSDL, UDDI 
> > and XKMS are good things. Then once you've decided that, it 
> > makes sense to ask for equivalents. They aren't so there 
> > isn't. The issue should be a no-brainer for UDDI. Who do you 
> > know who is using UDDI? For what?
> 
> Paul,
> 
> Why do you insist on arguing over the individual trees instead of
> looking at the forest?  I didn't bother replying when you casually filed
> away my previous comments as not being relevant to Rich's specific
> problem.  Now you insist on examining the value  of individual SOAP
> specs when I was pointing out that REST doesn't seem to be catching fire
> unlike SOAP.

Okay, here's the forest as I see it:

SOAP has existed for about 2 1/2 years, and from very early on has been 
heavily promoted by both Microsoft and IBM. It was touted as revolutionary 
in an era when "revolutionary" technologies were practically guaranteed to 
bring forth hordes of slavering investors. Furthermore, SOAP became seen
as a core technology of Web Services not by accident, but because it was
a key part of the development trend that led to the idea of Web
Services.

REST has been around (in substance if not in name) for much longer than
SOAP. Yet the REST-for-Web-Services movement is still very new, and
takes place in a dramatically changed marketplace. The economy is in
recession, technical innovation has lost its magical aura (and even if
it hadn't, the resources available for experimentation are vastly
reduced). SOAP has money and momentum behind it; REST has a motley crew
of smart developers. Furthermore, REST probably seems like a radical 
change to the money people, who are now afraid of radical change; yet
not radical enough to that sizable portion of the developer community
that thrives on being "cutting-edge."

So the fact that REST isn't on the verge of taking over the world means
what, exactly?

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:1693
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-05 18:16:38
Subject:Re: [xml-dev] ANN: Building Web Services the REST Way
Message:

Don Park wrote:
> 
>...
> 
> Paul,
> 
> Why do you insist on arguing over the individual trees instead of
> looking at the forest?  I didn't bother replying when you casually filed
> away my previous comments as not being relevant to Rich's specific
> problem.  

In a mailing list thread you are usually trying to discuss some specific
topic. I didn't just file it, I also told you how to do the equivalent
in HTTP.

> ... Now you insist on examining the value  of individual SOAP
> specs when I was pointing out that REST doesn't seem to be catching fire
> unlike SOAP.

REST caught fire sometime in the mid-1990s. I first did a Web Service
(an ad server) using REST techniques (and a pre-XML encoding) in 1996.
Plus, REST has more real-world Internet-deployed apps than SOAP,
including (AFAIK) Hotmail, Exchange, the whole RSS "system", etc. And
the CIO of Utah has decided to use it. ;)

 * http://www.windley.com/2002/07/03.html#a64

If you see SOAP "catching fire" then you have a different perspective
then the people I meet who are trying to make money selling web services
tools or services. Also, I see an article every week about how
businesses are taking a "wait and see" attitude towards Web Services:
this is after *5* years of development. So "catching fire" does not seem
to be the right word to me. SOAP is catching fire with software vendors
who want to send a new round of tools.

> > J2EE and Expat are all you need for a "REST toolkit and
> > library." I'm sorry to be so anticlimatic but the basic REST
> > tools have been deployed for around eight years now. It's
> > pretty hard to do better when the industry has already spent
> > a *billion dollars* on REST toolkits.
> 
> This display of trivialization and delusion does not become you.

There is nothing trivial about a the amount of money industry has spent
implementing the REST architecture. I'm sorry if it seems that way to
you. One of the main inventors of REST is also one of the lead designers
of Apache (Fielding). So surprise, surprise, Apache has REST ideas deep
down in its core. I see nothing trivial about pointing that out. PHP's
developers are strongly influenced by the Apache group, so PHP has REST
ideas deep down in its core too. etc. etc. for IIS.

Fielding's REST thesis was a description of the architecture of the
*existing tools*. Let me stress that again: the term REST is a way of
describing the architecture of the tools that *already existed* when he
wrote the thesis.

I've also talked to people deeply involved with the standardization of
J2EE and they immediately "GOT" REST and described how J2EE supports it
implicitly. I can guarantee I'll have the same experience with the
developers of Zope when I see them next (it's the response I've gotten
from Zope users -- "oh, that's what I'm already doing"). So these are my
observations from the real world. XML developers haven't caught on to
the extent that HTML developers have yet. That's true. But they have the
infrastructure, they just don't know how to use it (after all, it took
years for HTML developers to learn how to use the tools also).

This idea that something doesn't exist if it doesn't have a boxed
toolkit is bizarre to me. Where is the toolkit for GOF patterns or XP or
structured programming? Insofar as REST is an architectural style, it
has more in common with structured programming than with SOAP. What is
the SOAP architectural style? Who writes the best practices for SOAP
services?

> > I'm curious, have you read the SOAP spec?
> 
> I have read 1.1 and earlier specs.  I have not yet read the 1.2 drafts.

I'll just be interested to see, when you do, whether you still see the
spirit of XML-RPC in there.

> PS: I find this sudden and unilateral shift to REST mailing list
> distasteful, Paul.

When I post about REST to XML-DEV, I'm told that it is tiresome and
off-topic. Therefore I try not to keep threads running there for long. I
asked on at least one occasion to move the thread to rest-discuss and
nobody either agreed or disagreed. Furthermore, if I respond to a
message on XML-DEV and then ask you to do your next response to
rest-discuss, that could be perceived as a way for me to have my "last
word" on XML-DEV and shunt your comments onto a different forum. I
thought it was better to let you have the last work on that list and
move my comments to a more appropriate one.

If you prefer to discuss it on XML-DEV then we can go back there and
I'll merely comment in my messages that you wanted to discuss it there.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1694
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-05 18:30:18
Subject:Re: [rest-discuss] RE: [xml-dev] ANN: Building Web Services the REST Way
Message:

Matt Gushee wrote:
> 
>...
> 
> Okay, here's the forest as I see it:
> 
> SOAP has existed for about 2 1/2 years, and from very early on has been
> heavily promoted by both Microsoft and IBM. 

Actually, you should read this:
http://www.xml.com/pub/a/2001/04/04/soap.html

>...
> So the fact that REST isn't on the verge of taking over the world means
> what, exactly?

IIRC, Lotus Notes and Compuserve had all of the industry momentum in
1993/1994. The Web was an academic toy. That analogy was not picked at
random. Both of those products failed to understand the importance of
global, open, linking and addressing.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1695
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-05 21:16:22
Subject:RE: [rest-discuss] Re: [xml-dev] ANN: Building Web Services the REST Way
Message:


> -----Original Message-----
> From: Paul Prescod [mailto:paul@...t] 
> 
> There is nothing trivial about a the amount of money industry 
> has spent implementing the REST architecture. I'm sorry if it 
> seems that way to you. One of the main inventors of REST is 
> also one of the lead designers of Apache (Fielding). So 
> surprise, surprise, Apache has REST ideas deep down in its 
> core. I see nothing trivial about pointing that out. PHP's 
> developers are strongly influenced by the Apache group, so 
> PHP has REST ideas deep down in its core too. etc. etc. for IIS.

Well said. Perhaps the problem is that industry is not fully cognizant
of what it has been building. I'm reminded that many programmers did not
realize fully what they were doing with OO until the likes of Jim
Coplien and the GoF articulated the idea of Software Patterns.

Bill de hra

..
Propylon
www.propylon.com 








-----------------------------------------------------------------------------------
Post ID:1696
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-05 22:41:34
Subject:Re: [rest-discuss] Re: [xml-dev] ANN: Building Web Services the REST Way
Message:

Bill de h�ra wrote:
> 
>...
> 
> Well said. Perhaps the problem is that industry is not fully cognizant
> of what it has been building. I'm reminded that many programmers did not
> realize fully what they were doing with OO until the likes of Jim
> Coplien and the GoF articulated the idea of Software Patterns.

True enough. We all learned web programming so incrementally. It was
never approached as an architectural style, it was always tactical:
"gotta get this information up today. Better give a different URI to
each thing so it can be bookmarked. Oops, using POST messes up the
'refresh' button. Better use GET." etc.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1697
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-06 00:12:40
Subject:RE: [rest-discuss] Re: [xml-dev] ANN: Building Web Services the REST Way
Message:


> -----Original Message-----
> From: S. Mike Dierken [mailto:mdierken@hotmail.com] 
> Sent: 05 July 2002 18:17
> To: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Re: [xml-dev] ANN: Building Web 
> Services the REST Way
> 
> 
> 
> ----- Original Message -----
> From: "Bill de hra" <dehora@...>
> 
> > J2EE is way (waayy) more complicated than SOAP;
> > EJB+Servlets+JDBC+JAAS+RMI-IIOP+JNDI+JMS...
>
> That's because it's doing different things.

Sure, but that's what J2EE is according to Sun. A big beast.


> I wouldn't include IIOP (from Corba) or RMI (from Java) - 
> optional & usually available but not required in J2EE.

Yep, but the interop standard for EJB is RMI-IIOP, not RMI; historically
that was invented to keep the CORBA crowd happy. And it's essence is
synchronous, RPC and pass by value. I honestly don't know how well the
stubs and skeletons thing fits with REST, but otherwise RMI-IIOP doesn't
strike me as a RESTful protocol.

 
> JAAS is probably just as 
> core - I just don't happen to have any experience with it.

JAAS looks nice, it does much the same for authentication and
authorization that JNDI does for directories and JDBC does for
datasources. Clients can declare controls impendent of implementations.
I wanted to use it an upcoming project, but I didn't think there was
time for me to pick it up properly.

Bill de hra

..
Propylon
www.propylon.com 

  








-----------------------------------------------------------------------------------
Post ID:1698
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-06 01:31:10
Subject:"Application Protocols" -- an analogy
Message:

http://blogstream.com/pauls/1025918592

HTTP is an Application Protocol  
  
Posted by Paul Prescod on Friday July 05, @06:23PM
from the what-the-hell-are-you-REST-guys-talking-about? dept.
REST people often say that HTTP is an application protocol and therefore
you should not layer a "protocol independent" protocol on top of it, but
rather should only use it as is or extend it using documented extension
mechanisms. I want to offer an analogy that may clarify this.

I think we all agree that HTTP should be the basis for new technologies.
The question is whether these new technologies are new layers or new
extensions. 

Here's an analogy that might be useful. 

TCP is to HTTP as XML is to XHTML. XHTML is layered on top of XML and
XML makes almost no semantic demands on XHTML at all. XHTML can use an
element like <title> to represent something that is "logically" an
attribute and nobody complains. XHTML could use an attribute "date" to
represent something that "logically" has sub-structure and if anyone
complains it is because they are making life somewhat more difficult for
developers. But the XML standard does not say that you should use
attributes for "metadata-like things" and elements for "content-like
things". It makes almost no semantic demands on the vocabulary at all.
You would have to work pretty hard to violate the "semantics" of the XML
specification. All you could do, really, is break the syntax -- be
not-well-formed. Similarly, applications running on top of TCP have very
few semantic responsibilities. Both XML and TCP are designed to say: "do
what you want, just obey the syntactic rules of the specification." 

Now let's go up a step. XHTML is an XML application (in the old "SGML
application sense). HTTP is an application protocol. They *do* make
semantic demands on things building on top of them. In other words, you
MUST extend, not layer, on them. "P" means "paragraph" in XHTML. There
should never, ever, be a "layer" that adds another semantic on P like
"parachute". That would destroy interoperability with XHTML processors
in a very dangerous way. The documents would be valid XHTML (according
to validating parsers) but meaningless! 

You are supposed to extend XHTML with new elements, and you are supposed
to "subclass" P with "big paragraph" or "important paragraph" or
"disputed paragraph" but you should never state that in "in my variant
of XHTML, two P elements in a row means 'table'" Once you've done that,
it is no longer a variant of XHTML. It is a semantically incompatible
language and interoperability will suffer. Browsers can display it (if
it is valid XHTML) but they are displaying gibberish. 

Imagine a future scenario where firewalls filter out all vocabularies
except known ones like XHTML. Someone comes along and says: "We really
need to route arbitrary new hypertext vocabularies through firewalls.
Here's what we'll do. We'll write in NewML and 'serialize' down to HTML.
It won't be semantically meaningful HTML, because we'll use all of the
element types to mean what we want them to mean, and 'deserialize' back
to NewML on the other side. No, even better: we'll make a meta-markup
language and every man woman and child can invent their own new
hypertext markup languages that serialize to and deserialize from HTML." 

Now if somebody proposed that, I would have the following responses: 

 * If you needed more features in HTML, did you approach the working
group to add them? Having an incompatible bifurcation doesn't seem
productive. Maybe we could all benefit from your new features? 

 * If the working group turned you down, did you consider using the
existing, documented extension mechanisms? Millions of people have used
them with success. How did they fail you? 

 * Why do you have to piggy-back on HTML? Just because HTML slips
through firewalls and is popular? Surely your new markup language could
have achieved popularity of its own accord on the open market without
pretending to be HTML. Why not build on XML (TCP, in our analogy). 

 * Anyhow, why do we even need a framework for building hypertext markup
languages? HTML is an extensible hypertext markup language which
demonstrably satisfies most if not all distributed hypertext
presentation needs. When there are a hundred or a thousand markup
language variants, will interoperability be better or worse? 

These are the questions REST people ask SOAP people. 

My goal is to clarify why the relationship between SOAP (when running
over HTTP) and HTTP is very different than the relationship between HTTP
and TCP or TCP and IP. HTTP is "top dog" because it defines the baseline
semantics for anything that builds on it, just as XHTML (or RSS or
DocBook or...) does.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1699
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-06 02:24:30
Subject:Re: [rest-discuss] Security, REST and resources
Message:

At 03:10 AM 6/07/2002, S. Mike Dierken wrote:

>----- Original Message -----
>From: "Robert Leftwich" <robert@...>
>
> > Adding attachments would simply be a matter of a POST to the
> > patient record URI of an xml-structure containing the link to where the
> > document resides. A similar approach can be taken to change or delete the
> > link (i.e. PUT & DELETE). (Note that attachments are not identified as a
> > sub-resource in their own right as they are simply links and as such it is
> > not really necessary to expose them separately).
>Without an independent URI for the added link, you can't DELETE the link
>(since you can't identify the link you want to delete).
>You'd have to PUT the full patient record with a list of all the links minus
>the one you don't want.

Why do you *have* to PUT the *full* patient record? What is wrong with a PUT
containing a representation of the state the user agent wants changed, in
this case just the links it does want? For example, could the PUT contain a
Content-Model header 'Attachments' that told the server that this is the
only state it wanted to change, all the other state can remain the same?


> > Is there something I am missing in my understanding of the use of ACL in
> > REST, as this approach appears too fragile and inter-dependant for my
>liking?
> >
>Can you provide a concrete example of ACL as it applies to these resources
>so we know what you are seeing from your perspective.

Given the standards focus of  REST I thought I would attempt to use the ACL
available in servlets.  It supports the association of a role to a
URI/resource and an HTTP method if required, i.e.

<security-constraint>
     <!-- web resources that are protected for all access -->
     <web-resource-collection>
      <web-resource-name>Protected Resource</web-resource-name>
      <url-pattern>/patients/*</url-pattern>
     </web-resource-collection>

     <auth-constraint>
      <!-- role-name indicates roles that are allowed
         to access the web resources specified above -->
      <role-name>system_user</role-name>
     </auth-constraint>
   </security-constraint>

   <security-constraint>
     <!-- specialists attachments that have protected
          creation, update & deletion,
          i.e are read-only for non-specialist roles -->
     <web-resource-collection>
      <web-resource-name>Specialists Attachments</web-resource-name>
      <url-pattern>/patients/attachments/specialists/*</url-pattern>
      <http-method>POST</http-method>
      <http-method>PUT</http-method>
      <http-method>DELETE</http-method>
     </web-resource-collection>

     <auth-constraint>
      <role-name>specialist</role-name>
     </auth-constraint>
   </security-constraint>

   <security-constraint>
     <!-- police attachments that have protected
          creation, update & deletion
          i.e are read-only for non-police roles -->
     <web-resource-collection>
      <web-resource-name>Police Attachments</web-resource-name>
      <url-pattern>/patients/attachments/police/*</url-pattern>
      <http-method>POST</http-method>
      <http-method>PUT</http-method>
      <http-method>DELETE</http-method>
     </web-resource-collection>

     <auth-constraint>
      <role-name>police_officer</role-name>
     </auth-constraint>
   </security-constraint>

Lets assume that the security requirements change so that you no longer want
all police_officer roles being able to create, update or delete any of the
reports, you only want them to be able to do this to reports from their own
precinct. To do this you will need to change the resource modelling to
include the precinct in order for you to define the resources at the correct
granularity to meet the requirement, e.g.

   <security-constraint>
     <!-- police attachments that have protected
          creation, update & deletion for precinct1
          i.e are read-only for non-police roles -->
     <web-resource-collection>
      <web-resource-name>Police Attachments Precinct 1</web-resource-name>
      <url-pattern>/patients/attachments/police/precinct1/*</url-pattern>
      <http-method>POST</http-method>
      <http-method>PUT</http-method>
      <http-method>DELETE</http-method>
     </web-resource-collection>

     <auth-constraint>
      <role-name>precinct1_officer</role-name>
     </auth-constraint>
   </security-constraint>

   <security-constraint>
     <!-- police attachments that have protected
          creation, update & deletion for precinct 2,
          i.e are read-only for non-police roles -->
     <web-resource-collection>
      <web-resource-name>Police Attachments Precinct 2</web-resource-name>
      <url-pattern>/patients/attachments/police/precinct2/*</url-pattern>
      <http-method>POST</http-method>
      <http-method>PUT</http-method>
      <http-method>DELETE</http-method>
     </web-resource-collection>

     <auth-constraint>
      <role-name>precinct2_officer</role-name>
     </auth-constraint>
   </security-constraint>

...


>If I had an ACL system that was aware of HTTP messages, I could filter on
>portion of the message - method, content-type, user-id, etc.:

Do you know of any standards based ACL that provides such features?

I am slowly(!) coming to the realization that although REST portrays itself
as being based on existing and long-standing (in web terms) standards, it
really is only based on a small number of very low-level standards (HTTP,
URI, etc) and anything else that is needed to build systems based on its'
principles requires the definition of your own standards or at least the use
of a standardized approach as defined by the few REST gurus, i.e.
asynchronous notifications, reliable delivery , security,  authentication,
authorization, orchestration, message payloads, etc. most of which appear to
have yet to be used in anger in systems of any note.

This is an extremely difficult thing to sell to yourself, let alone to your
bosses and clients in the face of the juggernaut that is Web Services ala
SOAP, etc.

Robert







-----------------------------------------------------------------------------------
Post ID:1700
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-06 04:37:06
Subject:Re: [rest-discuss] Security, REST and resources
Message:

----- Original Message -----
From: "Robert Leftwich" <robert@...>

>
> Why do you *have* to PUT the *full* patient record? What is wrong with a
PUT
> containing a representation of the state the user agent wants changed, in
> this case just the links it does want? For example, could the PUT contain
a
> Content-Model header 'Attachments' that told the server that this is the
> only state it wanted to change, all the other state can remain the same?
Mainly caching - if the next request (by a different client maybe) does a
GET on the same URI, a cache could return the last PUT against that URI that
is saw. Even if the Accept header said "text/html" the cache isn't required
to fail with a 'content type not available' response.

>
> I am slowly(!) coming to the realization that although REST portrays
itself
> as being based on existing and long-standing (in web terms) standards, it
> really is only based on a small number of very low-level standards (HTTP,
> URI, etc) and anything else that is needed to build systems based on its'
> principles requires the definition of your own standards or at least the
use
> of a standardized approach as defined by the few REST gurus, i.e.
> asynchronous notifications, reliable delivery , security,  authentication,
> authorization, orchestration, message payloads, etc. most of which appear
to
> have yet to be used in anger in systems of any note.
I agree with you. I would like to be able to download a fully REST-able
adapter for SQL databases, or LDAP systems, or whatever. But that past few
years have been spent on the 'visual web' and the types of automation we
want - with security, interoperability, multiple document types, pub/sub
events - is the next phase. But it will take work.

REST is a set of low-level architectural principles - the implementation of
the Web is based on only a small number of standardized technologies -
because only a small number of technologies /could/ be standardized.
The security/authentication/authorization part has the most chance of being
standardized - but the Browser Wars left a mess of security due to the
failure of HTTP to address the needs of UI based applications. HTTP
standardizes identification - there is a header for it - but the mechanism
for /verifying/ that identity is still implementation dependent & I believe
it has to be.
What the "REST crowd" would like to see is awareness within the industry,
interest from designers and developers and new ground uncovered in the areas
(and others) that you describe. Now that it is easier to look upon the Web
from a 'big picture' point of view, we can see more clearly where to go
next.








-----------------------------------------------------------------------------------
Post ID:1701
Sender:Seth Johnson <seth.johnson@...>
Post Date/Time:2002-07-06 04:56:52
Subject:Re: [rest-discuss] Security, REST and resources
Message:

Question re: caching:  Do the caching algorithms purge
cached "records" based on whether a POST has occurred, so
that subsequent GETs have to "go to the source?"

This could be a dumb question, but I'm interested because of
the impact that this consideration may have on something I'm
working on.

Seth Johnson

"S. Mike Dierken" wrote:
> 
> From: "Robert Leftwich" <robert@...>
> > Why do you *have* to PUT the *full* patient record?
> 
> Mainly caching - if the next request (by a different client maybe) does a
> GET on the same URI, a cache could return the last PUT against that URI that
> is saw. Even if the Accept header said "text/html" the cache isn't required
> to fail with a 'content type not available' response.

-- 

[CC] Counter-copyright:
http://cyber.law.harvard.edu/cc/cc.html







-----------------------------------------------------------------------------------
Post ID:1702
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-07-06 13:21:44
Subject:Re: [rest-discuss] "Application Protocols" -- an analogy
Message:

Fwiw, I don't think that's a good analogy, because XHTML *is* XML, and
you can treat it as such.  You say "almost no" below, but a requirement
for clean layering is that there be zero dependancies.  So it's actually
a good analogy for extension. 8-O

MB


-----Original Message-----
From: Paul Prescod <paul@...>
To: rest-discuss@yahoogroups.com <rest-discuss@yahoogroups.com>
Sent: Fri Jul 05 21:31:10 2002
Subject: [rest-discuss] "Application Protocols" -- an analogy

http://blogstream.com/pauls/1025918592

HTTP is an Application Protocol  
  
Posted by Paul Prescod on Friday July 05, @06:23PM
from the what-the-hell-are-you-REST-guys-talking-about? dept.
REST people often say that HTTP is an application protocol and therefore
you should not layer a "protocol independent" protocol on top of it, but
rather should only use it as is or extend it using documented extension
mechanisms. I want to offer an analogy that may clarify this.

I think we all agree that HTTP should be the basis for new technologies.
The question is whether these new technologies are new layers or new
extensions. 

Here's an analogy that might be useful. 

TCP is to HTTP as XML is to XHTML. XHTML is layered on top of XML and
XML makes almost no semantic demands on XHTML at all. XHTML can use an
element like <title> to represent something that is "logically" an
attribute and nobody complains. XHTML could use an attribute "date" to
represent something that "logically" has sub-structure and if anyone
complains it is because they are making life somewhat more difficult for
developers. But the XML standard does not say that you should use
attributes for "metadata-like things" and elements for "content-like
things". It makes almost no semantic demands on the vocabulary at all.
You would have to work pretty hard to violate the "semantics" of the XML
specification. All you could do, really, is break the syntax -- be
not-well-formed. Similarly, applications running on top of TCP have very
few semantic responsibilities. Both XML and TCP are designed to say: "do
what you want, just obey the syntactic rules of the specification." 

Now let's go up a step. XHTML is an XML application (in the old "SGML
application sense). HTTP is an application protocol. They *do* make
semantic demands on things building on top of them. In other words, you
MUST extend, not layer, on them. "P" means "paragraph" in XHTML. There
should never, ever, be a "layer" that adds another semantic on P like
"parachute". That would destroy interoperability with XHTML processors
in a very dangerous way. The documents would be valid XHTML (according
to validating parsers) but meaningless! 

You are supposed to extend XHTML with new elements, and you are supposed
to "subclass" P with "big paragraph" or "important paragraph" or
"disputed paragraph" but you should never state that in "in my variant
of XHTML, two P elements in a row means 'table'" Once you've done that,
it is no longer a variant of XHTML. It is a semantically incompatible
language and interoperability will suffer. Browsers can display it (if
it is valid XHTML) but they are displaying gibberish. 

Imagine a future scenario where firewalls filter out all vocabularies
except known ones like XHTML. Someone comes along and says: "We really
need to route arbitrary new hypertext vocabularies through firewalls.
Here's what we'll do. We'll write in NewML and 'serialize' down to HTML.
It won't be semantically meaningful HTML, because we'll use all of the
element types to mean what we want them to mean, and 'deserialize' back
to NewML on the other side. No, even better: we'll make a meta-markup
language and every man woman and child can invent their own new
hypertext markup languages that serialize to and deserialize from HTML."


Now if somebody proposed that, I would have the following responses: 

 * If you needed more features in HTML, did you approach the working
group to add them? Having an incompatible bifurcation doesn't seem
productive. Maybe we could all benefit from your new features? 

 * If the working group turned you down, did you consider using the
existing, documented extension mechanisms? Millions of people have used
them with success. How did they fail you? 

 * Why do you have to piggy-back on HTML? Just because HTML slips
through firewalls and is popular? Surely your new markup language could
have achieved popularity of its own accord on the open market without
pretending to be HTML. Why not build on XML (TCP, in our analogy). 

 * Anyhow, why do we even need a framework for building hypertext markup
languages? HTML is an extensible hypertext markup language which
demonstrably satisfies most if not all distributed hypertext
presentation needs. When there are a hundred or a thousand markup
language variants, will interoperability be better or worse? 

These are the questions REST people ask SOAP people. 

My goal is to clarify why the relationship between SOAP (when running
over HTTP) and HTTP is very different than the relationship between HTTP
and TCP or TCP and IP. HTTP is "top dog" because it defines the baseline
semantics for anything that builds on it, just as XHTML (or RSS or
DocBook or...) does.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 









-----------------------------------------------------------------------------------
Post ID:1703
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-06 15:55:55
Subject:Re: [rest-discuss] "Application Protocols" -- an analogy
Message:

Mark Baker wrote:
> 
> Fwiw, I don't think that's a good analogy, because XHTML *is* XML, and
> you can treat it as such.  

HTTP connections *are* TCP connections and you can treat them as such.

> You say "almost no" below, but a requirement
> for clean layering is that there be zero dependancies.  So it's actually
> a good analogy for extension. 8-O

There could never be zero dependencies. HTTP depends on TCP's
"reliabilty" semantics. It depends on the fact that TCP is bidirectional
and synchronous.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1704
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-06 16:23:02
Subject:Re: [PMX:#] [rest-discuss] Top dog
Message:

Paul Prescod wrote:
> bhaugen32 wrote:
> > 
> > Mark Baker wrote in
> > http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0042.html
> > 
> > > What's special about the application layer,
> > > is that it is the "top dog".
> > > You can't layer on top of it and still call
> > > yourself a valid use of that protocol.
> > > You can only extend it.
> > 
> > How about the case we discussed previously about implementing the
> > offer-acceptance business protocol in REST?
> > 
> > There is clearly something else going on that seems to be to
> > be "above" the HTTP protocol.  As ISO says, you're not just
> > exchanging data, you're making business commitments.
> 
> There is something else going on, but it is an extension of HTTP. I
> think of things like WebDAV and Offer/Acceptance as plugins. 

Are you thinking of Offer/Acceptance as a technical thing?
It can be implemented via several technical protocols, including REST 
(as we discussed) or EDI-mailbox-style SOAP (as in ebXML or 
RosettaNet) or email or fax or paper and ink, for that matter.

In each case, what you want to end up with technically is a single 
document spelling out the business commitment and signed by both 
parties to signify their agreement.

But the essence is in another dimension, where the business 
commitments live:  economic and legal.  

Also, this is not a case of abusing HTTP as an application protocol, 
but using it as it was intended in order to achieve this purpose in 
this other dimension.

> > Rohit Khare had an interesting diagram in his recent Soap Routing
> > slide show where he added two layers on top the application 
protocol:
> > Layer 8 - Economic (which is where business commitments cd go)
> > Layer 9 - Political.
> 
> I was at the talk and in that context it was clear that he meant it 
more
> as a joke. Not "economic protocols" like ebXML but "economic 
protocols"
> like -- how do I con venture capitalists into giving me money?

Thanks, I suspected he didn't mean what I meant.  
But I took it seriously anyway, and still like the idea.  
And I think ISO and UN/CEFACT think about it in much the same way.
What I hear from both groups now is that there is a layer of business 
protocols on top of the ISO stack, and then a layer of regulatory 
protocols on top of the business protocols.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1705
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-07-06 19:01:11
Subject:Re: [rest-discuss] "Application Protocols" -- an analogy
Message:

A good litmus test for layering in my experience, is if the top piece
can be defined independantly of the bottom piece. You won't find any
mention of TCP in RFC 2616 (I hope - I don't have it handy) for example,
but XHTML couldn't exist without XML.

A HTTP connection isn't necessarily a TCP connection because of this.

This is a really subtle point, but an important one, and one that could
do with some more rigorous defintion IMO.

MB

-----Original Message-----
From: Paul Prescod <paul@...>
To: Mark Baker <mbaker@...>; rest-discuss@yahoogroups.com
<rest-discuss@yahoogroups.com>
Sent: Sat Jul 06 11:55:55 2002
Subject: Re: [rest-discuss] "Application Protocols" -- an analogy

Mark Baker wrote:
> 
> Fwiw, I don't think that's a good analogy, because XHTML *is* XML, and
> you can treat it as such.  

HTTP connections *are* TCP connections and you can treat them as such.

> You say "almost no" below, but a requirement
> for clean layering is that there be zero dependancies.  So it's
actually
> a good analogy for extension. 8-O

There could never be zero dependencies. HTTP depends on TCP's
"reliabilty" semantics. It depends on the fact that TCP is bidirectional
and synchronous.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/







-----------------------------------------------------------------------------------
Post ID:1706
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-07-06 19:02:44
Subject:Re: [PMX:#] [rest-discuss] Top dog
Message:

Btw, my last response on xml-dist-app to Stuart Williams should explain
the answers to the questions you had, Bob. Sorry, don't have a browser
handy to look up the URI.

MB

-----Original Message-----
From: bhaugen32 <bhaugen32@...>
To: rest-discuss@yahoogroups.com <rest-discuss@...m>
Sent: Sat Jul 06 12:23:02 2002
Subject: Re: [PMX:#] [rest-discuss] Top dog

Paul Prescod wrote:
> bhaugen32 wrote:
> > 
> > Mark Baker wrote in
> > http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0042.html
> > 
> > > What's special about the application layer,
> > > is that it is the "top dog".
> > > You can't layer on top of it and still call
> > > yourself a valid use of that protocol.
> > > You can only extend it.
> > 
> > How about the case we discussed previously about implementing the
> > offer-acceptance business protocol in REST?
> > 
> > There is clearly something else going on that seems to be to
> > be "above" the HTTP protocol.  As ISO says, you're not just
> > exchanging data, you're making business commitments.
> 
> There is something else going on, but it is an extension of HTTP. I
> think of things like WebDAV and Offer/Acceptance as plugins. 

Are you thinking of Offer/Acceptance as a technical thing?
It can be implemented via several technical protocols, including REST 
(as we discussed) or EDI-mailbox-style SOAP (as in ebXML or 
RosettaNet) or email or fax or paper and ink, for that matter.

In each case, what you want to end up with technically is a single 
document spelling out the business commitment and signed by both 
parties to signify their agreement.

But the essence is in another dimension, where the business 
commitments live:  economic and legal.  

Also, this is not a case of abusing HTTP as an application protocol, 
but using it as it was intended in order to achieve this purpose in 
this other dimension.

> > Rohit Khare had an interesting diagram in his recent Soap Routing
> > slide show where he added two layers on top the application 
protocol:
> > Layer 8 - Economic (which is where business commitments cd go)
> > Layer 9 - Political.
> 
> I was at the talk and in that context it was clear that he meant it 
more
> as a joke. Not "economic protocols" like ebXML but "economic 
protocols"
> like -- how do I con venture capitalists into giving me money?

Thanks, I suspected he didn't mean what I meant.  
But I took it seriously anyway, and still like the idea.  
And I think ISO and UN/CEFACT think about it in much the same way.
What I hear from both groups now is that there is a layer of business 
protocols on top of the ISO stack, and then a layer of regulatory 
protocols on top of the business protocols.

-Bob Haugen



To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 









-----------------------------------------------------------------------------------
Post ID:1707
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-06 19:42:53
Subject:Re: [rest-discuss] "Application Protocols" -- an analogy
Message:

Mark Baker wrote:
> 
> A good litmus test for layering in my experience, is if the top piece
> can be defined independantly of the bottom piece. You won't find any
> mention of TCP in RFC 2616 (I hope - I don't have it handy) for example,
> but XHTML couldn't exist without XML.

"HTTP communication usually takes place over TCP/IP connections. The
default port is TCP 80 [19], but other ports can be used. This does not
preclude HTTP from being implemented on top of any other protocol on the
Internet, or on other networks. HTTP only presumes a reliable transport;
any protocol that provides such guarantees can be used; the mapping of
the HTTP/1.1 request and response structures onto the transport data
units of the protocol in question is outside the scope of this
specification."

But you can imagine a similar state for XHTML (in a world where there
were multiple competing markup language syntaxes):

"This does not preclude XHTML from being encoded in any other syntax.
XHTML only presumes a concept of 'element' and 'attribute'. Blah blah
blah blah." 

In fact it is very trendy these days to define markup languages in terms
of the "infoset" and say that "any mapping from any syntax to the
infoset is legal." So you could imagine an XHTML this is an extension to
the "infoset" but the infoset would be a layer on top of XML itself.
(after all, it has been implemented on top of relational databases etc.)

> A HTTP connection isn't necessarily a TCP connection because of this.

The same goes for many XML specifications. XHTML doesn't happen to have
that language in the spec because there is no real competitor to XML
(though there are hardly competitors to TCP used much anymore either!).

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1708
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-07-06 20:04:37
Subject:Re: [rest-discuss] "Application Protocols" -- an analogy
Message:

Mark Baker wrote,
> A good litmus test for layering in my experience, is if the top piece
> can be defined independantly of the bottom piece. You won't find any
> mention of TCP in RFC 2616 (I hope - I don't have it handy) for
> example, but XHTML couldn't exist without XML.

Sadly not the case.

The best illustration of HTTP's coupling with TCP is the definition of 
the value of the mandatory Host: request header (see RFC 2616, 14.23). 
Even tho' TCP isn't explicitly mentioned it's hard to make sense of 
without the assumption of TCP as the underlying transport protocol. 
Implicit couplings to TCP show up elsewhere in the spec (particularly 
in section 8) and also in related RFCs (eg. 2109). IMO HTTPs alleged 
transport independence is mostly window dressing.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:1709
Sender:Dan Brickley <danbri@...>
Post Date/Time:2002-07-06 21:24:16
Subject:Re: [rest-discuss] "Application Protocols" -- an analogy
Message:

On Sat, 6 Jul 2002, Paul Prescod wrote:

> Mark Baker wrote:
> >
> > A good litmus test for layering in my experience, is if the top piece
> > can be defined independantly of the bottom piece. You won't find any
> > mention of TCP in RFC 2616 (I hope - I don't have it handy) for example,
> > but XHTML couldn't exist without XML.
>
> "HTTP communication usually takes place over TCP/IP connections. The
> default port is TCP 80 [19], but other ports can be used. This does not
> preclude HTTP from being implemented on top of any other protocol on the
> Internet, or on other networks. HTTP only presumes a reliable transport;
> any protocol that provides such guarantees can be used; the mapping of
> the HTTP/1.1 request and response structures onto the transport data
> units of the protocol in question is outside the scope of this
> specification."
>
> But you can imagine a similar state for XHTML (in a world where there
> were multiple competing markup language syntaxes):
>
> "This does not preclude XHTML from being encoded in any other syntax.
> XHTML only presumes a concept of 'element' and 'attribute'. Blah blah
> blah blah."
>
> In fact it is very trendy these days to define markup languages in terms
> of the "infoset" and say that "any mapping from any syntax to the
> infoset is legal." So you could imagine an XHTML this is an extension to
> the "infoset" but the infoset would be a layer on top of XML itself.
> (after all, it has been implemented on top of relational databases etc.)

FWIW we do something similar, and imho more convincing, with RDF. RDF is
defined in its own world of edge-labelled graphs, with any mapping to XML
(or to unicode/text) being fine. And there _are_ non-XML syntaxes that
work for exchanging RDF, so there's definitely some layering going on. Flipside
of that is disconnection: by remaining aloof from nitty gritty of the
'lower' layers, the loftier layer risks reinventing useful stuff from
below. In SOAP's case, content negotiation etc.; in RDF's case, query
mechanisms (XPath, XQuery etc). We can't win... ;-)

Dan


-- 
mailto:danbri@...
http://www.w3.org/People/DanBri/







-----------------------------------------------------------------------------------
Post ID:1710
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-07-06 23:22:38
Subject:Re: [rest-discuss] "Application Protocols" -- an analogy
Message:

Defining it in terms of the Infoset is only a partial defintion
(granted, it shoots a hole in my litmus test as currently worded). You
still need to pick a serialization in order to be able to realize the
thing.  And once you've picked a serialization, you are no longer a
layer because the serializations themselves remain recognizable.

I suppose that true layering is perhaps native to protocols, and doesn't
apply to data formats.  At least that seems a reasonable hypothesis
based on this discussion.

Thanks for that text from 2616 - it makes my point about HTTP/TCP, and
saves a response to Miles. 8-). In HTTP "0.9" and 1.0, there was
actually some poor layering, because a request was said to end if the
connection went down (I.e. TCP FIN was effectively given HTTP
semantics).

MB

-----Original Message-----
From: Paul Prescod <paul@...>
To: Mark Baker <mbaker@...>; rest-discuss@yahoogroups.com
<rest-discuss@yahoogroups.com>
Sent: Sat Jul 06 15:42:53 2002
Subject: Re: [rest-discuss] "Application Protocols" -- an analogy

Mark Baker wrote:
> 
> A good litmus test for layering in my experience, is if the top piece
> can be defined independantly of the bottom piece. You won't find any
> mention of TCP in RFC 2616 (I hope - I don't have it handy) for
example,
> but XHTML couldn't exist without XML.

"HTTP communication usually takes place over TCP/IP connections. The
default port is TCP 80 [19], but other ports can be used. This does not
preclude HTTP from being implemented on top of any other protocol on the
Internet, or on other networks. HTTP only presumes a reliable transport;
any protocol that provides such guarantees can be used; the mapping of
the HTTP/1.1 request and response structures onto the transport data
units of the protocol in question is outside the scope of this
specification."

But you can imagine a similar state for XHTML (in a world where there
were multiple competing markup language syntaxes):

"This does not preclude XHTML from being encoded in any other syntax.
XHTML only presumes a concept of 'element' and 'attribute'. Blah blah
blah blah." 

In fact it is very trendy these days to define markup languages in terms
of the "infoset" and say that "any mapping from any syntax to the
infoset is legal." So you could imagine an XHTML this is an extension to
the "infoset" but the infoset would be a layer on top of XML itself.
(after all, it has been implemented on top of relational databases etc.)

> A HTTP connection isn't necessarily a TCP connection because of this.

The same goes for many XML specifications. XHTML doesn't happen to have
that language in the spec because there is no real competitor to XML
(though there are hardly competitors to TCP used much anymore either!).

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/







-----------------------------------------------------------------------------------
Post ID:1711
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-07-06 23:52:46
Subject:Re: [rest-discuss] "Application Protocols" -- an analogy
Message:

Mark Baker wrote,
> Thanks for that text from 2616 - it makes my point about HTTP/TCP,
> and saves a response to Miles. 8-). In HTTP "0.9" and 1.0, there was
> actually some poor layering, because a request was said to end if the
> connection went down (I.e. TCP FIN was effectively given HTTP
> semantics).

Hmm ... I disagree. The passage that Paul quoted certainly represents 
the desire of the WG to make HTTP transport independent, but the 
reality is different. The Host: header ties the HTTP to TCP, and it's 
semantics couldn't easily be magic'd away by editorial passes between 
1.0 and 1.1.

Rather than wrestling with ASCII art UML diagrams, here's a Java 
fragement which illustrates the problem,

  public interface HttpRequest 
  {
    public HostPortPair getHost();
    public void setHost(HostPortPair host);
  }

  public final class TcpHttpRequest
  {
    public HostPortPair getHost()
    {
      // no problem
    }

    public void setHost(HostPortPair host)
    {
      // no problem
    }
  }

  public final class NonTcpHttpRequest
  {
    public HostPortPair getHost()
    {
      // oops ... how do we implement this?
    }

    public void setHost(HostPortPair host)
    {
      // oops ... how do we implement this?
    }
  }
  
The problem is probably fixable ... the Host: header might be definable 
in a transport independant way without creating other problems. But it 
wasn't in RFC 2616. Maybe HTTP/1.2 ;-)

IIRC there are a few threads on this in the HTTP WG mailing list 
archive, but I don't have any references handy just now.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:1712
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-07-07 21:47:47
Subject:RE: [rest-discuss] Security, REST and resources
Message:

Robert wrote:
> Now the security issues come into play. Suppose that for obvious reasons
> you want to be able to restrict who can add, update or delete particular
> types of attachments.
>
> Without having individual sub-resources for each of the types in question
> there appears to be no way to setup this style of security using ACL. If
> you do choose the sub-resources approach, what happens when your security
> requirements change? Do you then have to change your resources to match?
>
> Is there something I am missing in my understanding of the use of ACL in
> REST, as this approach appears too fragile and inter-dependant for my
> liking?

Conceptually, I think applying ACLs as associations between users/groups and
resources/representations and HTTP methods makes a lot of sense.  For example:

  Allow(philip, GET, resource1)
  Allow(administrators, *, *)
  Deny (guests, *, POST)
  Deny (*.microsoft.com, *, *)  ;-)

These could be declared in XML and could be applied to any logical or physical
location in a node's namespace.

Then S. Mike wrote in response:
> If I had an ACL system that was aware of HTTP messages, I could filter
> on portion of the message - method, content-type, user-id, etc.:

Definitely.  I immediately think about filters being a great place to do
this....not only to filter at the HTTP message header level, but also at the ACL
policy level (e.g., what I show above declared above and beyond optional or
mandatory header fields).

Good topic.

-Philip

PS: I just got back from a week of scuba diving in Key West.  During a deep
wreck dive, I think I achieved Zen on REST and methods.  Let me get caught up
and I'll send my take.







-----------------------------------------------------------------------------------
Post ID:1713
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-07 22:10:47
Subject:RE: [rest-discuss] Security, REST and resources
Message:


> -----Original Message-----
> From: Philip Eskelin [mailto:philip@eskelin.com] 
>
> Conceptually, I think applying ACLs as associations between 
> users/groups and resources/representations and HTTP methods 
> makes a lot of sense.  For example:
> 
>   Allow(philip, GET, resource1)
>   Allow(administrators, *, *)
>   Deny (guests, *, POST)
>   Deny (*.microsoft.com, *, *)  ;-)
> 
> These could be declared in XML and could be applied to any 
> logical or physical location in a node's namespace.

Or in any language that supports aspect oriented programming. Those
allow and deny methods look a lot like pointcut operators to me.

Bill de hra

..
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:1714
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-07 22:27:28
Subject:Re: [rest-discuss] Security, REST and resources
Message:


>
> Conceptually, I think applying ACLs as associations between users/groups
and
> resources/representations and HTTP methods makes a lot of sense.  For
example:
>
>   Allow(philip, GET, resource1)
>   Allow(administrators, *, *)
>   Deny (guests, *, POST)
>   Deny (*.microsoft.com, *, *)  ;-)
>

I've always taken the approach that permissions are declarative
relationships between information and users. The 'users' actually could be
an individual, a group, etc. I generalize that into 'principal'. The actual
storage, caching, updating, etc. in an implementation is what makes a
product work in any particular setting. You could bind the permissions to
the information, or to the user, or in a third 'link table' or whatever. The
principal could be a 'role' and these could be a fixed list and hardcoded
into the application logic - there are a lot of choices on how to implement
permissions.

One interesting aspect is that permissions are relationships between
information and users and they 'block' messages coming from many sources to
one target, and subscriptions are also relationships between information and
users and they 'forward' messages from one source to many targets - and the
forwarded messages are echoes of the operations that hit the permission
'block'. There's something important in there somewhere...  permissions and
subscriptions are tangled somehow. These are the four foundations of
applications I enjoy building - information, users, permissions and
subscriptions - and they way you manage messages into or out of this system
makes it a holistic system.

Mike






-----------------------------------------------------------------------------------
Post ID:1715
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-07 22:40:32
Subject:Re: [rest-discuss] Security, REST and resources
Message:

Philip Eskelin wrote:
> 
>...
> 
> PS: I just got back from a week of scuba diving in Key West.  During a deep
> wreck dive, I think I achieved Zen on REST and methods.  

And I thought *I* was obsessed.

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1716
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-07 22:42:37
Subject:Re: [rest-discuss] Security, REST and resources
Message:

Bill de h�ra wrote:
> 
>...
> Or in any language that supports aspect oriented programming. Those
> allow and deny methods look a lot like pointcut operators to me.

And I was thinking of semantic Web languages. ;)

Seriously, semantic web languages (e.g. DAML) seem to have the
inferencing and subclassing facilities that would allow really
sophisticated security rules to be succinctly stated.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1717
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-07 22:58:32
Subject:RE: [rest-discuss] Security, REST and resources
Message:

At 07:47 AM 8/07/2002, Philip Eskelin wrote:
>Robert wrote:
> >
> > Is there something I am missing in my understanding of the use of ACL in
> > REST, as this approach appears too fragile and inter-dependant for my
> > liking?
>
>Conceptually, I think applying ACLs as associations between users/groups and
>resources/representations and HTTP methods makes a lot of sense.

I agree. My original issue was in attempting to fit the requirements to the
existing servlet security spec. It is obvious (now) that this spec is not
sufficiently powerful/granular to cope with a REST approach.

Robert


>PS: I just got back from a week of scuba diving in Key West.

Just to make you feel even better  - it's been somewhere between - (that's
minus!) 7 (centigrade) overnight and +10C daytime for the past week or so,
not quite scuba weather!








-----------------------------------------------------------------------------------
Post ID:1718
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-07 23:06:02
Subject:RE: [rest-discuss] Security, REST and resources
Message:


> -----Original Message-----
> From: Paul Prescod [mailto:paul@...t] 
>
> Seriously, semantic web languages (e.g. DAML) seem to have 
> the inferencing and subclassing facilities that would allow 
> really sophisticated security rules to be succinctly stated.

Yes, you can hang some metadata RDF style about security off a resource,
and if you use this to fire processing actions, you've reinvented AI
slots and frames; not a bad thing imo. 

And as we were talking about J2EE a few days back, take a look at the
JAAS. Syntactically it feels a bit clunky, but underneath it is nicely
declarative and gives you a good separation of policy and mechanism.

Bill de hra

..
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:1719
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-07-07 23:28:02
Subject:RE: [rest-discuss] Re: [xml-dev] ANN: Building Web Services the REST Way
Message:

Paul wrote:
> I don't see the problem. REST is the architecture of the Web and a REST
> toolkit would be a piece of software that helps you build the mediating
> layer between your application and the Web. AFAIK, that's what (e.g.)
> J2EE and Zope are used for. Now that XML has come along it makes sense
> to want to extend these things. Just as they had native knowledge of
> HTML, you might want to give them native knowledge of XML and RDF. And
> maybe newer toolkits could better enforce best practices. But overall, I
> see no problem calling any web development platform a REST toolkit. REST
> is not something new.

I agree with your position that any web development platform could be called a
REST toolkit.  However, I think a more RESTful toolkit should have types defined
in its namespace that correspond to Fielding's documented approach if it's going
to make programming RESTfully feel more concretely similar (and IMO easier to
comprehend the REST style).

For example, here are some of the objects that are being implemented in my
toolkit (sorry I keep bringing up my own vaporware, but it's the most concrete
thing I have right now): CObject, CString, CList, CTable, CResource,
CRepresentation, CConnector, CStream, CRequest, CResponse, CComponent, CFilter,
CProxy, etc.

Add a handful of sample apps to a class framework like this and you've got a
nice simple way to communicate the essence of the RESTful style.

-Philip







-----------------------------------------------------------------------------------
Post ID:1720
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-07 23:29:29
Subject:Re: [rest-discuss] Security, REST and resources
Message:

At 08:27 AM 8/07/2002, S. Mike Dierken wrote:

>I've always taken the approach that permissions are declarative
>relationships between information and users.

What about functionality and users, i.e. restricting the functions those
users can perform on the information. This tends to be more of a user-agent
issue, but still there needs to be the ability to hide or disable
functionality that the current user cannot perform. A declarative mapping
from resource permissions to functionality could be useful, but the user
agent would need to be able to discover what the resource permissions are.

Hmm... if the resource permissions were available as a resource in their own
right, then a user-agent could retrieve them and do the mapping as required.
Sounds vaguely plausible and is certainly RESTful is it not ?

>there are a lot of choices on how to implement permissions.

Indeed there are, unfortunately none of which appear to be ideally suited to
REST out of the box :-(


>There's something important in there somewhere...  permissions and
>subscriptions are tangled somehow.

If you think HTTP Events then the permissions are intimately tied to 
subscriptions - if you don't have permission to access a resource then you 
cannot subscribe to it. The issue of the composite resources, i.e. the 
/site/changes resource is more problematic, the publisher would need to 
filter notifications based on the subscribers permissions.

>These are the four foundations of
>applications I enjoy building - information, users, permissions and
>subscriptions - and they way you manage messages into or out of this system
>makes it a holistic system.

It's a concern that we as an industry need to keep on building users,
permissions and subscriptions. Why have we still not
standardized/componentized these things sufficiently well that we can
concentrate on the information, which is where the real value and
benefits lie?

Robert

PS And why is it that my systems end up more as hole-istic rather
than holistic :-)







-----------------------------------------------------------------------------------
Post ID:1721
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-07-07 23:34:41
Subject:RE: [rest-discuss] Security, REST and resources
Message:

Bill wrote:
> > Conceptually, I think applying ACLs as associations between
> > users/groups and resources/representations and HTTP methods
> > makes a lot of sense.  For example:
> >
> >   Allow(philip, GET, resource1)
> >   Allow(administrators, *, *)
> >   Deny (guests, *, POST)
> >   Deny (*.microsoft.com, *, *)  ;-)
> >
> > These could be declared in XML and could be applied to any
> > logical or physical location in a node's namespace.
>
> Or in any language that supports aspect oriented programming. Those
> allow and deny methods look a lot like pointcut operators to me.

This is a very interesting take.  I hadn't of that.  How might you implement it?
I understand AOP but I'm not sure I understand how you would integrate that into
this conceptual approach.  Do you mean pointcut operators applied to doFilter
methods inside filter components?

-Philip







-----------------------------------------------------------------------------------
Post ID:1722
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-07 23:35:49
Subject:Re: [rest-discuss] Security, REST and resources
Message:

On 7/7/02 5:40 PM, "Paul Prescod" <paul@...> wrote:

> Philip Eskelin wrote:
>> 
>> ...
>> 
>> PS: I just got back from a week of scuba diving in Key West.  During a deep
>> wreck dive, I think I achieved Zen on REST and methods.
> 
> And I thought *I* was obsessed.

My gestalt happened in the shower...  That's a whole lot more mundane;
Phil, I'm envious. ;-) :-)

Jb








-----------------------------------------------------------------------------------
Post ID:1723
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-07 23:57:36
Subject:Re: [rest-discuss] Security, REST and resources
Message:

----- Original Message -----
From: "Robert Leftwich" <robert@...>

>
> What about functionality and users, i.e. restricting the functions those
> users can perform on the information.
Those functions are communicated via messages and the permissions are
filters that use data from those messages.
So I guess permissions are relations between users and information AND with
patterns/pointers into (prototypical) messages.

>A declarative mapping
> from resource permissions to functionality could be useful, but the user
> agent would need to be able to discover what the resource permissions are.
Sure - getting a repesentation in XML is easy.

>
> Hmm... if the resource permissions were available as a resource in their
own
> right, then a user-agent could retrieve them and do the mapping as
required.
> Sounds vaguely plausible and is certainly RESTful is it not ?
Yep - you wouldn't /evaluate/ the permissions, but you can do some great UI
hints.



> If you think HTTP Events then the permissions are intimately tied to
> subscriptions - if you don't have permission to access a resource then you
> cannot subscribe to it.
Being subscribed to a resource is the same as reading the future of a
resource - so the only
permissions you need are GET permissions (or 'read' permissions if you are a
old fogey into those archaic things called operating systems).
Depending on how you implement the relation between info and users, the act
of creating a subscription is either an act upon the information, or perhaps
an act upon a user, or an act upon a third entity (a collection of
permissions). That third entity would have permissions unto itself. Fun...

> The issue of the composite resources, i.e. the
> /site/changes resource is more problematic, the publisher would need to
> filter notifications based on the subscribers permissions.
You have to filter on the current state of the subscribers GET ('read')
permission on the resource - somewhat intensive, unless you are willing to
live with latency, and then you could have the subscription(s) listen for
changes to permissions on the subscribed resource. (it sounds complicate,
but honest it really isn't - i've done this stuff with RDBs as the backend
and it was very straightforward...)

>
> It's a concern that we as an industry need to keep on building users,
> permissions and subscriptions. Why have we still not
> standardized/componentized these things sufficiently well that we can
> concentrate on the information, which is where the real value and
> benefits lie?
I'm amazed that OSes don't ship with all four aspects out of the box - file
systems are fine for information (ignoring searchability), but there are no
common/standardized subscription mechanisms on that and certainly no common
directory systems. Heck, my OutlookExpress address book is my personal
directory service - I'd love to have LDAP into that thing...








-----------------------------------------------------------------------------------
Post ID:1724
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-07-08 00:07:12
Subject:RE: [rest-discuss] Security, REST and resources
Message:

Paul wrote:
> Philip Eskelin wrote:
> >
> >...
> >
> > PS: I just got back from a week of scuba diving in Key
> > West.  During a deepwreck dive, I think I achieved Zen on
> > REST and methods.
>
> And I thought *I* was obsessed.

I'm not finished catching up, so pardon me if I take anyone off their thread.
During my dive, I realized that in order for me to see the fish around the
wreck, and swim across the ship's deck to a payphone and act like I'm placing a
call, I must go to the site first.  I can't do any of it from the boat.  I swim
to the mooring buoy and descend down the line to the wreck....i.e., I transfer
myself.

I probably went over the top with my analogy.  But what it helped me realize is
that when you boiled it down, my notion of method - and even my revised notion
(after our noun vs. verb discussion) - was *yet* another RPC!  Makes me cringe
;-).  Bottom line: to break away from an RPC over the Internet, why not just
take 'remote' out of RPC and replace it with 'local'?  And how do you do that in
REST?

You GET a representation of the resource, invoke your method locally, and then
POST the updated representation back to the resource.  That's it.  Wasn't it Tip
O'Neill that said "all politics is local"?  You get the idea...

-Philip








-----------------------------------------------------------------------------------
Post ID:1725
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-07-08 03:13:55
Subject:RE: [rest-discuss] Security, REST and resources
Message:

Jeff wrote:
> Paul wrote:
> > Philip Eskelin wrote:
> > >
> > > ...
> > >
> > > PS: I just got back from a week of scuba diving in Key
> > > West.  During a deep wreck dive, I think I achieved Zen
> > > on REST and methods.
> >
> > And I thought *I* was obsessed.
>
> My gestalt happened in the shower...  That's a whole lot more mundane;
> Phil, I'm envious. ;-) :-)

Glad to be back on the list!  To combine my "method Zen" with the security
discussion and Mike's comments about the role (pun intended) of subscriptions,
here is a contrast that I find interesting:

Old Way (DCE RPC, ONC RPC, EZ-RPC, Microsoft RPC, CORBA, DCOM, RMI, XML-RPC,
SOAP, etc):

1. Remote message to a server requesting subcription to a topic
2. Remote response by server indicating the results
3. Remote message to server indicating update to topic by a publisher
   client(s)
4. Remote server sends (or multicasts) an update to each remote
   subscriber
5. Remote message to server requesting any or all of the topic's
   contents

New Way (REST, WebDAV?, etc):

1. Subscriber client creates subordinate representation (r1) of a
   subscription
2. HTTP POST of r1 to the remote topic's Subscriptions-URI resource,
   including a Subscriber-URI entity field if the client desires
   real-time event notifications
3. Publisher client creates subordinate representation (r2) of an
   update relative to the topic's watched content resource
4. HTTP POST of r2 to the remote topic's Watched-URI resource
5. Server translates and/or forwards r2 via HTTP PUT to each
   subscriber client's Subscriber-URI resource
6. HTTP GET to the remote topic's Watched-URI resource to fetch any
   or all of the topic's contents

Notice the common theme is that old method invocations are remote, and new
invocations are local.  For REST, invocations don't happen over the network at
the "application-semantic" level, unless it's GET, PUT, POST, or DELETE.

Whether the data requested in old #5 or new #6 is fetched remotely may depend on
features like: throttles, caching rules, filtering ACL policies, existence of
proxies, etc.  With the old method, it seems that snapping in these features
would become dismally over-complicated.  Since the new method does all method
invocations locally, the semantics of these features sit at the HTTP level,
which is a very RESTful and *much* simpler approach.

Additional, detailed differences between the two approaches could take up
several pages.  Comments/thoughts on the contrast?  Should we post something
more polished like it on RESTwiki?

-Philip







-----------------------------------------------------------------------------------
Post ID:1726
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-08 03:15:30
Subject:REST and HTTP
Message:

Okay, I have only just joined this group (and rest-explore), so bear with me
as I get up to speed here.

I have been reading (and reading and reading) information on REST.  I have
watched an endless number of REST-related debates on xml-dev.  I have
probably seen just about ever argument made for and against REST.  At times,
I have thought I understood REST enough to see its value.  At other times, I
have looked at REST and seen nothing of value.  And in the end, I am exactly
where I started off.

Maybe this has to do with the fact that every time I see REST, it is joined
at the hip with HTTP.  I know that REST is a methodology and HTTP is an
implementation.  I also know that a lot of people say that HTTP is an
example of REST.  But that's where the relationship stops for me.  HTTP (in
it's original incarnation, as I understand it) had a very simple purpose:
provide a simple technique to allow researchers to share their works with
other researchers.  The purpose of HTTP was simple.  The implementation of
HTTP was simple.  But, as far as I can see, the fact that it is RESTful is
just as much a coincidence as anything else.  So, if this is the case, why
does everyone keep getting hung up on HTTP when discussing REST?

It seems to me that the "REST effort" would progress much better if all
conversations would just drop HTTP and talk about implementations in
general.  I think that a lot of people (including myself) end up having a
hard time determining if an argument is about REST or the "RESTfulness of
HTTP".  HTTP may be a good example of the REST principles, but that's all it
should be.  Maybe we could come up with (assuming there isn't already) a
fictitious RESTful implementation (NOT BASED ON HTTP) that would allow
discussions of REST without losing focus or making it difficult for us newer
guys to figure out which is about REST and which is about something related
to REST.

---
Seairth Jacobs
seairth@...

p.s. I'm not looking for a flame war here.  I just want to figure out what
REST is all about without having to deal with the excess baggage of HTTP.







-----------------------------------------------------------------------------------
Post ID:1727
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-08 03:18:18
Subject:REST and URIs
Message:

Quite often, URIs (especially the URL subset) are used has "noun" examples
when discussing REST.  Is this due to the fact that most discussions are
also talking about HTTP (see my last post), or is there something about a
URI that is particularly RESTful in of itself?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:1728
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-08 03:43:11
Subject:An attempt at a RESTful implementation
Message:

I do not know whether this is more appropriate for this list or the
rest-explore list.  I have written down some ideas I had a while back.
While writing it down, I tried to keep REST (as I understood it at the time)
in mind during some of the design process.  I would be curious to see what
others thought about how RESTful this is or is not and what would improve
it's RESTfulness.  If nothing else, this may allow me to better understand
REST principles at work by looking at something in a context I am familiar
with (that isn't HTTP).  Note that this is a draft document (and all that
goes with it).

http://www.seairth.com/web/rpc/gtp.html

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:1729
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-08 05:36:46
Subject:Re: [rest-discuss] REST and HTTP
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

> The purpose of HTTP was simple.  The implementation of
> HTTP was simple.  But, as far as I can see, the fact that it is RESTful is
> just as much a coincidence as anything else.
HTTP was simple. And it succeeded. And it grew. And it /continued/ to
succeed. Why was that?
If you list the reasons, and give that list a name, you will have 'named'
the principles of the Web architecture.
Roy just happened to call it REST.
In other words - HTTP happened first, REST was the name made up to explain
it.

> So, if this is the case, why
> does everyone keep getting hung up on HTTP when discussing REST?
Not every discussion of REST falls back on HTTP. I've talked a small amount
about using JMS with REST concepts - addressability, minimal methods,
multiple representations for an entity, etc. Refering back to HTTP is just a
way of giving concrete examples and avoiding academic ivory towers.

> It seems to me that the "REST effort" would progress much better if all
> conversations would just drop HTTP and talk about implementations in
> general.  I think that a lot of people (including myself) end up having a
> hard time determining if an argument is about REST or the "RESTfulness of
> HTTP".  HTTP may be a good example of the REST principles, but that's all
it
> should be.  Maybe we could come up with (assuming there isn't already) a
> fictitious RESTful implementation (NOT BASED ON HTTP) that would allow
> discussions of REST without losing focus or making it difficult for us
newer
> guys to figure out which is about REST and which is about something
related
> to REST.
Okay. Start a page on the Wiki. But remember, an implementation of REST
shines when it is large-scaled and network based -
single-user/single-machine APIs have a lot of other issues and tradeoffs
that make REST not a clear choice.







-----------------------------------------------------------------------------------
Post ID:1730
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-08 05:39:57
Subject:Re: [rest-discuss] REST and URIs
Message:



> Quite often, URIs (especially the URL subset) are used has "noun" examples
> when discussing REST.  Is this due to the fact that most discussions are
> also talking about HTTP (see my last post), or is there something about a
> URI that is particularly RESTful in of itself?

For me, REST is a about remote, untouchable 'resources' - and in order to
interact with them, they need to be identified. This 'identity' aspect seems
fundamental to REST. And it seems easier to talk about noun-oriented things
when you talk about things with identity. Really /anything/ can be
identified - methods, operations, transactions, etc. - but when you have
identity, it seems to 'noun-ify' whatever you are talking about.






-----------------------------------------------------------------------------------
Post ID:1731
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-08 05:50:41
Subject:Re: [rest-discuss] An attempt at a RESTful implementation
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>



> I do not know whether this is more appropriate for this list or the
> rest-explore list.  I have written down some ideas I had a while back.
> While writing it down, I tried to keep REST (as I understood it at the
time)
> in mind during some of the design process.  I would be curious to see what
> others thought about how RESTful this is or is not and what would improve
> it's RESTfulness.  If nothing else, this may allow me to better understand
> REST principles at work by looking at something in a context I am familiar
> with (that isn't HTTP).  Note that this is a draft document (and all that
> goes with it).
>
> http://www.seairth.com/web/rpc/gtp.html
>
Cool.

>> "In data manipulation, there are five basic possible actions: ADD, EDIT,
DELETE, GET, and PUT"
Coming up with basic actions for data manipulation is a great start. I've
had problems with the particular ones from HTTP, as well as the ones from
SQL.
With ADD, what are you adding data to? Why isn't there a remove?

Interesting...
I'll have to take some time with this paper. Thanks.










-----------------------------------------------------------------------------------
Post ID:1732
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-08 13:49:53
Subject:Re: [rest-discuss] An attempt at a RESTful implementation
Message:

From: "S. Mike Dierken" <mdierken@...>
> >> "In data manipulation, there are five basic possible actions: ADD,
EDIT,
> DELETE, GET, and PUT"
> Coming up with basic actions for data manipulation is a great start. I've
> had problems with the particular ones from HTTP, as well as the ones from
> SQL.
> With ADD, what are you adding data to? Why isn't there a remove?

The actual use of the verbs is somewhat relative to the application.  In the
case of ADD, it is only useful in a situation where you want to "add"
something to the target.  For instance, you might "add" a contact to a
contacts resource.  Using PUT is not necessarily sufficient here because you
still have to indicate that you want to add the resource.

DELETE is the "remove".

Truthfully, data entry only has four verbs (3 push/1 pull): ADD, EDIT,
DELETE, GET.  However, a problem one encounters in a loosely coupled system
is that we don't always know which push verb to use.  This is why I include
the PUT operation.  This allows the source to "loosely" send data to the
target.

I should also point out that the verbs chosen in GTP are not related to HTTP
verbs in any way, though a few are named the same.

> Interesting...
> I'll have to take some time with this paper. Thanks.

Yes, take a look.  I have tried to show some examples to clarify the verbs.
If you want more, I'd be happy to give more.  Give me a scenario and let me
see if I can "implement" it in GTP.


Also, what do you think of the [potential] RESTfulness of GTP?  Am I at
least in the ballpark, as far as you see it?  Or is this approach not what
REST is about?  I do have some doubts about the relationship between  REST
"state transfers" and GTP.

---
Seairth Jacobs
seairth@...








-----------------------------------------------------------------------------------
Post ID:1733
Sender:Bruce.Durling@...
Post Date/Time:2002-07-08 16:05:34
Subject:Is REST CRUD?
Message:

Pardon my ignorance, but while we are getting all Zen here...Is REST just
CRUD?

|| 'CRUD'  || 'REST' ||
|| Create  || PUT    ||
|| Read    || GET    ||
|| Update  || POST   ||
|| Delete  || DELETE ||

Add to this globally unique UID's (via lovely URI's) and you turn the whole
world into one large addressable database where each thing is a BLOB. It
seems simple yet earth shattering to me. Think of all the glue I can write
now. ;)

Is this too simple? Am I missing something? Is google the new SQL?

cheers,
bld



This message contains information from Equifax, Inc. which may be
confidential and privileged.  If you are not an intended recipient, please
refrain from any disclosure, copying, distribution or use of this
information and note that such actions are prohibited.  If you have
received this transmission in error, please notify by e:mail
postmaster@....







-----------------------------------------------------------------------------------
Post ID:1734
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-08 17:00:59
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

----- Original Message -----
From: <Bruce.Durling@...>


> Pardon my ignorance, but while we are getting all Zen here...Is REST just
> CRUD?
>
> || 'CRUD'  || 'REST' ||
> || Create  || PUT    ||
> || Read    || GET    ||
> || Update  || POST   ||
> || Delete  || DELETE ||
>
> Add to this globally unique UID's (via lovely URI's) and you turn the
whole
> world into one large addressable database where each thing is a BLOB. It
> seems simple yet earth shattering to me. Think of all the glue I can write
> now. ;)
>
You are very close - the specific meaning of each operation /is/ different,
but the analogy is sound. Unfortunately RDBMS doesn't have uniform/universal
addressing - at least I personally don't know how to use SQL to talk about
(and operate upon) databases, tables, columns, etc.

In terms of SQL (I don't know if the CRUD words match the SQL operators...)
PUT = "Upsert" (Update or Insert as necessary)
DELETE = Delete
POST = Insert (and maybe Alter Table, Create Table)
GET = Select








-----------------------------------------------------------------------------------
Post ID:1735
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-08 17:12:43
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

Bruce.Durling@... wrote:
> 
> Pardon my ignorance, but while we are getting all Zen here...Is REST just
> CRUD?

This is a meme I'm starting to promote.

>...
> Add to this globally unique UID's (via lovely URI's) and you turn the whole
> world into one large addressable database where each thing is a BLOB. It
> seems simple yet earth shattering to me. Think of all the glue I can write
> now. ;)

Even better, think of all of the glue you can avoid writing, because
interoperability falls out of the architecture. ;)

> Is this too simple? Am I missing something? Is google the new SQL?

I would say that HTTP is to networked applications what SQL is to
relational databases. It's an important analogy but it is more than an
analogy. The "few methods" concept seems to fall out of the universe
itself.

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1736
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-07-08 17:28:37
Subject:RE: [rest-discuss] Is REST CRUD?
Message:

It's important to point out that while the CRUD analogy is good, it's
only good with respect to the generic interface part of the
architecture.  REST is about more than just the generic interface.
 
MB





-----------------------------------------------------------------------------------
Post ID:1737
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-08 17:45:16
Subject:Re: [rest-discuss] "Application Protocols" -- an analogy
Message:

Miles Sabin wrote:
> 
>...
> 
> Sadly not the case.
> 
> The best illustration of HTTP's coupling with TCP is the definition of
> the value of the mandatory Host: request header (see RFC 2616, 14.23).
> Even tho' TCP isn't explicitly mentioned it's hard to make sense of
> without the assumption of TCP as the underlying transport protocol.
> Implicit couplings to TCP show up elsewhere in the spec (particularly
> in section 8) and also in related RFCs (eg. 2109). IMO HTTPs alleged
> transport independence is mostly window dressing.

IMO, transport independence is mostly hype anyways. IP needs to be
transport independent. But above IP, I don't see that it really ends up
mattering. If you want to use HTTP, you might as well roll out TCP and
IP because they will be useful for other things anyways!
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1738
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-08 18:07:54
Subject:Re: [rest-discuss] An attempt at a RESTful implementation
Message:

On 7/8/02 8:49 AM, "Seairth Jacobs" <seairth@...> wrote:

> Truthfully, data entry only has four verbs (3 push/1 pull): ADD, EDIT,
> DELETE, GET.  However, a problem one encounters in a loosely coupled system
> is that we don't always know which push verb to use.  This is why I include
> the PUT operation.  This allows the source to "loosely" send data to the
> target.
> 
> I should also point out that the verbs chosen in GTP are not related to HTTP
> verbs in any way, though a few are named the same.

Seairth, I dont mean to stir the pot, but what you've just described *is*
semantically equivalent to HTTP.  It seems to me that you only differ on the
detail and "syntax," not the high-level semantics.  To wit:

GTP       HTTP
------    -----
GET       GET
DELETE    DELETE
EDIT      PUT or POST
ADD       PUT or POST
PUT       xxx response code

The major exception seems to be that you have a notion of a "response
method" indicated by PUT.  I'm not sure what that buys you, really.

Consider:  HTTP PUT creates / replaces / updates the state of a resource
given some data (representation) of the desired resource state.  When
performed on an enclosing container resource, this can be considered an ADD.
Similarly, when performed on any existing resource, it's an EDIT.  Your PUT,
in the backchannel case, is basically equivalent to (a single, nonspecific)
HTTP response code --- truthfully, it doesn't serve much purpose at all,
because subsequent information would be needed to discern the actual intent
/ meaning of the resource.

In general, your model - as with HTTP applications that use PUT - seems to
work with a less abstract notion of resource than i.e. applications that
encapsulate resource state behind GET and POST;  with POST-based apps, you
can't ever actually set the state of a resource directly, at best you ask
the resource or its container to do that for you.  You never GET resource
state directly, you merely get a representation.  And that encapsulation is
a good thing.  Your model is actually weaker than HTTP, because it doesn't
accommodate the more abstract application of POST, meaning "feed some
arbitrary data to a resource" with the resource itself being responsible for
the interpretation.  (If PUT is a valid GTP *request* method, then GTP isn't
weaker --- it's semantically equivalent, as originally asserted.)

Similarly, I'm not sure what ONX buys you over XML.  In both cases
(GTP/HTTP, ONX/XML) the differences seem superficial at best.

I don't mean to dis your effort, but it's worth asking whether your effort
wouldn't be better spent trying to get what you want to do done with HTTP
and XML rather than reinventing them.  We see further when we stand on the
shoulders of giants. :-)

$0.02,

Jb







-----------------------------------------------------------------------------------
Post ID:1739
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-08 18:12:40
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

----- Original Message -----
From: "Mark Baker" <mbaker@...>
To: <Bruce.Durling@...>; <rest-discuss@yahoogroups.com>
Sent: Monday, July 08, 2002 10:28 AM
Subject: RE: [rest-discuss] Is REST CRUD?


> It's important to point out that while the CRUD analogy is good, it's
> only good with respect to the generic interface part of the
> architecture.  REST is about more than just the generic interface.
>

Yes - I forgot to mention that in my e-mail... a RDBMS is solving a
different problem, so it won't have the same list of architectural
characteristics as REST, but the flexibility to implement any
application-specific operation on top of CRUD is similar to the ability to
implement any application-specif operation on top of GPPD
(GET/PUT/POST/DELETE).






-----------------------------------------------------------------------------------
Post ID:1740
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-08 18:25:06
Subject:Re: [PMX:#] [rest-discuss] REST and HTTP
Message:

Seairth Jacobs wrote:
> 
>...
> 
> Maybe this has to do with the fact that every time I see REST, it is joined
> at the hip with HTTP.  

This bothers many people but it is important to understand that one of
the central virtues of REST is *standardization* of interfaces. It isn't
the case that any protocol with generic interfaces is equal to any other
one. The one that is deployed is (all else equal) MUCH BETTER because of
the interoperability you get out of using it.

> ... I know that REST is a methodology and HTTP is an
> implementation.  I also know that a lot of people say that HTTP is an
> example of REST.  But that's where the relationship stops for me.  HTTP (in
> it's original incarnation, as I understand it) had a very simple purpose:
> provide a simple technique to allow researchers to share their works with
> other researchers.  

But what does it matter what HTTP was intended to do 12 years ago. HTTP
has evolved quite a bit if you look at the specifications. There is
nothing in those specifications that is specific to some particular
problem domain.

>...
> It seems to me that the "REST effort" would progress much better if all
> conversations would just drop HTTP and talk about implementations in
> general.  

Until there is a second REST-designed protocol, HTTP *is* about as
general as we can get. Plus, a big attraction of REST to me is the power
of HTTP tools.

 * http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0074.html

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1741
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-07-08 18:31:07
Subject:RE: [rest-discuss] Is REST CRUD?
Message:

Right.
 
But you bring up another point that anybody promoting (or using) the
generic interface should remember; GET/POST/PUT/DELETE *might* be
sufficient (actually, GET and POST might be), but REST says that the
interface can be extended if you want to, so long as the new method is
generic to all resources, like LOCK, WATCH, etc..
 
Though I can understand not mentioning this first to emphasize how
general the existing methods are, and to get people thinking about how
to solve their problems using only those methods.  Perhaps at the end of
the talk or whatever, just say "oh yah, and you can add new methods".
8-)
 
MB

	-----Original Message----- 
	From: S. Mike Dierken 
	Sent: Mon 7/8/2002 2:12 PM 
	To: Bruce.Durling@equifax.com; rest-discuss@yahoogroups.com;
Mark Baker 
	Cc: 
	Subject: Re: [rest-discuss] Is REST CRUD?
	
	


	----- Original Message ----- 
	From: "Mark Baker" <mbaker@idokorro.com> 
	To: <Bruce.Durling@equifax.com>; <rest-discuss@yahoogroups.com> 
	Sent: Monday, July 08, 2002 10:28 AM 
	Subject: RE: [rest-discuss] Is REST CRUD? 


	> It's important to point out that while the CRUD analogy is
good, it's 
	> only good with respect to the generic interface part of the 
	> architecture.  REST is about more than just the generic
interface. 
	> 

	Yes - I forgot to mention that in my e-mail... a RDBMS is
solving a 
	different problem, so it won't have the same list of
architectural 
	characteristics as REST, but the flexibility to implement any 
	application-specific operation on top of CRUD is similar to the
ability to 
	implement any application-specif operation on top of GPPD 
	(GET/PUT/POST/DELETE). 






-----------------------------------------------------------------------------------
Post ID:1742
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-08 19:56:30
Subject:RE: [rest-discuss] Is REST CRUD?
Message:

Paul,

> -----Original Message-----
> From: Paul Prescod [mailto:paul@prescod.net] 
>
> Bruce.Durling@... wrote:
> > 
> > Pardon my ignorance, but while we are getting all Zen 
> here...Is REST 
> > just CRUD?
> 
> This is a meme I'm starting to promote.

And don't stop at CRUD.

Here's about as far as I got to in terms of similarities, and I'm sure
you could tweak it to make a bit more sense. My interest was in mapping
Linda onto HTTP. 

http		sql 		linda		jspaces	cvs

GET	 	SELECT		rd/in		read
update/checkout
PUT		CREATE        out		write		add
POST		UPDATE        out		write		commit
DELETE		DELETE        cin		take		remove
noop		(triggers)	noop		notify
(sendmail ;)


Miles Sabin (cc'd) said once it might possible to use DDDS to support a
global tuplespace; his interest was mapping Linda onto Rest. Noteworthy:
Linda doesnt have a single namespace, which is a mistake Mark Baker
pointed out to me a while back.

What Mark Baker said is important though; few methods is just one aspect
of Rest.

As an aside: a lot of process synchronization problems can be handled by
applying best practices for CVS, rather than global locking schemes (as
per SourceSafe), which maybe wouldn't be planetary scalable anyway.
Javaspaces has done a good job on the semantics for synchronization on
read and write ops. 

Bill de hra

..
Propylon
www.propylon.com 

 










-----------------------------------------------------------------------------------
Post ID:1743
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-08 20:20:01
Subject:Re: [rest-discuss] HTTP/Linda, and versioning/locking rant
Message:

On 7/8/02 2:56 PM, "Bill de hra" <dehora@...> wrote:


> Noteworthy:
> Linda doesnt have a single namespace, which is a mistake Mark Baker
> pointed out to me a while back...

IMO, the right mapping from Linda->the Web does *not* assume that the Web
itself constitutes a global tuplespace.  After all, Linda's methods (in, rd,
out) are operations on a tuplespace;  the Web's GET, POST, DELETE are
operations on resources, not on the Web as a whole (whatever that means).
So the right mapping is tuplespace->resource, not tuplespace->HTTP
namespace.  The HTTP namespace merely provides an arbitrarily large number
of named tuplespaces, i.e. resources.  Equivalently, resources aren't
tuples, they're tuplespaces.

A more detailed explanation of a Webby Linda mapping can be found at

    http://internet.conveyor.com/RESTwiki/moin.cgi/LindaAndTheWeb

> As an aside: a lot of process synchronization problems can be handled by
> applying best practices for CVS, rather than global locking schemes (as
> per SourceSafe), which maybe wouldn't be planetary scalable anyway.

<RANT>

Not exasperated with you particularly, Bill, but let me rant for a sec:

Could we all get over this whole idea of locking as necessary or desirable
for versioning, avoiding conflict in object evolution, etc.?  It's a
side-effect of a bad storage metaphor, namely that stored entities are
mutable.  Stored entities need not be mutable:  imagine a filesystem in
which stored files are immutable, identified by OIDs (maybe hashes), and
accessible directly via those names or more conveniently via names.  What's
mutable is the file name->stored objects (i.e. bits), and indeed a canonical
mapping must be maintained, but that can be done heuristically.  With the
addition of a stream of representations of mutations in the name->stored
object mappings --- something like a filesystem journal --- it is possible
to have complete and implicit file versioning.

The evolutionary history of a given file is then an arbitrarily bushy tree
of immutable stored entities, and the "canonical" version is just the
particular version that happens to be pointed to by some name in a
hierarchical namespace at some given time.  The history / version graph
itself can be reconstructed from the journal and consulted / heuristics
applied to generate the canonical mapping in the case of conflicts.

If we factor the notions of naming and storage and assume immutability, then
the problem isn't just solved, it *disappears.*  Really.  This is one of
those problems we can just define away by appropriate abstraction.

Check out Tannenbaum's Amoeba operating system and its fileserver ("bullet")
/ directory server architecture.  Also, Plan 9 has a new archival filesystem
architecture called Venti that applies essentially the same concepts to
block-level storage.

These issues are rather near and dear to my heart --- they're part of the
Deepfile "Big Picture."  I just cringe whenever people talk about
versioning, locking, DAV, CVS, etc. because most people don't recognize that
these are only band-aids on what is fundamentally a sick and empoverished
filesystem metaphor.

</RANT>

Cheers!

Jb







-----------------------------------------------------------------------------------
Post ID:1744
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-08 20:49:08
Subject:XML/XHTML analogy
Message:

I was trying to draw a protocol analogy to XML/XHTML.  The best I could
come up with was;

XML is to XHTML as HTTP is to Yahoo.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1745
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-08 21:08:02
Subject:RE: [rest-discuss] HTTP/Linda, and versioning/locking rant
Message:

> Jeff Bone: 
> These issues are rather near and dear to my heart --- they're 
> part of the Deepfile "Big Picture."  I just cringe whenever 
> people talk about versioning, locking, DAV, CVS, etc. because 
> most people don't recognize that these are only band-aids on 
> what is fundamentally a sick and empoverished filesystem metaphor.

Jeff,

I didn't recognise that and I'm glad you said it. I do think filesystems
(or rather directories) are a pretty impoverished as a user interface. I
hate having to micro-manage files by naming versions of them and
figuring out what directories they should go into. I also imagine you've
got opinions on Lifestreams?

Bill de hra

..
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:1746
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-07-08 23:09:36
Subject:REST and Linda? (WAS: [rest-discuss] Is REST CRUD?)
Message:

Bill de h�ra wrote,
> Miles Sabin (cc'd) said once it might possible to use DDDS to support
> a global tuplespace; his interest was mapping Linda onto Rest.

I take that back ;-)

I think I now now how to build a fully distributed tuple space, but it 
doesn't bear any particularly interesting relationship to HTTP or REST 
(hint, take a peek at http://citeseer.nj.nec.com/460728.html). And I 
now also think that some REST idioms are much more closely related to 
Pi Calculus than anything else (tho', to be honest, that's probably 
stretching things a bit).

REST interests me a bit, but mostly for reasons that are likely to be 
anathema to dyed in the wool RESTians ...

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:1747
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-08 23:17:55
Subject:Re: [rest-discuss] An attempt at a RESTful implementation
Message:

From: "Jeff Bone" <jbone@...>
>
> Seairth, I don�t mean to stir the pot, but what you've just described *is*
> semantically equivalent to HTTP.  It seems to me that you only differ on
the
> detail and "syntax," not the high-level semantics.  To wit:
>
> GTP       HTTP
> ------    -----
> GET       GET
> DELETE    DELETE
> EDIT      PUT or POST
> ADD       PUT or POST
> PUT       xxx response code
>
> The major exception seems to be that you have a notion of a "response
> method" indicated by PUT.  I'm not sure what that buys you, really.

Actually, GTP is a good deal different from HTTP (at least as I see it).
One of the primary differences is that it is not necessarily a client-server
protocol.  It is perfectly correct send a PUT message and get a DELETE
message in return.  In other words, there is no set relationship between
what message is received based and what message was sent.  This is an
application-specific issue, not a protocol issue.  HTTP has a distinctive
client and server parts.  Yes, it is possible to have a given application
implement both parts and effectively allow for peer-to-peer communication.
But, to my knowledge, this was not the intent of HTTP (and more or less
still isn't).  On the other hand, it is entirely forseeable to design
peer-to-peer, client-server, etc. applications in GTP.

If you were to map GTP verbs to HTTP verbs (sticking to the client-server
pattern only), you would probably end up with:

HTTP        GTP
-----          -----
GET          GET
DELETE   DELETE
PUT          GET, conditionally followed by an ADD or EDIT
POST       PUT
response   PUT, always used as the "response" from the "server"


Again, a request can potentially receive a response that uses any of the
verbs.  PUT is just the most generic response and is equatable to HTTP
responses *when implementing an HTTP-like GTP-based application*.  The real
strength is in being able to get back any sort of message.  Here are some
examples:

* Two peer-to-peer programs could use PUT to send heartbeats to one another.
* An "offline address book" client application could send a PUT message to a
server, which would return an EDIT message to instruct the client to update
one or more local entries.
* A client application could initiate a session with a GET message.  The
server may then respond with a GET message indicating that it wants to know
more about the client capabilities.  The client would then respond with a
PUT message.
* One server (A) could be queuing requests to go to another server (B).
Server A might start with a PUT message to Server B to indicate its status.
Server B would then issue a GET message for the next message in the queue.
Server A would then send whatever message was queued.  This process would
repeat itself until Server A sent a final PUT message indicating that there
are no more queued messages.

It may be possible to force implementation all of the above on top of HTTP,
but that feels to me like the proverbial "square peg in a round hole".  This
is why I do not consider GTP and HTTP to be "semantically equivalent".

> Consider:  HTTP PUT creates / replaces / updates the state of a resource
> given some data (representation) of the desired resource state.  When
> performed on an enclosing container resource, this can be considered an
ADD.
> Similarly, when performed on any existing resource, it's an EDIT.  Your
PUT,
> in the backchannel case, is basically equivalent to (a single,
nonspecific)
> HTTP response code --- truthfully, it doesn't serve much purpose at all,
> because subsequent information would be needed to discern the actual
intent
> / meaning of the resource.

Part of this, I think I have already answered up top.  As for the HTTP PUT
verb being an "ADD if not exist, otherwise EDIT", I have always had issues
with this.  PUT is the logical equivalent of:

    IF GET
        EDIT
    ELSE
        ADD
    END

In my opinion (for what little that is worth), HTTP PUT is a "lazy" verb.
You are attempting to perform a compoung command using a single command.
This seems to me to be a particularly non-RESTian verb.

> In general, your model - as with HTTP applications that use PUT - seems to
> work with a less abstract notion of resource than i.e. applications that
> encapsulate resource state behind GET and POST;  with POST-based apps, you
> can't ever actually set the state of a resource directly, at best you ask
> the resource or its container to do that for you.  You never GET resource
> state directly, you merely get a representation.  And that encapsulation
is
> a good thing.  Your model is actually weaker than HTTP, because it doesn't
> accommodate the more abstract application of POST, meaning "feed some
> arbitrary data to a resource" with the resource itself being responsible
for
> the interpretation.  (If PUT is a valid GTP *request* method, then GTP
isn't
> weaker --- it's semantically equivalent, as originally asserted.)

Okay, given that GTP PUT can be used like HTTP POST and that GTP is not like
HTTP, would you still say that GTP is still weaker?    GTP allows the
"representation" of a resource to be sent instead of the resource itself.  A
GTP message can never perform an action.  Only the recipient can determine
what actions can and can't be taken.  Only the recipient performs the actual
action.  To me, this is REST-like abstraction.  The actual level of
abstraction reached depends entirely on the actual implementation of a
GTP-enabled application.  GTP just makes the facilities available.

You know, I am almost beginning to get an idea. Maybe GTP is more of a
generic foundation protocol.  GTP itself is neither RESTful not non-RESTful.
Instead, it provides a foundation on which RESTful applications can be built
(a la HTTP-alike).  HTTP is more of a combination of a protocol and an
application in this sense.  Increasingly, people are using HTTP less as an
application and more as a foundation protocol.  The difference is that GTP
is designed from the ground up to provide only the foundation and leaves the
 actual REST implementation to the application level that sits on top of it.
On the other hand, maybe I am just fooling myself here.  :)

> Similarly, I'm not sure what ONX buys you over XML.  In both cases
> (GTP/HTTP, ONX/XML) the differences seem superficial at best.

Yes, ONX is similar to XML.  However, the devil is in the details.  ONX is
specifically designed to accomodate data in ways that XML is unsuited for.
It is also designed to be more efficiently parsable.  This allows for faster
processing times and faster network transmission times.  As I point out in
the GTP introduction, GTP could be written with XML as well.  "ONX vs. XML"
is not the issue here.

> I don't mean to dis your effort, but it's worth asking whether your effort
> wouldn't be better spent trying to get what you want to do done with HTTP
> and XML rather than reinventing them.  We see further when we stand on the
> shoulders of giants. :-)

And yet, if HTTP and XML were truly the "dynamic duo" that everyone wants to
believe they are, this list (and several others) wouldn't exist.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:1748
Sender:"Robert O'Brien" <robrien@...>
Post Date/Time:2002-07-08 23:24:13
Subject:RE: [rest-discuss] Is REST CRUD?
Message:

> Mark Baker wrote:
>
> It's important to point out that while the CRUD analogy is good, it's
> only good with respect to the generic interface part of the
> architecture.  REST is about more than just the generic interface.

> S. Mike Dierken wrote:
>
> Yes - I forgot to mention that in my e-mail... a RDBMS is solving a
> different problem, so it won't have the same list of architectural
> characteristics as REST, but the flexibility to implement any
> application-specific operation on top of CRUD is similar to the ability to
> implement any application-specif operation on top of GPPD
> (GET/PUT/POST/DELETE).

I find the idea of a Resource having many Representations bears many
similarities to the idea of a Logical Entity (as in logical vs. physical
models) in Relational Theory. In SQL, views provide representations of
logical entities that may span many physical tables. Obviously the mechanism
for identifying and resolving an entity is different to identifying and
resolving a resource but the principles seem similar. Can a *View* in SQL be
considered a rough equivalent to a *Representation* of a resource in REST?

Unfortunately SQL Databases don't allow updates through views that span
multiple tables. Therefore a true separation of the logical model from the
physical model has never been fully realised :-( Fortunately for a REST+HTTP
based architecture this separation seems to be fundamental in the sense that
I can PUT/POST one representation to a resource (assuming of course that the
resource understands and supports them) and GET a different one back based
on Content Negotiation, Etags or URI query parameters.

Robert.








-----------------------------------------------------------------------------------
Post ID:1749
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-09 00:07:19
Subject:Re: [rest-discuss] An attempt at a RESTful implementation
Message:

>> The major exception seems to be that you have a notion of a "response
>> method" indicated by PUT.  I'm not sure what that buys you, really.
> 
> Actually, GTP is a good deal different from HTTP (at least as I see it).
> One of the primary differences is that it is not necessarily a client-server
> protocol.  

The distinction between client-server and peer-to-peer has everything to do
with overall system architecture - with the roles the various components
play in the context of a single interaction - and, really, very little to do
with the underlying protocol.  Having built, I think, the first
Internet-scale commercial p2p app (Ding!), I think I can safely make some
assertions, here. ;-)

I've generally found C-S to be an inadequate distinction --- really, you
want to think about whether components initiate or service a request in a
given interaction;  a component that plays the role of a server in one
interaction might be a client in the next;  indeed, proxy components play
both roles in the context of a single conceptual interaction (server to the
initiating client, client to the origin server.)

Another distinction is whether responses are synchronous or asynchronous (or
both) with requests --- this issue is orthogonal but related to C-S v. p2p.
As discussed ad nauseam early in this list's lifecycle, either is sufficient
to model the other.

The short version is that you don't need new protocols beyond HTTP to do
things like "p2p" or async --- assuming that the semantics of the supported
methods are equivalent.  The protocol should describe the interactions
between components at a semantic level.

Again, given the similarity between the semantics, I see no need for a new
application protocol.

> It may be possible to force implementation all of the above on top of HTTP,
> but that feels to me like the proverbial "square peg in a round hole".

:-/

I see nothing in your list that can't be modeled IMHO even more simply just
by assuming you have resources chatting with each other over HTTP.  But that
may be because resource modeling in terms of HTTP has become second nature
by now...  It's a hard thing to grok, but seriously:  whenever in the past
I've thought HTTP provided a more complex or unnatural or grotty model for
something, I've been wrong.  Having helped propagate at least one non-HTTP
app protocol (whodp) and lived to regret it, I'm seriously leery of any new
protocols.

HTTP is incredibly general, and it doesn't have the constraints and
implications that most programmers intuitively think it has.

>   IF GET
>       EDIT
>   ELSE
>       ADD
>   END
> 
> In my opinion (for what little that is worth), HTTP PUT is a "lazy" verb.
> You are attempting to perform a compoung command using a single command.
> This seems to me to be a particularly non-RESTian verb.

I don't think I understand what you've said, but I'm pretty sure we don't
agree on the meaning of HTTP's PUT.

> Okay, given that GTP PUT can be used like HTTP POST and that GTP is not like
> HTTP, would you still say that GTP is still weaker?

I can't get past the second:  I'm still certain that GTP is essentially
equivalent to HTTP, the differences merely rooted in misunderstanding of
HTTP.

> GTP allows the
> "representation" of a resource to be sent instead of the resource itself.

That's the basis of HTTP --- resources are NEVER, EVER sent.  Only
representations.  

> Yes, ONX is similar to XML.  However, the devil is in the details.  ONX is
> specifically designed to accomodate data in ways that XML is unsuited for.

You know, everytime I run into this argument, nobody can ever come up with
datatypes that XML is *actually* unsuitable for.  (Graph structures are
incredibly general...)

> It is also designed to be more efficiently parsable.

Some research by some guys at IBM Almaden a year or so ago proved that the
efficiency issue -wrt- parsing XML is wildly overstated.  For the average
bit of XML, it's statistical noise in the overall performance picture.

> And yet, if HTTP and XML were truly the "dynamic duo" that everyone wants to
> believe they are, this list (and several others) wouldn't exist.

Methinks you misunderstand the purpose of this list...  It exists, in large
part, specifically to help propagate better understanding of HTTP's
generality and utility.  Resistance is futile. :-)  Reinventing the wheel is
one thing;  reinventing *wood* something else entirely. ;-)
Jb







-----------------------------------------------------------------------------------
Post ID:1750
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-07-09 00:41:41
Subject:RE: [rest-discuss] Is REST CRUD?
Message:

BTW, I've been thinking more about this, and there definitely some
similarities between REST's generic interface and the generic interface
of other systems, but there are some important differences too,
especially with SQL/CRUD and other data manipulation languages.  The
most important one, IMO is about "POST", and that while it can be used
for insertion/creation, it's really a very generic method for "accept
this data", which can be used to implement everything (except GET - PUT
and DELETE can be negotiated).
 
This is pretty different than SQL INSERT or CRUD "CREATE", since both
are explicit operations where the invoker has explicit a priori
knowledge of the state of the resource after a successful invocation.
With POST, that knowledge has to be negotiated.
 
Just something to keep in mind.
 
MB





-----------------------------------------------------------------------------------
Post ID:1751
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-09 00:54:29
Subject:Re: [rest-discuss] HTTP/Linda, and versioning/locking rant
Message:

----- Original Message -----
From: "Jeff Bone" <jbone@...>

> Could we all get over this whole idea of locking as necessary or desirable
> for versioning, avoiding conflict in object evolution, etc.?  It's a
> side-effect of a bad storage metaphor, namely that stored entities are
> mutable.  Stored entities need not be mutable:  imagine a filesystem in
> which stored files are immutable, identified by OIDs (maybe hashes), and

Somebody I respect a lot once said "Dynamism is an illusion". This was in
reference to versioning in Groves. Kind of similar I suppose...







-----------------------------------------------------------------------------------
Post ID:1752
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-09 00:58:52
Subject:Re: [rest-discuss] XML/XHTML analogy
Message:

How about "XHTML is to XML as C++ is to programming"
Or "XHTML is to XML as InternetExplorer is to C++"


----- Original Message ----- 
From: "Mark Baker" <distobj@...>
To: <rest-discuss@yahoogroups.com>
Sent: Monday, July 08, 2002 1:49 PM
Subject: [rest-discuss] XML/XHTML analogy


> I was trying to draw a protocol analogy to XML/XHTML.  The best I could
> come up with was;
> 
> XML is to XHTML as HTTP is to Yahoo.
> 
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> 
> 
> 






-----------------------------------------------------------------------------------
Post ID:1753
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-09 00:58:32
Subject:Re: [rest-discuss] HTTP/Linda, and versioning/locking rant
Message:

At 06:20 AM 9/07/2002, Jeff Bone wrote:

><RANT>
>
>Not exasperated with you particularly, Bill, but let me rant for a sec:

Thanks for responding to the need for that rant, very interesting stuff !

>On 7/8/02 2:56 PM, "Bill de h�ra" <dehora@...> wrote:
>
> > As an aside: a lot of process synchronization problems can be handled by
> > applying best practices for CVS, rather than global locking schemes (as
> > per SourceSafe), which maybe wouldn't be planetary scalable anyway.
>
>If we factor the notions of naming and storage and assume immutability, then
>the problem isn't just solved, it *disappears.*  Really.  This is one of
>those problems we can just define away by appropriate abstraction.

Since the OP specifically mentioned process synchronization, how does the
immutable approach make that disappear? More specifically how does it handle
the stale data/lost update problem? I can see that there is no such thing
as a lost update in the traditional sense, but how does it cope with that
scenario and still make sure that the 'current ' file contents are accurate?

Further, were you implying that immutability makes the problem of
people/processes working out of queue go away, e.g. in the workflow sense
that there is a shared queue of work needing to be done, with multiple
processes being fed from the queue, how does immutability help with this
sort of process synch'ing?

Robert








-----------------------------------------------------------------------------------
Post ID:1754
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-09 01:06:45
Subject:Re: [rest-discuss] An attempt at a RESTful implementation
Message:

>
> Part of this, I think I have already answered up top.  As for the HTTP PUT
> verb being an "ADD if not exist, otherwise EDIT", I have always had issues
> with this.  PUT is the logical equivalent of:
>
>     IF GET
>         EDIT
>     ELSE
>         ADD
>     END
>
> In my opinion (for what little that is worth), HTTP PUT is a "lazy" verb.
> You are attempting to perform a compoung command using a single command.
> This seems to me to be a particularly non-RESTian verb.

It's very RESTian in that the conditional is implemented on the server,
which allows the client to PUT data to a location known by the client in
advance - bypassing gnarly issues of ownership of IDs. The server becomes
stupid and the client becomes smart. Not all Web applications /have/ to be
built this way, but it is a very powerful way to build applications.








-----------------------------------------------------------------------------------
Post ID:1755
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-09 01:12:55
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

----- Original Message -----
From: "Robert O'Brien" <robrien@...>

>
> I find the idea of a Resource having many Representations bears many
> similarities to the idea of a Logical Entity (as in logical vs. physical
> models) in Relational Theory. In SQL, views provide representations of
> logical entities that may span many physical tables. Obviously the
mechanism
> for identifying and resolving an entity is different to identifying and
> resolving a resource but the principles seem similar. Can a *View* in SQL
be
> considered a rough equivalent to a *Representation* of a resource in REST?
I really don't think so.
A RDBMS view mainly changes schema with regard to naming and I think it's a
namespace operation - it changes the names by which you address/navigate the
data.

If you access the data with something like these:
 SELECT * from view_2 where key = $id
 SELECT * from view_3 where key = $id

then I think /that/ would be REST 'representation' - the resource ID hasn't
changed, only the content returned.

>
> Unfortunately SQL Databases don't allow updates through views that span
> multiple tables.
I bet there are companies that do that... but not many. I think Dr.
Stonebraker's last company did something like that.








-----------------------------------------------------------------------------------
Post ID:1756
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-09 01:39:44
Subject:Re: [PMX:#] [rest-discuss] REST and HTTP
Message:

From: "Paul Prescod" <paul@...>
> Seairth Jacobs wrote:
> >
> > Maybe this has to do with the fact that every time I see REST, it is
joined
> > at the hip with HTTP.
>
> This bothers many people but it is important to understand that one of
> the central virtues of REST is *standardization* of interfaces. It isn't
> the case that any protocol with generic interfaces is equal to any other
> one. The one that is deployed is (all else equal) MUCH BETTER because of
> the interoperability you get out of using it.

Sure, I understand that.  And if HTTP is truly RESTful, then I think it is a
good thing to make such a statement.  However, what I was saying was that it
seems like REST and HTTP are

>
> > ... I know that REST is a methodology and HTTP is an
> > implementation.  I also know that a lot of people say that HTTP is an
> > example of REST.  But that's where the relationship stops for me.  HTTP
(in
> > it's original incarnation, as I understand it) had a very simple
purpose:
> > provide a simple technique to allow researchers to share their works
with
> > other researchers.
>
> But what does it matter what HTTP was intended to do 12 years ago. HTTP
> has evolved quite a bit if you look at the specifications. There is
> nothing in those specifications that is specific to some particular
> problem domain.

I agree that HTTP has taken on a lot more over the years. However, it seems
to me that HTTP 1.1 contains a lot of features that are not necessarily
RESTful (e.g. persistant connections). In other words, I think that there is
a subset of HTTP 1.1 that is definitely RESTful.  However, HTTP 1.1
altogether does not seem quite as RESTful.  To claim that "HTTP is an
example of REST" implies (esp. to those who do not understand REST but do
understand HTTP) that HTTP and REST are a one-to-one relationship, which I
do not believe to be the case.  Earlier versions of HTTP were more RESTful.
The very fact that Fielding used HTTP as an example of REST shows that at
one point in the past REST and HTTP *were* one-to-one related.

Another way to look at this HTTP/REST thing is:  if HTTP is the only
implementation of REST that the REST-minded community will discuss, then why
do we even have REST in the first place?  REST is only useful as a concept
that could be generally applied.  Otherwise, it may as well be called "HTTP
Guidelines".

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:1757
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-09 02:04:46
Subject:Re: [rest-discuss] An attempt at a RESTful implementation
Message:

From: "Jeff Bone" <jbone@...>
>
> The distinction between client-server and peer-to-peer has everything to
do
> with overall system architecture - with the roles the various components
> play in the context of a single interaction - and, really, very little to
do
> with the underlying protocol.  Having built, I think, the first
> Internet-scale commercial p2p app (Ding!), I think I can safely make some
> assertions, here. ;-)
>
> I've generally found C-S to be an inadequate distinction --- really, you
> want to think about whether components initiate or service a request in a
> given interaction;  a component that plays the role of a server in one
> interaction might be a client in the next;  indeed, proxy components play
> both roles in the context of a single conceptual interaction (server to
the
> initiating client, client to the origin server.)
>
> Another distinction is whether responses are synchronous or asynchronous
(or
> both) with requests --- this issue is orthogonal but related to C-S v.
p2p.
> As discussed ad nauseam early in this list's lifecycle, either is
sufficient
> to model the other.
>
> The short version is that you don't need new protocols beyond HTTP to do
> things like "p2p" or async --- assuming that the semantics of the
supported
> methods are equivalent.  The protocol should describe the interactions
> between components at a semantic level.
>
> Again, given the similarity between the semantics, I see no need for a new
> application protocol.
>
> > It may be possible to force implementation all of the above on top of
HTTP,
> > but that feels to me like the proverbial "square peg in a round hole".
>
> :-/
>
> I see nothing in your list that can't be modeled IMHO even more simply
just
> by assuming you have resources chatting with each other over HTTP.  But
that
> may be because resource modeling in terms of HTTP has become second nature
> by now...  It's a hard thing to grok, but seriously:  whenever in the past
> I've thought HTTP provided a more complex or unnatural or grotty model for
> something, I've been wrong.  Having helped propagate at least one non-HTTP
> app protocol (whodp) and lived to regret it, I'm seriously leery of any
new
> protocols.
>
> HTTP is incredibly general, and it doesn't have the constraints and
> implications that most programmers intuitively think it has.

Okay, it sounds like you have worked with HTTP in ways that I have not.  If
this is the case, then you would obviously know how flexible HTTP is when
it's actually applied to a situation.  Maybe I need to sit down and look at
and work with HTTP in some of those same ways to see for myself...

> > Yes, ONX is similar to XML.  However, the devil is in the details.  ONX
is
> > specifically designed to accomodate data in ways that XML is unsuited
for.
>
> You know, everytime I run into this argument, nobody can ever come up with
> datatypes that XML is *actually* unsuitable for.  (Graph structures are
> incredibly general...)
>
> > It is also designed to be more efficiently parsable.
>
> Some research by some guys at IBM Almaden a year or so ago proved that the
> efficiency issue -wrt- parsing XML is wildly overstated.  For the average
> bit of XML, it's statistical noise in the overall performance picture.

Hmm... interesting.  Well, that is certainly something to think about (re
XML vs. ONX).  However, as I pointed out, GTP can just as easily sit on top
of XML, so it's not an issue as far as GTP discussions go.

> Methinks you misunderstand the purpose of this list...  It exists, in
large
> part, specifically to help propagate better understanding of HTTP's
> generality and utility.  Resistance is futile. :-)  Reinventing the wheel
is
> one thing;  reinventing *wood* something else entirely. ;-)

Yes, this is definitely true.  The list description is "Introductory-level
discussion about REpresentational State Transfer, the name given to the
architecture of the World Wide Web by Roy Fielding". Hmm...

Thanks for the feedback.  I am not convinced that GTP isn't a better
solution, but I do realize I need to take a better look at the workings of
HTTP.  :)

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:1758
Sender:"Robert O'Brien" <robrien@...>
Post Date/Time:2002-07-09 02:59:21
Subject:RE: [rest-discuss] Is REST CRUD?
Message:

> S. Mike Dierken wrote:

> A RDBMS view mainly changes schema with regard to naming and I
> think it's a namespace operation - it changes the names by which
> you ddress/navigate the data.

Agreed. I find the idea of logical vs. physical model separation as one way
to think of a resource and it's many 'representations'. For example when a
resouce needs to represent itself, in XML, using different schema.

> If you access the data with something like these:
>  SELECT * from view_2 where key = $id
>  SELECT * from view_3 where key = $id
>
> then I think /that/ would be REST 'representation' - the resource
> ID hasn't changed, only the content returned.

Agreed; I was assuming the use of a surrogate key for entity identity - a
common way of mapping objects to SQL DBMS - rather than the namespace
operations refered to above.

Robert.








-----------------------------------------------------------------------------------
Post ID:1759
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-09 05:08:45
Subject:Re: [PMX:#] [rest-discuss] REST and HTTP
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

> Another way to look at this HTTP/REST thing is:  if HTTP is the only
> implementation of REST that the REST-minded community will discuss, then
why
> do we even have REST in the first place?  REST is only useful as a concept
> that could be generally applied.  Otherwise, it may as well be called
"HTTP
> Guidelines".

This is a very good point. This discussion could (and probably should) be
boiled down into "HTTP Guidelines" - but the REST principles stand apart
from HTTP.
Personally, I have used the principles where I needed to build large-scale,
long-lived technology in support of products/applications - even when I
could not directly use HTTP for one reason or another. For example, I once
built a system using RDBMS and JMS to create a large scale subscription and
notification system - the characterstics it borrowed from REST were global
identifiers, generic interface and representations. The toughest part in
terms of education was when the limited operations in the interface caused
the identifiers to grow (via 'sub-properties') - that was too much for many
people to understand & they just wanted to put everything into one slot
(putting operation names into identifiers, etc).








-----------------------------------------------------------------------------------
Post ID:1760
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-09 05:15:20
Subject:Re: [rest-discuss] XML/XHTML analogy
Message:

Sorry, missed the 'protocol' part...
How about "XML is to XHTML as TCP/IP is to HTTP"
or "XML is to markup as HTTP is to distributed computing"
or "XML is to XHTML as HTTP is to AS2" (AS2 is a HTTP+MIME based biz doc
exchange protocol)
or "XML is to XHTML as HTTP is to Hotmail"

hmm... I think your analogy is the best... mine just don't make sense.


----- Original Message -----
From: "S. Mike Dierken" <mdierken@...>
To: <rest-discuss@yahoogroups.com>; "Mark Baker" <distobj@...>
Sent: Monday, July 08, 2002 5:58 PM
Subject: Re: [rest-discuss] XML/XHTML analogy


> How about "XHTML is to XML as C++ is to programming"
> Or "XHTML is to XML as InternetExplorer is to C++"
>
>
> ----- Original Message -----
> From: "Mark Baker" <distobj@...>
> To: <rest-discuss@yahoogroups.com>
> Sent: Monday, July 08, 2002 1:49 PM
> Subject: [rest-discuss] XML/XHTML analogy
>
>
> > I was trying to draw a protocol analogy to XML/XHTML.  The best I could
> > come up with was;
> >
> > XML is to XHTML as HTTP is to Yahoo.
> >
> > MB
> > --
> > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> > Ottawa, Ontario, CANADA.               distobj@...
> > http://www.markbaker.ca        http://www.idokorro.com
> >
> >
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:1761
Sender:"Peter Drayton" <peter@...>
Post Date/Time:2002-07-09 06:45:22
Subject:RE: [rest-discuss] Is REST CRUD?
Message:

Following the "REST as SQL CRUD" theme, would it be fair then to say
that SQL's EXEC is similar to POST? 

As with using POST for insertion/creation, implementing a CRUD "CREATE"
using a SQL stored proc may result in the state of the resource not
being a priori knowable after successful invocation.

--Peter
http://www.razorsoft.net/weblog

-----Original Message-----
From: Mark Baker [mailto:mbaker@...] 
Sent: Monday, July 08, 2002 5:42 PM
To: Mark Baker; S. Mike Dierken; Bruce.Durling@...;
rest-discuss@yahoogroups.com
Subject: RE: [rest-discuss] Is REST CRUD?


BTW, I've been thinking more about this, and there definitely some
similarities between REST's generic interface and the generic interface
of other systems, but there are some important differences too,
especially with SQL/CRUD and other data manipulation languages.  The
most important one, IMO is about "POST", and that while it can be used
for insertion/creation, it's really a very generic method for "accept
this data", which can be used to implement everything (except GET - PUT
and DELETE can be negotiated).

This is pretty different than SQL INSERT or CRUD "CREATE", since both
are explicit operations where the invoker has explicit a priori
knowledge of the state of the resource after a successful invocation.
With POST, that knowledge has to be negotiated.

Just something to keep in mind.

MB







-----------------------------------------------------------------------------------
Post ID:1762
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-09 11:42:01
Subject:Re: [rest-discuss] XML/XHTML analogy
Message:

On Mon, Jul 08, 2002 at 10:15:20PM -0700, S. Mike Dierken wrote:
> Sorry, missed the 'protocol' part...
> How about "XML is to XHTML as TCP/IP is to HTTP"

That's the one we started with, which I believe is incorrect because
the latter relationship is one of "layering & use", whereas the former
is just of "use".

> or "XML is to markup as HTTP is to distributed computing"

That's ok.

> or "XML is to XHTML as HTTP is to AS2" (AS2 is a HTTP+MIME based biz doc
> exchange protocol)
> or "XML is to XHTML as HTTP is to Hotmail"

s/Hotmail/Yahoo - that's cheating!

> hmm... I think your analogy is the best... mine just don't make sense.

I think there's something to be written about this, to explain layering
vs. use vs. extension of protocols, data formats, etc..  Might be worth
a Wiki page when I get around to it.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1763
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-09 13:46:51
Subject:REST and only REST (was Re: [rest-discuss] REST and HTTP)
Message:

From: "S. Mike Dierken" <mdierken@...>
> > Another way to look at this HTTP/REST thing is:  if HTTP is the only
> > implementation of REST that the REST-minded community will discuss, then
> why
> > do we even have REST in the first place?  REST is only useful as a
concept
> > that could be generally applied.  Otherwise, it may as well be called
> "HTTP
> > Guidelines".
>
> This is a very good point. This discussion could (and probably should) be
> boiled down into "HTTP Guidelines" - but the REST principles stand apart
> from HTTP.

Yes, the REST principles do stand apart.  My mistake was in believing that
this list focused on REST itself, not "REST as it applies to HTTP".

> Personally, I have used the principles where I needed to build
large-scale,
> long-lived technology in support of products/applications - even when I
> could not directly use HTTP for one reason or another.

Yet according to some, there isn't anything that HTTP can't do.  ;)  And
maybe Jeff Bone is right.  Maybe it is the uberprotocol (at least as far as
REST is concerned).  I am going to have to do some more searhing, playing,
etc. to see how this is possible.  And in the end, I would be happy to
discover his truth.

In the meantime, is there a list out there that is about REST itself?  Sure,
I expect HTTP to come up in conversation now and then, but I want something
that is primarily about REST and not HTTP (which I am beginning to believe
this list is actually about).  I know I have some more te learn before I
fully understand REST.  I am finding that using HTTP to teach REST is just
too confusing.  HTTP brings too much baggage with it (even if the baggage is
nothing more than the "tradtional web mindset").

---
Seairth Jacobs
seairth@...









-----------------------------------------------------------------------------------
Post ID:1764
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-09 13:57:32
Subject:Is GTP RESTful? (was Re: [rest-discuss] An attempt at a RESTful implementation)
Message:

*sigh*  You know, with the entire conversation of "GTP vs. HTTP" and "ONX
vs. XML", I totally forgot about my original question:  Is GTP RESTful?  I
am not necessarily looking to supplant HTTP or XML.  If someone finds any of
it useful, I would be ecstatic.  However, GTP is just as much an academic
effort as anything else (at this point, anyhow).  I am trying to grasp what
REST means without specifically looking to HTTP for examples.

So, back to the original question (and it's corrolaries): Is GTP RESTful?
If not, what is lacking?  What REST principals does GTP not address?  What
parts of GTP do not fit into the REST principles?

---
Seairth Jacobs
seairth@...

p.s.  And if this is the wrong list to be asking these questions to, can
someone suggest another list where this would be more appropriate?







-----------------------------------------------------------------------------------
Post ID:1765
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-09 14:34:22
Subject:Re: [PMX:#] REST and only REST (was Re: [rest-discuss] REST and HTTP)
Message:

Seairth Jacobs wrote:
> 
>...
> 
> In the meantime, is there a list out there that is about REST itself?  

Let's put it this way: try and find a list that discusses relational
databases without a focus on SQL. Obviously there is some subset of the
relational world for whom it is practical and feasible to separate SQL
from relational. But the much larger subset spends their day working in
SQL and need to solve problems in SQL. There are few proposed
alternatives to SQL and their deployment costs would be massive. So you
will not find many programmers outside of the academy who strongly
separate theory and practice. The same is true of REST.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1766
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-09 15:04:53
Subject:Re: REST and only REST (was Re: [rest-discuss] REST and HTTP)
Message:

From: "Paul Prescod" <paul@...>
>
> Let's put it this way: try and find a list that discusses relational
> databases without a focus on SQL. Obviously there is some subset of the
> relational world for whom it is practical and feasible to separate SQL
> from relational. But the much larger subset spends their day working in
> SQL and need to solve problems in SQL. There are few proposed
> alternatives to SQL and their deployment costs would be massive. So you
> will not find many programmers outside of the academy who strongly
> separate theory and practice. The same is true of REST.

True enough.  However, if I were looking to solve an SQL problem, I would
look for an SQL list.  If this list is for solving HTTP problems (as they
apply to REST), then it would make more sense to call this list something
like "http-rest-discuss".  I had thought that this was a more generalized
list.  I was wrong.  I can accept that and move on.  :)

Truthfully, I don't have any problem discussing HTTP as it relates to REST.
I just have trouble learning REST by discussing REST as it relates to HTTP.
I admit that this may be my own problem and no one else's.  I'm just trying
to figure out a way around that problem...

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:1767
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-09 15:12:53
Subject:Re: [PMX:#] Re: REST and only REST (was Re: [rest-discuss] REST and HTTP)
Message:

Seairth Jacobs wrote:
> 
>...
> 
> Truthfully, I don't have any problem discussing HTTP as it relates to REST.
> I just have trouble learning REST by discussing REST as it relates to HTTP.
> I admit that this may be my own problem and no one else's.  I'm just trying
> to figure out a way around that problem...

Roy's thesis makes the distinction between REST and HTTP. If you want to
compare REST to GTP I'd start there, especially with this bit:

"REST is defined by four interface constraints: identification of
resources; manipulation of resources through representations;
self-descriptive messages; and, hypermedia as the engine of application
state."

I don't think it is easy to answer whether GTP is RESTful. To do so, I
would have to really understand it, almost as well as you do, and then
try to apply it mentally to a bunch of REST-architected systems and see
whether it handles them properly.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1768
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-09 16:13:40
Subject:Re: [rest-discuss] An attempt at a RESTful implementation
Message:

On 7/8/02 9:04 PM, "Seairth Jacobs" <seairth@...> wrote:

> Thanks for the feedback.  I am not convinced that GTP isn't a better
> solution, but I do realize I need to take a better look at the workings of
> HTTP.  :)

No prob, and I hope you don't feel too beat up --- I just hate seeing people
make the same mistakes that I've made in the past, and inventing new app
protocols when HTTP would've sufficed is definitely one of those. :-)

Jb







-----------------------------------------------------------------------------------
Post ID:1769
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-09 16:29:05
Subject:Re: [rest-discuss] HTTP/Linda, and versioning/locking rant
Message:

On 7/8/02 7:58 PM, "Robert Leftwich" <robert@...> wrote:

> 
> Since the OP specifically mentioned process synchronization, how does the
> immutable approach make that disappear? More specifically how does it handle
> the stale data/lost update problem? I can see that there is no such thing
> as a lost update in the traditional sense, but how does it cope with that
> scenario and still make sure that the 'current ' file contents are accurate?

That's a good question...  IME, the "lost update" problem is neither as
common / problematic as most people seem to think, nor as difficult to
resolve.  It does, however, usually require really application-specific
solutions.

In the case where the stored objects --- including perhaps the canonical
name -> object mappings --- are immutable, there are a number of ways to
resolve it.  Techniques for doing so are indeed simpler by virtue of the
immutability of the stored objects.  Consider the following sequence:

A looks up name foo, gets ref to object 1
A computes 1' from 1
B looks up name foo, gets ref to object 1
B computes 1'' from 1
B writes 1''
B writes new mapping of foo -> 1''
A writes new mapping of foo -> 1'

The canonical mapping of foo now points at 1', and the mapping foo -> 1'' is
"lost."  However, it's not really lost:  during this time, the mappings from
name to object have been:

t1: foo -> 1
t2: foo -> 1''
t3: foo -> 1'

The version tree for the object has been (read down and left-to-right)

Foo @ t1 -->    1
               / \
Foo @ t2 -->  1'' \
                   \
Foo @ t3 -->        1'

The "canonical" version of the object can heuristically be considered to be
the one pointed to by the latest mapping of name -> object.  If this isn't
sufficient, if it's truly necessary for correct application semantics to
ensure that this mapping is never updated if it has been updated subsequent
to the initial read, then it suffices to just check the canonical (most
current) mapping to ensure it's the same before doing the update.  I.e.:

A looks up name foo, gets ref to object 1
A computes 1' from 1
B looks up name foo, gets ref to object 1
B computes 1'' from 1
B writes 1''
CONDITIONAL ON foo -> 1, B writes new mapping of foo -> 1''
CONDITIONAL ON foo -> 1, A writes new mapping of foo -> 1'

In the failure case, A must then take some application-specific action to
resolve things.  This could be notifying a user, rereading and doing some
kind of merge, etc.

Note that transactions --- the ability to perform or not perform a sequence
of such actions as an atomic unit --- does indeed aid in implementation of
correct algorithms even in the presence of immutable stored objects.  But
that's really orthogonal to locking - transactions in the abstract neither
imply nor require locking.

> 
> Further, were you implying that immutability makes the problem of
> people/processes working out of queue go away, e.g. in the workflow sense
> that there is a shared queue of work needing to be done, with multiple
> processes being fed from the queue, how does immutability help with this
> sort of process synch'ing?

I'm not sure it does...  Explain further?

Jb







-----------------------------------------------------------------------------------
Post ID:1770
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-09 16:50:45
Subject:The Four REST Contstraints (was Re: REST and only REST)
Message:

From: "Paul Prescod" <paul@...>
>
> Roy's thesis makes the distinction between REST and HTTP. If you want to
> compare REST to GTP I'd start there, especially with this bit:
>
> "REST is defined by four interface constraints: identification of
> resources; manipulation of resources through representations;
> self-descriptive messages; and, hypermedia as the engine of application
> state."
>
> I don't think it is easy to answer whether GTP is RESTful. To do so, I
> would have to really understand it, almost as well as you do, and then
> try to apply it mentally to a bunch of REST-architected systems and see
> whether it handles them properly.

Now, this is something I can understand.  Thanks.

So, the basic constraints are:

1) Identification of resources: I am not sure about this one.  In part, I
having trouble what it means to "identify a resource" in a RESTful fashion.
The most common technique, as I understand it, is the URI.  However, I am
not sure that I understand what exactly makes the URI the right
identification method for the job (unless this is just because of it's
relationship to HTTP, etc.).

I suppose the other problem here is that this part of GTP is somewhat left
to be handled be the application that is implemented on top of it.  In other
words, it is up to the application that uses GTP to determine the actual
identification process, format, etc.  The main reason I did this is because
I could not see what advantage there would be to forcing all GTP-enabled
applications to use URIs (as opposed to some other identification format).

2) Manipulation of resources through representations: Now, I have always had
a question about this one.  How exactly can one manipulate resources over a
network any other way?  In other words, it seems to me that any time I
communicate with a computer that returns a resource to me, I can only ever
get a "representation" of that resource (even if the representation contains
all known aspects of that resource).  When I download my e-mail, I am
retrieving a representation of what is on the POP server.  When I send an
e-mail, the SMTP server is only getting a representation of that e-mail.
When I download a file from FTP, I am getting a representation of what is on
the FTP server.  If I were to then edit the downloaded representation and
upload it back again, I am sending back a request to update the remote
resource through my version of the representation.  Does any of what I am
saying make sense, or am I just not grasping what is really meant by this
constraint?

3) Self-descriptive messages: GTP has got this one.  Since it is base on ONX
(or XML), this is a given.

4) Hypermedia as the engine of applications state:  Okay, I think I
understand this one.  All that this is saying is that any given
representation of a resource contains some sort of link to other
representations of the same or other resource(s).  In HTML, it is the URL in
anchors, etc.  These links are the only allowable methods by which a state
can be transferred from one representation to another representation (or
from one state to another state).  Now, how this applies to GTP is a good
question.  In part, I think this is somewhat like the same argument I have
for #1 above.  I think that, as GTP stands now, it does not impose the
method by which "hypermedia" is achieved.

Maybe in order for GTP to be more REST-like, I need to impose the resource
identification and hypermedia rules up front.  For instance, maybe the URI
should be the only allowable format.  This would certainly make this aspect
of GTP universal across implementations, but would it also impose
restrictions on what can and cannot realistically be done with GTP?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:1771
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-09 17:07:43
Subject:Re: [rest-discuss] The Four REST Contstraints (was Re: REST and only REST)
Message:

On 7/9/02 11:50 AM, "Seairth Jacobs" <seairth@...> wrote:
> 
> 1) Identification of resources: I am not sure about this one.  In part, I
> having trouble what it means to "identify a resource" in a RESTful fashion.
> The most common technique, as I understand it, is the URI.  However, I am
> not sure that I understand what exactly makes the URI the right
> identification method for the job (unless this is just because of it's
> relationship to HTTP, etc.).

Things to think about:  a URI doesn't have to be an HTTP URI --- you could
easily have GTP URIs.  Second, a URI isn't anything more than a name for
something --- think handle, name, OID, hash, whatever.  The only semantics a
URI "officially" has is dereference - Axiom of [URI] Opacity.  (In fact,
that's questionable --- but that's a good first approximation.)  The nice
thing about HTTP and many other URI schemes is that the naming is
decentralized and uncoordinated --- as long as there's a DNS name or IP
address to qualify the namespace, it's possible to add names with no
coordination between administrative concerns whatsoever.  This is an
important point and, IMO, one of the keys to the success of the Web.

> 2) Manipulation of resources through representations: Now, I have always had
> a question about this one.  How exactly can one manipulate resources over a
> network any other way?  In other words, it seems to me that any time I
> communicate with a computer that returns a resource to me, I can only ever
> get a "representation" of that resource (even if the representation contains
> all known aspects of that resource).  When I download my e-mail, I am
> retrieving a representation of what is on the POP server.  When I send an
> e-mail, the SMTP server is only getting a representation of that e-mail.
> When I download a file from FTP, I am getting a representation of what is on
> the FTP server.  If I were to then edit the downloaded representation and
> upload it back again, I am sending back a request to update the remote
> resource through my version of the representation.  Does any of what I am
> saying make sense, or am I just not grasping what is really meant by this
> constraint?

Nope, you've basically got it.  In the literal sense, this constraint is a
tautology.  You can only manipulate things via representations.  I suspect
that the purpose of the constraint is to point out and underscore the
distinction between the logical entity denoted by the URI --- the resource
--- and the representation.  Most people get confused the other way around,
and assume that resources are transferred --- this is still a source of
confusion for many very bright people, cf. recent discussion in TAG and
elsewhere.

> 4) Hypermedia as the engine of applications state:  Okay, I think I
> understand this one.  All that this is saying is that any given
> representation of a resource contains some sort of link to other
> representations of the same or other resource(s).  In HTML, it is the URL in
> anchors, etc.  These links are the only allowable methods by which a state
> can be transferred from one representation to another representation (or
> from one state to another state).  Now, how this applies to GTP is a good
> question.  In part, I think this is somewhat like the same argument I have
> for #1 above.  I think that, as GTP stands now, it does not impose the
> method by which "hypermedia" is achieved.

This one, IMO, is the most propaganda-like of the constraints:  politically
charged and technically not that useful / meaningful.  It simply begs for
the definitions of hypermedia, application, application state, and engine.
Nor, IMO, does a literal interpretation of REST - REpresentational State
Transfer - really require hypermedia.  (IMO, all the rest of REST is useful
in thinking about i.e. globally distributed filesystems containing objects
that do not in fact refer to one another via hyperlinks...  But with the
addition of this constraint, REST ties itself undesirably and inextricably
to the existing Web and other Web-like hypermedia systems.  IMHO,
short-sightedness on Roy's part.)  But that's a controversial dead horse
that we've already beat up.

Having said that, the Web is a GOOD THING and distributed systems in general
gain tremendously by accommodating the Web's hypermedia data model, REST
architecture, and other technical qualities.

jb







-----------------------------------------------------------------------------------
Post ID:1772
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-07-09 17:11:30
Subject:RE: [rest-discuss] Is REST CRUD?
Message:

I didn't know SQL had "EXEC".  SQL92 doesn't appear to.
 
If it's a method for passing data to some thing for processing, then I
guess it probably is the same, though the name "EXEC" doesn't suggest
that it's the same.  And not knowing the state after a stored procedure
executes is necessary but insufficient to be the same as POST.
 
MB
 

	-----Original Message----- 
	From: Peter Drayton 
	Sent: Tue 7/9/2002 2:45 AM 
	To: Mark Baker; 'S. Mike Dierken'; Bruce.Durling@equifax.com;
rest-discuss@yahoogroups.com 
	Cc: 
	Subject: RE: [rest-discuss] Is REST CRUD?
	
	

	Following the "REST as SQL CRUD" theme, would it be fair then to
say 
	that SQL's EXEC is similar to POST? 

	As with using POST for insertion/creation, implementing a CRUD
"CREATE" 
	using a SQL stored proc may result in the state of the resource
not 
	being a priori knowable after successful invocation. 

	--Peter 
	http://www.razorsoft.net/weblog 

	-----Original Message----- 
	From: Mark Baker [ mailto:mbaker@idokorro.com] 
	Sent: Monday, July 08, 2002 5:42 PM 
	To: Mark Baker; S. Mike Dierken; Bruce.Durling@equifax.com; 
	rest-discuss@yahoogroups.com 
	Subject: RE: [rest-discuss] Is REST CRUD? 


	BTW, I've been thinking more about this, and there definitely
some 
	similarities between REST's generic interface and the generic
interface 
	of other systems, but there are some important differences too, 
	especially with SQL/CRUD and other data manipulation languages.
The 
	most important one, IMO is about "POST", and that while it can
be used 
	for insertion/creation, it's really a very generic method for
"accept 
	this data", which can be used to implement everything (except
GET - PUT 
	and DELETE can be negotiated). 

	This is pretty different than SQL INSERT or CRUD "CREATE", since
both 
	are explicit operations where the invoker has explicit a priori 
	knowledge of the state of the resource after a successful
invocation. 
	With POST, that knowledge has to be negotiated. 

	Just something to keep in mind. 

	MB 






-----------------------------------------------------------------------------------
Post ID:1773
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-07-09 18:22:41
Subject:Re: [rest-discuss] HTTP/Linda, and versioning/locking rant
Message:

>>Could we all get over this whole idea of locking as necessary or desirable
>>for versioning, avoiding conflict in object evolution, etc.?  It's a
>>side-effect of a bad storage metaphor, namely that stored entities are
>>mutable.  Stored entities need not be mutable:  imagine a filesystem in
>>which stored files are immutable, identified by OIDs (maybe hashes), and
> 
> 
> Somebody I respect a lot once said "Dynamism is an illusion". This was in
> reference to versioning in Groves. Kind of similar I suppose...

We've wrestled with this problem for a long time.  The tuplespace (in 
this case, javaspaces) is very core to our system.  As our application 
evolves over time, we've found that our data evolves over time.  We've 
had to keep good track of our Java classes so that we don't create 
incompatible serialization issues.  Granted, this is very Java specific.

What I'd love for our application to do is use XML + RDF as our 
information serialization.  We can then become a lot more flexible with 
interpreting and parsing the documents (especially when using RDF).

But data definitions are mutable in the real world, and in some cases 
(java serialization) can cause big headaches.

Seth







-----------------------------------------------------------------------------------
Post ID:1774
Sender:"Peter Drayton" <peter@...>
Post Date/Time:2002-07-09 18:29:25
Subject:RE: [rest-discuss] Is REST CRUD?
Message:

In Sybase/Microsoft Transact-SQL EXEC is the short form of EXECUTE,
which executes a stored procedure. 

However, (and I didn't actually know that this distinction existed until
today) in SQL-92 [1] EXEC is *not* the short form of EXECUTE: EXECUTE
(section 17.10) invokes stored procedures, while EXEC (section 19) is
used for embedded SQL. In SQL-92 parlance I was referring to EXECUTE. 

My observation/question was that EXEC[UTE] is a "method for passing data
to some thing for processing", which feels similar on some levels to
POST. 

I really like the REST<->CRUD analogy, BTW.

--Peter

[1] http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

-----Original Message-----
From: Mark Baker [mailto:mbaker@...] 
Sent: Tuesday, July 09, 2002 10:12 AM
To: Peter Drayton; S. Mike Dierken; Bruce.Durling@...;
rest-discuss@yahoogroups.com
Subject: RE: [rest-discuss] Is REST CRUD?

I didn't know SQL had "EXEC".  SQL92 doesn't appear to.

If it's a method for passing data to some thing for processing, then I
guess it probably is the same, though the name "EXEC" doesn't suggest
that it's the same.  And not knowing the state after a stored procedure
executes is necessary but insufficient to be the same as POST.

MB

-----Original Message----- 
From: Peter Drayton 
Sent: Tue 7/9/2002 2:45 AM 
To: Mark Baker; 'S. Mike Dierken'; Bruce.Durling@...;
rest-discuss@yahoogroups.com 
Cc: 
Subject: RE: [rest-discuss] Is REST CRUD?

Following the "REST as SQL CRUD" theme, would it be fair then to say 
that SQL's EXEC is similar to POST? 

As with using POST for insertion/creation, implementing a CRUD "CREATE" 
using a SQL stored proc may result in the state of the resource not 
being a priori knowable after successful invocation. 







-----------------------------------------------------------------------------------
Post ID:1775
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-07-09 19:21:02
Subject:RE: [rest-discuss] Is REST CRUD?
Message:

Ah, thanks for the ref.  I wasn't being a smart ass, I couldn't even
find "execute" in the sql92 reference I had. 8-)
 
So after looking at it, I'd say that it's not post, because you have to
provide the "statement name"; if you know a statement name, then you
have an expectation of what the result will be if you execute it.  If
you don't know a statement name, then you can't use the method.
 
So it appears to mean "invoke this method" (which the name indicates),
and that's different than POST.
 
MB





-----------------------------------------------------------------------------------
Post ID:1776
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-09 21:15:37
Subject:Re: [rest-discuss] HTTP/Linda, and versioning/locking rant
Message:

On 7/9/02 1:22 PM, "Seth Ladd" <seth@...> wrote:

> 
> We've wrestled with this problem for a long time.  The tuplespace (in
> this case, javaspaces) is very core to our system.  As our application
> evolves over time, we've found that our data evolves over time.  We've
> had to keep good track of our Java classes so that we don't create
> incompatible serialization issues.  Granted, this is very Java specific.

Not really that Java specific --- I've run into this issue every time I've
had to wrestle with object persistence in the face of schema evolution.  The
old object-relational tools (i.e., Persistence - anybody remember that?) had
this problem in spades, Python's pickle has this problem to a certain lesser
extent, etc.  It's really troublesome in statically-typed languages with
what I think of as "rigid" object models, i.e. C++.  Languages where objects
are really just slot containers / dictionaries / etc. --- e.g. Python ---
this is often less troublesome.

> 
> What I'd love for our application to do is use XML + RDF as our
> information serialization.  We can then become a lot more flexible with
> interpreting and parsing the documents (especially when using RDF).

Wrt XML tuplespaces, sounds like a job for Ruple. :-)

Wrt schema drift and RDF, one of the most significant problems with RDF is
that facts can reference facts outside of a local factset / administrative
domain, which can evolve in an uncoordinated and therefore destructive
fashion.  Until the various parties involve *deeply* address these and
related problems, there will be no Semantic Web other than very local
factsets. :-/  The good news is that, assuming immutability of (certain)
resources i.e., true idempotency of GET over time, the problem is rather
trivial...

BTW, I'm a big fan of predicate calculus as a data model, but I'm not sure
what RDF buys you over arbitrary n-ary tuples when you're talking about
generative communication...  Perhaps you could talk about that a bit?

> 
> But data definitions are mutable in the real world, and in some cases
> (java serialization) can cause big headaches.

Make sure instances of some schema embed a reference to an immutable copy of
their schema.  It also helps to have named, declarative descriptions of
transformations between schema versions that can be referenced...  In XML,
for instance, this could perhaps be an XSLT that transforms XML schemas.

Jb







-----------------------------------------------------------------------------------
Post ID:1777
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-09 21:19:28
Subject:Re: REST and only REST (was Re: [rest-discuss] REST and HTTP)
Message:

----- Original Message ----- 
From: "Seairth Jacobs" <seairth@...>

> 
> Yet according to some, there isn't anything that HTTP can't do.  ;)  
True - but I don't pay the bills...







-----------------------------------------------------------------------------------
Post ID:1778
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-09 21:37:18
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

On 7/9/02 1:29 PM, "Peter Drayton" <peter@...> wrote:

>
> My observation/question was that EXEC[UTE] is a "method for passing data
> to some thing for processing", which feels similar on some levels to
> POST. 

Here's my problem with this analogy.  First, the relational calculus per se
doesn't say anything about EXECUTE, and EXECUTE by itself has no impact on
any data model.  IMO, whether any SQL has EXEC, EXECUTE, etc., its not
really accurate to think of it as a part of CRUD.  Instead, it's really a
way to tunnel SQL through SQL...

But more troublesome:  it's perhaps dangerous to think of POST in this way,
i.e. to think about it as a way to provide arbitrary data to a resource for
arbitrary purposes.  It's a slippery slope from there to RPC.  Before
"getting" REST, I used to argue that we only really needed one protocol with
one method:  INVOKE, or POST, or EXEC, etc.  All other methods, I argued,
could and should be implemented by individual objects in terms of that
single primitive method.

AFAICT the "correct" interpretation of POST should really be:  update the
state of the resource in question given the following (potentially partial)
representation of what the new resource state should be.  This is a subtle
distinction, but IMO an important one:  POST isn't an arbitrary method
dispatch interface, but rather a very specific method itself that consumes a
representation of the intended resource state and acts accordingly.

As with many of these issues, though, this is so subtle and slippery that in
practice I find myself violating it all the time. ;-)  In WebKit, for
instance, in our administrative UI for the current product, we're using its
mechanism for binding "actions" passed in via POST to methods in particular
servlet method implementations.  This is the wrong way to do it:  we should
really be modeling things differently, but it's often not clear what the
right model should be...  And the arguments in favor of doing it the right
way often come across as rather academic.

Trying to practice what I preach,

Jb








-----------------------------------------------------------------------------------
Post ID:1779
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-09 23:01:27
Subject:Re: [rest-discuss] HTTP/Linda, and versioning/locking rant
Message:

At 02:29 AM 10/07/2002, Jeff Bone wrote:
>On 7/8/02 7:58 PM, "Robert Leftwich" <robert@...> wrote:
> >
> > Further, were you implying that immutability makes the problem of
> > people/processes working out of queue go away, e.g. in the workflow sense
> > that there is a shared queue of work needing to be done, with multiple
> > processes being fed from the queue, how does immutability help with this
> > sort of process synch'ing?
>
>I'm not sure it does...  Explain further?

I was thinking along the lines of locking for exclusivity not for versioning
(the queue thing was a bit of a red herring), i.e. semaphores/resource
locks, Thinking on it further, the immutability probably has no influence at
all. If you use a basic lock file approach, either the file is there or not
and assuming that delete actually does delete the lock file and not simply
remove the mapping link (so that you end up with a multitude of unlinked old
lock file versions somewhere in your file system) then all is well.


Robert


>Jb
>
>
>
>To unsubscribe from this group, send an email to:
>rest-discuss-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/







-----------------------------------------------------------------------------------
Post ID:1780
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-09 23:11:46
Subject:Re: [rest-discuss] HTTP/Linda, and versioning/locking rant
Message:

On 7/9/02 6:01 PM, "Robert Leftwich" <robert@...> wrote:

> 
>> I'm not sure it does...  Explain further?
> 
> I was thinking along the lines of locking for exclusivity not for versioning
> (the queue thing was a bit of a red herring), i.e. semaphores/resource
> locks, Thinking on it further, the immutability probably has no influence at
> all. If you use a basic lock file approach, either the file is there or not
> and assuming that delete actually does delete the lock file and not simply
> remove the mapping link (so that you end up with a multitude of unlinked old
> lock file versions somewhere in your file system) then all is well.

Correct.  Immutability probably doesn't do away with the need for semaphores
/ etc. for the purpose of synchronization where it's truly needed --- but my
point is that with immutability and complete version history, you can avoid
many synchronization situations.  The issue becomes not "canonically right
at any given instant" but rather "determination of the canonically right
state on demand."

BTW, please note that a combination of immutable stored files, a heuristic
that says "canonical version is the latest version", and a mechanism that
lets you access historical versions via various criteria gives you something
that has the overt last-writer-wins semantics of filesystems absent file
locking *and* CVS-like versioning, w/o explicit check-in/check-out.

Cheers,

Jb







-----------------------------------------------------------------------------------
Post ID:1781
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-10 00:19:22
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

At 07:37 AM 10/07/2002, Jeff Bone wrote:

>AFAICT the "correct" interpretation of POST should really be:  update the
>state of the resource in question given the following (potentially partial)
>representation of what the new resource state should be.

This is using the broadest possible sense of 'resource state' is it not?
I understood POST to be specifically aimed at *new* subordinate resources
(from RFC2616). With your classification PUT and POST are only marginally
different, in that PUT ''SHOULD be considered as a modified version'  of the
resource, i.e. in its entirety, but POST can be a partial representation of
the resource.

>This is a subtle
>distinction, but IMO an important one:  POST isn't an arbitrary method
>dispatch interface, but rather a very specific method itself that consumes a
>representation of the intended resource state and acts accordingly.

Isn't that classification exactly the same as PUT?


>As with many of these issues, though, this is so subtle and slippery that in
>practice I find myself violating it all the time. ;-)

IMHO that is a huge problem for REST and it may be an insurmountable one -
there is no canonical answer. This may be symptomatic of the fact that the
limited verb count means that you invariably have to overload/overlay many
meanings on top of them, so many in fact that their usefulness becomes diluted.

>In WebKit, ...

Webkit == Webware (http://webware.sourceforge.net/) ?

>Trying to practice what I preach,

Trying to find something to practice!

Robert







-----------------------------------------------------------------------------------
Post ID:1782
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-10 03:25:24
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

On 7/9/02 7:19 PM, "Robert Leftwich" <robert@...> wrote:

> With your classification PUT and POST are only marginally
> different, in that PUT ''SHOULD be considered as a modified version'  of the
> resource, i.e. in its entirety, but POST can be a partial representation of
> the resource.

Yes, that's my understanding.  The imperfect analogy I've used before:

PUT ~=  echo "foo" > foo
POST ~= echo "foo" >> foo

With the proviso that foo -- the file, the thing that's getting redirected
to -- can be equivalent to a device file, i.e. could well be /dev/foo.


>> This is a subtle
>> distinction, but IMO an important one:  POST isn't an arbitrary method
>> dispatch interface, but rather a very specific method itself that consumes a
>> representation of the intended resource state and acts accordingly.
> 
> Isn't that classification exactly the same as PUT?

PUT is "replace."  POST is "update," "append," etc.  The distinction is
equivalent to the distinction between > and >>.

> 
> 
>> As with many of these issues, though, this is so subtle and slippery that in
>> practice I find myself violating it all the time. ;-)
> 
> IMHO that is a huge problem for REST and it may be an insurmountable one -
> there is no canonical answer. This may be symptomatic of the fact that the
> limited verb count means that you invariably have to overload/overlay many
> meanings on top of them, so many in fact that their usefulness becomes
> diluted.

My guess is it's a combination of educational / cultural bias and impedance
mismatch between toolkits and model...

> 
>> In WebKit, ...
> 
> Webkit == Webware (http://webware.sourceforge.net/) ?
>

Yup!
 
>> Trying to practice what I preach,
> 
> Trying to find something to practice!
>

Keep searching, it's there. :-)  (Seriously, it took me a year of
acrimonious head-butting with Mark and (esp) Roy to get it...

Jb
 







-----------------------------------------------------------------------------------
Post ID:1783
Sender:"Mark Baker" <mbaker@...>
Post Date/Time:2002-07-10 12:45:29
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

I don't like your description of POST there Jeff.  POSTed data need not
have anything to do with being a representation of the resource to which
it's being POSTed.  Like POSTing a representation of a pair of shoes to
a shopping cart.

It's just "take this data", with the (critical) proviso that a
successful response just means that the data was accepted, nothing more.
i.e. you need not tunnel with it to use it.

MB

-----Original Message-----
From: Jeff Bone <jbone@...>
To: Robert Leftwich <robert@...>
CC: rest-discuss@yahoogroups.com <rest-discuss@yahoogroups.com>
Sent: Tue Jul 09 23:25:24 2002
Subject: Re: [rest-discuss] Is REST CRUD?

On 7/9/02 7:19 PM, "Robert Leftwich" <robert@...> wrote:

> With your classification PUT and POST are only marginally
> different, in that PUT ''SHOULD be considered as a modified version'
of the
> resource, i.e. in its entirety, but POST can be a partial
representation of
> the resource.

Yes, that's my understanding.  The imperfect analogy I've used before:

PUT ~=  echo "foo" > foo
POST ~= echo "foo" >> foo

With the proviso that foo -- the file, the thing that's getting
redirected
to -- can be equivalent to a device file, i.e. could well be /dev/foo.


>> This is a subtle
>> distinction, but IMO an important one:  POST isn't an arbitrary
method
>> dispatch interface, but rather a very specific method itself that
consumes a
>> representation of the intended resource state and acts accordingly.
> 
> Isn't that classification exactly the same as PUT?

PUT is "replace."  POST is "update," "append," etc.  The distinction is
equivalent to the distinction between > and >>.

> 
> 
>> As with many of these issues, though, this is so subtle and slippery
that in
>> practice I find myself violating it all the time. ;-)
> 
> IMHO that is a huge problem for REST and it may be an insurmountable
one -
> there is no canonical answer. This may be symptomatic of the fact that
the
> limited verb count means that you invariably have to overload/overlay
many
> meanings on top of them, so many in fact that their usefulness becomes
> diluted.

My guess is it's a combination of educational / cultural bias and
impedance
mismatch between toolkits and model...

> 
>> In WebKit, ...
> 
> Webkit == Webware (http://webware.sourceforge.net/) ?
>

Yup!
 
>> Trying to practice what I preach,
> 
> Trying to find something to practice!
>

Keep searching, it's there. :-)  (Seriously, it took me a year of
acrimonious head-butting with Mark and (esp) Roy to get it...

Jb
 



To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 









-----------------------------------------------------------------------------------
Post ID:1784
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-10 14:36:17
Subject:Re: [PMX:#] [rest-discuss] The Four REST Contstraints (was Re: REST and only REST)
Message:

Seairth Jacobs wrote:
> 
>...
> 
> Now, this is something I can understand.  Thanks.
> 
> So, the basic constraints are:
> 
> 1) Identification of resources: I am not sure about this one.  In part, I
> having trouble what it means to "identify a resource" in a RESTful fashion.
> The most common technique, as I understand it, is the URI.  However, I am
> not sure that I understand what exactly makes the URI the right
> identification method for the job (unless this is just because of it's
> relationship to HTTP, etc.).

Whether you believe the "U" stands for "universal" or "uniform", the
relevant property is a good thing. Uniform is good in that you have
globally understood parsing rules. Universal is good because it implies
that any component may talk to any resource.

> I suppose the other problem here is that this part of GTP is somewhat left
> to be handled be the application that is implemented on top of it.  In other
> words, it is up to the application that uses GTP to determine the actual
> identification process, format, etc.  The main reason I did this is because
> I could not see what advantage there would be to forcing all GTP-enabled
> applications to use URIs (as opposed to some other identification format).

Well if one GTP application used CORBA object ids and another used URIs
then the universe would be split into the world of components that know
how to use one kind of address and the world of components that know how
to use the other kind of address. The web has this problem to a certain
extent, but market pressures suppress the proliferation of variant URI
schemes. My personal opinion is that non-GETTABLE URI schemes should
only be used for pre-existing legacy namespaces (like "mailto:" or
"isbn:").

> 2) Manipulation of resources through representations: Now, I have always had
> a question about this one.  How exactly can one manipulate resources over a
> network any other way?  In other words, it seems to me that any time I
> communicate with a computer that returns a resource to me, I can only ever
> get a "representation" of that resource (even if the representation contains
> all known aspects of that resource). 

Obviously you can't really touch objects over the network. But some
networking technologies might claim that clients may behave as if they
are. Arguably, if you PUT a file thorugh FTP and then do an immediate
GET, with some a priori knowledge that nobody else could touch the file,
you should get back the exact same bits. But HTTP doesn't define the
"bits" of a resource. And according to my understanding, you could PUT
one second and GET back something different the next second, even if
nobody else fiddled with the data.

> 3) Self-descriptive messages: GTP has got this one.  Since it is base on ONX
> (or XML), this is a given.

Note the sub-parts of "self-description" from the thesis: "REST enables
intermediate processing by constraining messages to be self-descriptive:
interaction is stateless between requests, standard methods and media
types are used to indicate semantics and exchange information, and
responses explicitly indicate cacheability."

> 4) ....
> 
> Maybe in order for GTP to be more REST-like, I need to impose the resource
> identification and hypermedia rules up front.  For instance, maybe the URI
> should be the only allowable format.  This would certainly make this aspect
> of GTP universal across implementations, but would it also impose
> restrictions on what can and cannot realistically be done with GTP?

A URI is just a syntax. Agreeing to use it is not much more restrictive
than agreeing to use ONX. If you are reinventing the universe without
worrying about practicality, you might consider whether URIs should have
better support for URIs that embed URIs without escaping. For instance
this is not a valid URI:

http://google.com?get_cached_page=http://www.bates.com

IIRC, slashes are not allowed in query strings unless escaped. A
new-fangled replacement for URIs might allow something like:

http://google.com?get_cached_page=(http://www.bates.com)

The thing in parens is implicitly escaped and could have its own
sub-parts:

http://google.com?get_cached_page=(http://www.bates.com?something_else=())

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1785
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-10 14:46:09
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

Jeff Bone wrote:
> 
> ...
> 
> As with many of these issues, though, this is so subtle and slippery that in
> practice I find myself violating it all the time. ;-)  In WebKit, for
> instance, in our administrative UI for the current product, we're using its
> mechanism for binding "actions" passed in via POST to methods in particular
> servlet method implementations.  This is the wrong way to do it:  we should
> really be modeling things differently, but it's often not clear what the
> right model should be...  And the arguments in favor of doing it the right
> way often come across as rather academic.

One of the problems with teaching REST today is that deployed tools only
depend strongly upon the semantics for GET. 

PUT, DELETE are mostly ignored except in a WebDAV context. POST is
"everything that doesn't make sense as GET". In part, that's why I think
that WebDAV is a good partner for HTTP in REST systems. When someone
asks: "what's the practical consequence of using POST for DELETE" we can
answer: "you break compatibility with Windows Explorer and MS Office."
Some people will not care but others will.

In a perfect world, we would all use tools like "wget", "wput",
"wdelete", "wpost" every day. But really, outside of WebDAV, we only use
"wget".
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1786
Sender:"wscottmeans" <wsmeans@...>
Post Date/Time:2002-07-10 16:36:33
Subject:Re: Is REST CRUD?
Message:

On Wed, 10 Jul 2002 07:46:09 -0700, Paul Prescod wrote:
> One of the problems with teaching REST today is that deployed tools 
only
> depend strongly upon the semantics for GET.
> 
> PUT, DELETE are mostly ignored except in a WebDAV context. POST is
> "everything that doesn't make sense as GET". In part, that's
> why I think
> that WebDAV is a good partner for HTTP in REST systems. When someone
> asks: "what's the practical consequence of using POST for
> DELETE" we can
> answer: "you break compatibility with Windows Explorer and MS
> Office."
> Some people will not care but others will.
> 
> In a perfect world, we would all use tools like "wget",
> "wput",
> "wdelete", "wpost" every day. But really, outside of
> WebDAV, we only use
> "wget".

I know that the proper semantic use of GET, PUT, POST, and DELETE is 
central to REST, but unfortunately a lot of us have to work in the 
imperfect world of HTML where GET and POST are much better supported 
than the other two.

For me, the beauty of REST is the promise that I can architect a 
single, uniform, XML-based back-end infrastructure that can then be 
displayed and manipulated by a virtually unlimited set of client 
interfaces. But if I have to build this interface to depend on PUT 
and DELETE, then I have to somehow translate GET and POST requests 
from "down-level" clients (i.e. HTML, VoiceXML, WAP, etc.) to 
their "proper" equivalents.

XML and XSLT do a great job of solving the "one source, many formats" 
problem, but if I can't write my back-end processing to the lowest 
common denominator (i.e. GET and POST), I lose a lot of the ground I 
gained on the transformation side.

Any thoughts? Am I missing something?







-----------------------------------------------------------------------------------
Post ID:1787
Sender:"Dr. Carter" <Open_the_Mind_Now@...>
Post Date/Time:2002-07-10 16:54:47
Subject:It is beneficial to your library & its patrons to have the book (Please suggest)
Message:

Dear Sir/Ma'am:

It is significantly beneficial to your library and its patrons to have a book titled 

"Complete Conduct Principles for the 21st Century" by Dr. John Newton. 

Please suggest to your local library(ies) that the book be purchased. This is a great contribution you can make to your neighborhood!  

"I find it heartening that you are crusading on behalf of this worthy book. It has occupied a space on our shelves for some time now. To have this book in our library is a quiet source of pride to me, the librarian." said Mr. Don Brusha, a highly respectable Librarian of Avon Park Library in Avon Park, Florida, USA, in a letter to me regarding the book.

This book is a MUST for EVERYONE to be better prepared for personal conduct for the 21st century.  EVERY  LIBRARY  SHOULD  HAVE  IT.  

You may ask yourself
      >    How to make people respect you
      >    How to win friends
      >    How to let your conduct help your health, work, job, career, relationships, spirit,  mind, well-being, ...
      >    How to make your life smoother and happier 
      >    How to do whatever you like without being unpleasant to other people 
      >    How to develop good conduct in your children or students 
      >    How to make the world peaceful and better

You (and the library patrons) can find all the answers to these questions, and much more, in this great book.
 
BENEFITS to each individual reader: Many! -- such as for health, work, job, career, self-improvement, education, relationships, spirit, mind, well-being, and much more -- almost all the areas that are important to you in the 21st century. People around you will benefit, too. (Please see the preface of the book for details.) 

EVERYONE may find this book useful and helpful, regardless of age (from children to oldsters), occupation, rank, status, gender, religious beliefs, nationality, country, or region. 

If you are a parent or a teacher, you can learn how to develop good conduct in your children or students from this book. Please advise your children or students to read the book. It will result in great benefits for both you and them. 

The book's content is obvious from its title. The complete useful conduct principles cover not only what we should do, but also what we should not do -- especially those faults people make often and easily. 

"The book will also be effective for violence prevention for the whole society." said some experts.

This timely, unique, and very important book is designed to suit most people, and is self-contained and user-friendly. 

This book is significantly different and better than competitive works.

Some of its innovative contents may help solve problems that Western culture cannot. 

The book's merit and importance have been recognized and praised by many experts, elected public officials, and world leaders.

How to make the world peaceful and better ---
You (and the library patrons) can find the solution in the book.
Let's work together to make the world peaceful and better! 

The author, John Newton, holds a Ph.D. from MIT, and does researches at Harvard. His long-term research on "The personal conduct in the human society of the 21st century" resulted in this book. It is published by Nicer Century World Organization, headquartered beside Harvard University and MIT, two leading institutes of new knowledge and literature.

It has the Library of Congress Cataloging-in-Publication data. Trade hardcover (case bound, Smyth sewn; with dust jacket) ISBN 0967370574; trade paperback (perfect bound) ISBN 0967370582. Bound durably and functionally to stand up to heavy library use.  60 lb natural acid-free excellent and healthful paper. 5.5inX8.5in. 192 pages. Including Principle Index and General Index. Self-contained. 

Again, please suggest to your local library(ies) that the book be purchased.

Your effort to make a great contribution to your family and neighborhood and the whole society will be highly appreciated.


Sincerely yours,

Tom Carter, Ph.D.
President, Nicer Century World Organization
Massachusetts, USA

(Nicer Century World Organization is an educational, non-profit, non-partisan organization; it endeavors to make the 21st century nicer than ever before. To accomplish its mission, Nicer Century World Organization is proud to introduce this book.)








-----------------------------------------------------------------------------------
Post ID:1788
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-07-10 19:37:08
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

I agree with Mark on the interpretation of POST.

From the RFC [1]:

    9.6 PUT

       [...]

       The fundamental difference between the POST and PUT requests is
       reflected in the different meaning of the Request-URI. The URI in a
       POST request identifies the resource that will handle the enclosed
       entity. That resource might be a data-accepting process, a gateway to
       some other protocol, or a separate entity that accepts annotations.
       In contrast, the URI in a PUT request identifies the entity enclosed
       with the request -- the user agent knows what URI is intended and the
       server MUST NOT attempt to apply the request to some other resource.

Still, how might subtle differences in interpretation of the non-GET methods
effect the adoption of the REST model?  If web services are built that
don't follow these guidelines strictly enough, what sorts of
problems could emerge for developers attempting to integrate with them?

[1] http://rfc.net/rfc2616.html

----- Original Message -----
From: "Mark Baker" <mbaker@...>
To: <jbone@...>; <robert@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Wednesday, July 10, 2002 8:45 AM
Subject: Re: [rest-discuss] Is REST CRUD?


I don't like your description of POST there Jeff.  POSTed data need not
have anything to do with being a representation of the resource to which
it's being POSTed.  Like POSTing a representation of a pair of shoes to
a shopping cart.

It's just "take this data", with the (critical) proviso that a
successful response just means that the data was accepted, nothing more.
i.e. you need not tunnel with it to use it.

MB

-----Original Message-----
From: Jeff Bone <jbone@...>
To: Robert Leftwich <robert@...>
CC: rest-discuss@yahoogroups.com <rest-discuss@yahoogroups.com>
Sent: Tue Jul 09 23:25:24 2002
Subject: Re: [rest-discuss] Is REST CRUD?

On 7/9/02 7:19 PM, "Robert Leftwich" <robert@...> wrote:

> With your classification PUT and POST are only marginally
> different, in that PUT ''SHOULD be considered as a modified version'
of the
> resource, i.e. in its entirety, but POST can be a partial
representation of
> the resource.

Yes, that's my understanding.  The imperfect analogy I've used before:

PUT ~=  echo "foo" > foo
POST ~= echo "foo" >> foo

With the proviso that foo -- the file, the thing that's getting
redirected
to -- can be equivalent to a device file, i.e. could well be /dev/foo.


>> This is a subtle
>> distinction, but IMO an important one:  POST isn't an arbitrary
method
>> dispatch interface, but rather a very specific method itself that
consumes a
>> representation of the intended resource state and acts accordingly.
>
> Isn't that classification exactly the same as PUT?

PUT is "replace."  POST is "update," "append," etc.  The distinction is
equivalent to the distinction between > and >>.

>
>
>> As with many of these issues, though, this is so subtle and slippery
that in
>> practice I find myself violating it all the time. ;-)
>
> IMHO that is a huge problem for REST and it may be an insurmountable
one -
> there is no canonical answer. This may be symptomatic of the fact that
the
> limited verb count means that you invariably have to overload/overlay
many
> meanings on top of them, so many in fact that their usefulness becomes
> diluted.

My guess is it's a combination of educational / cultural bias and
impedance
mismatch between toolkits and model...

>
>> In WebKit, ...
>
> Webkit == Webware (http://webware.sourceforge.net/) ?
>

Yup!

>> Trying to practice what I preach,
>
> Trying to find something to practice!
>

Keep searching, it's there. :-)  (Seriously, it took me a year of
acrimonious head-butting with Mark and (esp) Roy to get it...

Jb




To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/





To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/









-----------------------------------------------------------------------------------
Post ID:1789
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-10 19:41:41
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

Mark wrote:

>  
> I don't like your description of POST there Jeff.  POSTed data need not
> have anything to do with being a representation of the resource to which
> it's being POSTed.  Like POSTing a representation of a pair of shoes to
> a shopping cart.
> 

And that's not a partial description of the desired new state of the
cart...?


Jb









-----------------------------------------------------------------------------------
Post ID:1790
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-07-10 20:22:08
Subject:Re: [rest-discuss] HTTP/Linda, and versioning/locking rant
Message:

> BTW, I'm a big fan of predicate calculus as a data model, but I'm not sure
> what RDF buys you over arbitrary n-ary tuples when you're talking about
> generative communication...  Perhaps you could talk about that a bit?

I was mostly refering to RDF being used by DAML+OIL.  I want to use 
DAML+OIL to help describe what the XML is marking up.  That way, as our 
schemas evolve, my code can remain flexible in handling the XML.  My 
code would be written to understand DAML+OIL classes, instead of raw 
XML.  It's an attempt to get away from hardcoding our application for 
particular schemas.  I want the application to understand problem 
domains, not particular object hierarchies.


> Make sure instances of some schema embed a reference to an immutable copy of
> their schema.  It also helps to have named, declarative descriptions of
> transformations between schema versions that can be referenced...  In XML,
> for instance, this could perhaps be an XSLT that transforms XML schemas.

In an all XML world, XSLT helps greatly to move me from schema to 
schema, especially when the data document references a schema version. 
Unfortunately, we're bound to C++ and its available libraries for these 
things seem to be sparse.

But in a perfect world.... :)

Seth







-----------------------------------------------------------------------------------
Post ID:1791
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-10 20:33:30
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

On Wed, Jul 10, 2002 at 02:41:41PM -0500, Jeff Bone wrote:
> And that's not a partial description of the desired new state of the
> cart...?

Ok, sub-optimal example. 8-)

There need not be any remnant of the state reflected in the POSTed
entity after processing.  For example, if I POSTed a picture of a hand
to a dog resource, the dog may change state to "recently petted".  But
the fact that a hand induced the state change isn't reflected in the
state of the dog.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1792
Sender:Lucas Gonze <lgonze@...>
Post Date/Time:2002-07-10 20:37:39
Subject:socket-level mods
Message:

I've been musing for a while about how to do everything you see in peer to 
peer with http.  Bidirectional communications are a real blocking factor.

What I mean by bidirectional is allow either side in a transaction to 
initiate requests.  The way to do this in HTTP is to have both sides 
establish a separate connection.  But this doesn't really solve the 
problems.  The problems are:

* long lasting connections.  HTTP is designed around one-shot connections
to pick up some hypertext.  Mechanisms to get a bunch of files keep the
connection open, but only until a batch of related resources have been
transferred.  P2P often uses an ongoing stream.  Now, maybe you can argue
that ongoing streams make no sense, but that's swimming upstream.  You
could argue that P2P designs should be rebuilt to use hypertext, but
that's also swimming upstream.  P2P has gotten a huge amount of thought
put into it and it uses ongoing connections so often for a reason.

* efficiency.  Using two sockets instead of one, plus the cost of 
maintaining open connections, is a brutual efficiency hit.

* firewall transgression.  being able to able to establish a server
connection to a node behind a firewall, by having the server create the
TCP connection but otherwise act as a server, is a critical tool.  few p2p
apps could live without it.

* event mechanisms.  given a single unidirectional connection there is no
way for a server to initiate an event, short of the knownow hack of
running events along the backstream to the client.

* coordinating related events on the two streams.  It is much easier to do
this with a single connection than with two.  (Years ago I actually did
write a coordinator for two connections, and it was a bear to get the
details right.)

I've done enough preliminary hacking in Tomcat to know that I can munge
the socket layer -- exclusively stuff below HTTP -- to support long
lasting connections where both parties can act as a client, server or
both.  But I am queasy about how this interacts with REST design.

The new design would still work by resource modelling.  However it would 
not be oriented towards hypertext, so stuff related to connection keep 
alive would be hairy.  It would not work with existing proxies, but that's 
not a REST issue IMO.  

On the other hand, the new design would be HTTP to the letter, because
HTTP doesn't say anyting about the socket layer.

...thoughts?

- Lucas











-----------------------------------------------------------------------------------
Post ID:1793
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-10 21:06:37
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

On 7/10/02 3:33 PM, "Mark Baker" <distobj@...> wrote:

> On Wed, Jul 10, 2002 at 02:41:41PM -0500, Jeff Bone wrote:
>> And that's not a partial description of the desired new state of the
>> cart...?
> 
> Ok, sub-optimal example. 8-)
> 
> There need not be any remnant of the state reflected in the POSTed
> entity after processing.  For example, if I POSTed a picture of a hand
> to a dog resource, the dog may change state to "recently petted".  But
> the fact that a hand induced the state change isn't reflected in the
> state of the dog.

My point is that there's a difference between "here is a hand, update your
state accordingly" and "change your state to recently petted."

Subtle, but important...  Actually, though, I think we're in violent
agreement and my initial attempt to explain my perspective was rather poor,
leading to the misunderstanding.

Jb







-----------------------------------------------------------------------------------
Post ID:1794
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-07-10 22:08:38
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

>>There need not be any remnant of the state reflected in the POSTed
>>entity after processing.  For example, if I POSTed a picture of a hand
>>to a dog resource, the dog may change state to "recently petted".  But
>>the fact that a hand induced the state change isn't reflected in the
>>state of the dog.
> 
> 
> My point is that there's a difference between "here is a hand, update your
> state accordingly" and "change your state to recently petted."

This is an excellent point that we've had to deal with.  Our network 
application is very RESTful.  All we transfer across the network are new 
representations of objects.  We always need to know, however, who made 
the change, and how it was made.

The fact that the dog is now being petted is not enough.  We needed to 
know the Who and the How as well.  We've wrapped up the Who, How, and 
What into a simple Request.  Just sending the What (dog) wasn't enough.

So the question becomes, when trasnfering the state of the dog, how do I 
also say who's responsible for that state change?  Do I also send a new 
state of a Hand which is now Petting and hyperlink that to a Person?

Or do I bundle up the Who with the What?

Seth







-----------------------------------------------------------------------------------
Post ID:1795
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-11 00:04:40
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

On Wed, Jul 10, 2002 at 04:06:37PM -0500, Jeff Bone wrote:
> My point is that there's a difference between "here is a hand, update your
> state accordingly" and "change your state to recently petted."
> 
> Subtle, but important...  Actually, though, I think we're in violent
> agreement and my initial attempt to explain my perspective was rather poor,
> leading to the misunderstanding.

Yup, sounds like it.  I just like the, IMO simple description that I provided
two emails ago about "passing data".  People are going to tunnel through any
method that goes through a firewall, no matter what it's defined to mean, so
I wouldn't worry so much about the "slippery slope".

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1796
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-11 02:56:47
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

On 7/10/02 7:04 PM, "Mark Baker" <distobj@...> wrote:

> On Wed, Jul 10, 2002 at 04:06:37PM -0500, Jeff Bone wrote:
>> My point is that there's a difference between "here is a hand, update your
>> state accordingly" and "change your state to recently petted."
>> 
>> Subtle, but important...  Actually, though, I think we're in violent
>> agreement and my initial attempt to explain my perspective was rather poor,
>> leading to the misunderstanding.
> 
> Yup, sounds like it.  I just like the, IMO simple description that I provided
> two emails ago about "passing data".  People are going to tunnel through any
> method that goes through a firewall, no matter what it's defined to mean, so
> I wouldn't worry so much about the "slippery slope".

Who the hell are you, and what have you done with Mark Baker? ;-)

Jb







-----------------------------------------------------------------------------------
Post ID:1797
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-07-11 03:11:18
Subject:RE: [rest-discuss] XML/XHTML analogy
Message:

How about "XHTML is to XML as SOAP-HTTP is to HTTP" - would that work?

In other words, I'm waiting for the day when someone uses SOAP as a framework to
create an application protocol like HTTP ;-)

-Philip

S. Mike Dierken wrote:
> How about "XHTML is to XML as C++ is to programming"
> Or "XHTML is to XML as InternetExplorer is to C++"
>
> Mark Baker wrote:
> > I was trying to draw a protocol analogy to XML/XHTML.  The best I could
> > come up with was;
> >
> > XML is to XHTML as HTTP is to Yahoo.







-----------------------------------------------------------------------------------
Post ID:1798
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-11 03:26:46
Subject:Re: [rest-discuss] XML/XHTML analogy
Message:

----- Original Message -----

> How about "XHTML is to XML as SOAP-HTTP is to HTTP" - would that work?
>
> In other words, I'm waiting for the day when someone uses SOAP as a
framework to
> create an application protocol like HTTP ;-)
>
In my 'copious free time' I was going to write a WSDL that had four
methods - get, put, post, delete - and paramters for http headers &
responses, etc. Tunneling HTTP through SOAP. Mainly to see who would pop a
vein...






-----------------------------------------------------------------------------------
Post ID:1799
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-07-11 03:29:12
Subject:RE: [PMX:#] [rest-discuss] REST and HTTP
Message:

Monday, July 08, 2002 9:40 PM, Seairth wrote:
> I agree that HTTP has taken on a lot more over the years. However, it seems
> to me that HTTP 1.1 contains a lot of features that are not necessarily
> RESTful (e.g. persistant connections). In other words, I think that there is
> a subset of HTTP 1.1 that is definitely RESTful.

How is the persistent connections feature not RESTful?  I see it as an approach
defined in the standard to optimize interactions.

Are there other features that you believe are "not necessarily RESTful"?

Thanks,
Philip








-----------------------------------------------------------------------------------
Post ID:1800
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-07-11 03:35:02
Subject:RE: [rest-discuss] Is REST CRUD?
Message:

Jeffrey,

Just to add my two cents before I go to sleep, this (the RFC 2616.9.6
description) is exactly how I interpret the contrast between POST and PUT.  In
REST terms: with PUT I am sending the entity as a representation to create or
replace the resource at the URI provided on the request line; and with POST, I
am sending the entity as a representation that is *subordinate* to the resource
at the URI provided on the request line.

What it means to "create" or "replace" or "send a subordinate" is up to the
server on the other side of the URI.  Heck, for PUT and/or POST, the URI may not
even physically exist.

-Philip

-----Original Message-----
From: Jeffrey Winter [mailto:j.winter@...]
Sent: Wednesday, July 10, 2002 3:37 PM
To: rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] Is REST CRUD?


I agree with Mark on the interpretation of POST.

From the RFC [1]:

    9.6 PUT

       [...]

       The fundamental difference between the POST and PUT requests is
       reflected in the different meaning of the Request-URI. The URI in a
       POST request identifies the resource that will handle the enclosed
       entity. That resource might be a data-accepting process, a gateway to
       some other protocol, or a separate entity that accepts annotations.
       In contrast, the URI in a PUT request identifies the entity enclosed
       with the request -- the user agent knows what URI is intended and the
       server MUST NOT attempt to apply the request to some other resource.

Still, how might subtle differences in interpretation of the non-GET methods
effect the adoption of the REST model?  If web services are built that
don't follow these guidelines strictly enough, what sorts of
problems could emerge for developers attempting to integrate with them?

[1] http://rfc.net/rfc2616.html

----- Original Message -----
From: "Mark Baker" <mbaker@...>
To: <jbone@...>; <robert@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Wednesday, July 10, 2002 8:45 AM
Subject: Re: [rest-discuss] Is REST CRUD?


I don't like your description of POST there Jeff.  POSTed data need not
have anything to do with being a representation of the resource to which
it's being POSTed.  Like POSTing a representation of a pair of shoes to
a shopping cart.

It's just "take this data", with the (critical) proviso that a
successful response just means that the data was accepted, nothing more.
i.e. you need not tunnel with it to use it.

MB

[snip]







-----------------------------------------------------------------------------------
Post ID:1801
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-07-11 03:43:23
Subject:RE: [rest-discuss] XML/XHTML analogy
Message:

Then, send those messages as streams in a standard HTTP-tunnelled RMI/IIOP
method invocation, and you are set to cause some serious cholesterol build-up
;-)

-----Original Message-----
From: S. Mike Dierken [mailto:mdierken@...]
Sent: Wednesday, July 10, 2002 11:27 PM
To: rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] XML/XHTML analogy

----- Original Message -----

> How about "XHTML is to XML as SOAP-HTTP is to HTTP" - would that work?
>
> In other words, I'm waiting for the day when someone uses SOAP as a
framework to
> create an application protocol like HTTP ;-)
>
In my 'copious free time' I was going to write a WSDL that had four
methods - get, put, post, delete - and paramters for http headers &
responses, etc. Tunneling HTTP through SOAP. Mainly to see who would pop a
vein...

To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.







-----------------------------------------------------------------------------------
Post ID:1802
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-11 11:34:43
Subject:Re: [rest-discuss] XML/XHTML analogy
Message:

On Wed, Jul 10, 2002 at 08:26:46PM -0700, S. Mike Dierken wrote:
> In my 'copious free time' I was going to write a WSDL that had four
> methods - get, put, post, delete - and paramters for http headers &
> responses, etc. Tunneling HTTP through SOAP. Mainly to see who would pop a
> vein...

FWIW, Paul (and more recently, me) tried to get the WSDL 1.2 folks to
remove the distinction between WSDL operations and HTTP verbs in the
HTTP binding.  Currently you need both, which pretty much mandates
tunneling over HTTP.

http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0053

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1803
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-11 12:33:44
Subject:Re: [rest-discuss] socket-level mods
Message:

On Wed, Jul 10, 2002 at 04:37:39PM -0400, Lucas Gonze wrote:
> * long lasting connections.  HTTP is designed around one-shot connections
> to pick up some hypertext.  Mechanisms to get a bunch of files keep the
> connection open, but only until a batch of related resources have been
> transferred.  P2P often uses an ongoing stream.  Now, maybe you can argue
> that ongoing streams make no sense, but that's swimming upstream.  You
> could argue that P2P designs should be rebuilt to use hypertext, but
> that's also swimming upstream.  P2P has gotten a huge amount of thought
> put into it and it uses ongoing connections so often for a reason.

HTTP supports "ongoing streams", as you describe them.  Entities can
be streams in HTTP.

> * efficiency.  Using two sockets instead of one, plus the cost of 
> maintaining open connections, is a brutual efficiency hit.

Ok.

> * firewall transgression.  being able to able to establish a server
> connection to a node behind a firewall, by having the server create the
> TCP connection but otherwise act as a server, is a critical tool.  few p2p
> apps could live without it.

Not sure I follow - I think you said "server" once too many times. 8-)

> * event mechanisms.  given a single unidirectional connection there is no
> way for a server to initiate an event, short of the knownow hack of
> running events along the backstream to the client.

Right, but I wouldn't call it a hack.  It seems a fundamental feature
of the generic interface that a client can request events with GET, as
long as those events stop when the connection drops.

> I've done enough preliminary hacking in Tomcat to know that I can munge
> the socket layer -- exclusively stuff below HTTP -- to support long
> lasting connections where both parties can act as a client, server or
> both.  But I am queasy about how this interacts with REST design.
> 
> The new design would still work by resource modelling.  However it would 
> not be oriented towards hypertext, so stuff related to connection keep 
> alive would be hairy.  It would not work with existing proxies, but that's 
> not a REST issue IMO.  
> 
> On the other hand, the new design would be HTTP to the letter, because
> HTTP doesn't say anyting about the socket layer.

I'm a bit wary of the above description.  IMO, not working with existing
proxies is definitely an issue.

Have you considered an HTTP extension method similar to SMTP TURN/ETRN
for turning the connection around?  I guess that might not be sufficient,
since it just flips it, it doesn't permit bi-directional comms over the
same socket simultaneously - but I don't know for sure until I see some
use cases.

And FWIW, you could specify this as a new protocol, but it would be a
new protocol, not HTTP, though you could reuse lots of HTTP.  But if you
read through Section 8 of 2616 while thinking about true 2-way over a
single connection, you'd see that the complexity of both specification
and implementation (i.e. wouldn't be able to reuse any existing HTTP
library) would probably be nasty.  *Much* simpler extensions, such as
draft-mogul-http-ooo-01.txt (out of order responses in pipelining), had
this same problem with existing libraries.

Alternately, you could use CONNECT to create a tunnel, and then the
server could tunnel HTTP back through.  That would probably be simpler,
but firewalls don't typically honour CONNECT, IIRC.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1804
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-11 14:30:08
Subject:Re: [PMX:#] [rest-discuss] REST and HTTP
Message:

Maintaining a connection implicitly means the server itself is maintaining
state.  I agree that it may be a weak argument, but I am pretty sure IIS
(and possibly other HTTP servers) takes advantage of this internally.  Also,
people tend to use the tools available if they think it will help.  It is
highly foreseeable that a server application would take advantage of the
persistent connection to maintain state.  I am not saying that someone who
is mindful of REST would do such a thing.  All I was saying was that HTTP
1.1 contains additional features over HTTP 1.0 that are less RESTful in
nature.

Another argument is that persistent connections potentially do not scale
well.  Yes, a persistent connection does reduce network traffic and latency,
but it also means that a given server can handle fewer connections over a
period of time, especially if the clients and the server are keeping the
connections open, but are otherwise idle.


As for another example of a part of HTTP 1.1 I feel is not RESTful (in my
mind):  the If-Match, If-Modified-Since, If-None-Match, If-Range, and
If-Unmodified-Since header fields (14.24-28).  From my understanding of
these fields, the client is effectively telling the server how to act.  I
was under the impression that a client could submit a representation of a
resource to the server, but the client has no control over what the server
actually does with the resource.  Likewise, I thought that the client has no
control over the representation of the resource returned to it.  However,
these header fields appear to give the client some control over how the
server receives and returns representations of resources.

Of course, since I am still figuring out what REST really is, I fully admit
that I may also be viewing all of this incorrectly...

---
Seairth Jacobs
seairth@...

----- Original Message -----
From: "Philip Eskelin" <philip@...>
To: "'Seairth Jacobs'" <seairth@...>
Cc: "'rest-discuss'" <rest-discuss@yahoogroups.com>
Sent: Wednesday, July 10, 2002 11:29 PM
Subject: RE: [PMX:#] [rest-discuss] REST and HTTP


> Monday, July 08, 2002 9:40 PM, Seairth wrote:
> > I agree that HTTP has taken on a lot more over the years. However, it
seems
> > to me that HTTP 1.1 contains a lot of features that are not necessarily
> > RESTful (e.g. persistant connections). In other words, I think that
there is
> > a subset of HTTP 1.1 that is definitely RESTful.
>
> How is the persistent connections feature not RESTful?  I see it as an
approach
> defined in the standard to optimize interactions.
>
> Are there other features that you believe are "not necessarily RESTful"?
>
> Thanks,
> Philip
>
>
>







-----------------------------------------------------------------------------------
Post ID:1805
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-11 17:16:38
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

----- Original Message -----
From: "Seth Ladd" <seth@...>

>
> So the question becomes, when trasnfering the state of the dog, how do I
> also say who's responsible for that state change?  Do I also send a new
> state of a Hand which is now Petting and hyperlink that to a Person?
>
> Or do I bundle up the Who with the What?
>
I think this is an important issue for real world applications. A simple
approach is to have the request message reference the principal under whose
authority the request is to be carried out - essentially the user ID (or
'was carried out' for events). A more complex approach would involve
verifying the sender has the authority to act on behalf of the principal -
essentially credentials/password (or sessionId or capabilities, etc.).
It would be interesting to make the link to the principal a full URI - and
allow for relative references, etc.
I haven't seen this done though, so it's new ground.

For the standby of HTTP, the Authorization header provides an extensible
format for identifying principals and providing credentials. But I'm not too
sure I like the handshaking/negotiating of usernames/passwords in HTTP - I
don't know of a way for the server to hand out (transient) credentials to
the client - at least not with Web browser user-agents.






-----------------------------------------------------------------------------------
Post ID:1806
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-11 17:26:48
Subject:Re: [rest-discuss] socket-level mods
Message:

----- Original Message -----
From: "Lucas Gonze" <lgonze@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Wednesday, July 10, 2002 1:37 PM
Subject: [rest-discuss] socket-level mods


>
> I've been musing for a while about how to do everything you see in peer to
> peer with http.  Bidirectional communications are a real blocking factor.


> * efficiency.  Using two sockets instead of one, plus the cost of
> maintaining open connections, is a brutual efficiency hit.
I'm not so sure about this - what types/roles are the machines & what
numbers of sockets are you thinking of?
Good sized servers should be able to have 10K open connections without a
problem.

> * firewall transgression.  being able to able to establish a server
> connection to a node behind a firewall, by having the server create the
> TCP connection but otherwise act as a server, is a critical tool.  few p2p
> apps could live without it.
Agreed.

>
> * event mechanisms.  given a single unidirectional connection there is no
> way for a server to initiate an event, short of the knownow hack of
> running events along the backstream to the client.
Hey.. it's not a hack, its 'elegant'...

>
> * coordinating related events on the two streams.  It is much easier to do
> this with a single connection than with two.  (Years ago I actually did
> write a coordinator for two connections, and it was a bear to get the
> details right.)
>
> I've done enough preliminary hacking in Tomcat to know that I can munge
> the socket layer -- exclusively stuff below HTTP -- to support long
> lasting connections where both parties can act as a client, server or
> both.  But I am queasy about how this interacts with REST design.

This is an area I would love to work on - a networking layer that did a
persistent, client-initiated connection and then consumed incoming messages
and delivered them to a regular HTTP server (possibly via jserv sockets to
tomcat or something) as an unsolicited incoming request.
This lets you write server-apps on clients/desktops - use all the tools you
are familiar with - ASP, JSP, servlets, etc. With some COM events, you can
even deliver to Win32 apps. The other pieces you need are public names
(host/domain), an intermediary to do the message transfer/new-protocol, and
some sort of security.
This would 'break' HTTP in that the messages between the client and the
message server would not be visibly HTTP requests - but that's okay.

>
> The new design would still work by resource modelling.  However it would
> not be oriented towards hypertext, so stuff related to connection keep
> alive would be hairy.  It would not work with existing proxies, but that's
> not a REST issue IMO.
I don't think keep-alive is related to hypertext. I don't know why you see
it as different than a persistent connection?
The handshaking is still request/response (except for
chunked-transfer-encoding, but I wouldn't mess with that).

>
> On the other hand, the new design would be HTTP to the letter, because
> HTTP doesn't say anyting about the socket layer.
>
> ...thoughts?
This is what I was talking about a while ago with the asynch-http &
http+events discussion. Can't find the links right now...








-----------------------------------------------------------------------------------
Post ID:1807
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-07-11 19:56:52
Subject:Re: [rest-discuss] socket-level mods
Message:

before going into detail on responses, let me state the problem: I want 
to be able to do anything that Gnutella can do in a RESTy way.  If there 
is a reason why this is a bad idea, I want to hear it.

On Thu, 11 Jul 2002, S. Mike Dierken wrote:
> > * efficiency.  Using two sockets instead of one, plus the cost of
> > maintaining open connections, is a brutual efficiency hit.
> I'm not so sure about this - what types/roles are the machines & what
> numbers of sockets are you thinking of?
> Good sized servers should be able to have 10K open connections without a
> problem.

maybe I'm plain wrong.  I'll hold off on declaring this a showstopper. ;)

> > * event mechanisms.  given a single unidirectional connection there is no
> > way for a server to initiate an event, short of the knownow hack of
> > running events along the backstream to the client.
> Hey.. it's not a hack, its 'elegant'...

hold the fort til you code it.  man what a hairy mess.  plus, requests 
received over a response channel are http tunnelled through http, which is 
a bad idea.

> 
> >
> > * coordinating related events on the two streams.  It is much easier to do
> > this with a single connection than with two.  (Years ago I actually did
> > write a coordinator for two connections, and it was a bear to get the
> > details right.)
> >
> > I've done enough preliminary hacking in Tomcat to know that I can munge
> > the socket layer -- exclusively stuff below HTTP -- to support long
> > lasting connections where both parties can act as a client, server or
> > both.  But I am queasy about how this interacts with REST design.
> 
> This is an area I would love to work on - a networking layer that did a
> persistent, client-initiated connection and then consumed incoming messages
> and delivered them to a regular HTTP server (possibly via jserv sockets to
> tomcat or something) as an unsolicited incoming request.

It's very doable.  There are a lot of assumptions in the 
tomcat code that you won't do it, but I haven't hit any hard blocks so 
far.  (Can't say the same for Jetty etc.  It's a credit to tomcat's clean 
design that this is doable.).

> 
> >
> > The new design would still work by resource modelling.  However it would
> > not be oriented towards hypertext, so stuff related to connection keep
> > alive would be hairy.  It would not work with existing proxies, but that's
> > not a REST issue IMO.
> I don't think keep-alive is related to hypertext. I don't know why you see
> it as different than a persistent connection?
> The handshaking is still request/response (except for
> chunked-transfer-encoding, but I wouldn't mess with that).

I'm thinking of Roy's dissertation, where he is very clear that there was 
an expected granularity of content, which is the granularity of hypertext.

> 
> >
> > On the other hand, the new design would be HTTP to the letter, because
> > HTTP doesn't say anyting about the socket layer.
> >
> > ...thoughts?
> This is what I was talking about a while ago with the asynch-http &
> http+events discussion. Can't find the links right now...

Nice.  It's what I was thinking about too.  The purpose of that whole
thing for me was to understand what (if anything) had to be done.








-----------------------------------------------------------------------------------
Post ID:1808
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-07-11 20:05:28
Subject:Re: [rest-discuss] socket-level mods
Message:

> > * firewall transgression.  being able to able to establish a server
> > connection to a node behind a firewall, by having the server create the
> > TCP connection but otherwise act as a server, is a critical tool.  few p2p
> > apps could live without it.
> 
> Not sure I follow - I think you said "server" once too many times. 8-)

ack.  Last time around we resorted to source/sink to have clear language 
in this setting.  What I'm thinking of is the TURN/ETRN functionality you 
mention below.

> 
> > * event mechanisms.  given a single unidirectional connection there is no
> > way for a server to initiate an event, short of the knownow hack of
> > running events along the backstream to the client.
> 
> Right, but I wouldn't call it a hack.  It seems a fundamental feature
> of the generic interface that a client can request events with GET, as
> long as those events stop when the connection drops.

Yes, but if the events are themselves requests you are tunnelling http in 
http.  If that's not evil I wnat to know why not.

> > On the other hand, the new design would be HTTP to the letter, because
> > HTTP doesn't say anyting about the socket layer.
> 
> I'm a bit wary of the above description.  IMO, not working with existing
> proxies is definitely an issue.

To the degree that it matters, it is a doable change to modify (some but 
not all) existing proxies.  One thing at a time.

> Have you considered an HTTP extension method similar to SMTP TURN/ETRN
> for turning the connection around?  I guess that might not be sufficient,
> since it just flips it, it doesn't permit bi-directional comms over the
> same socket simultaneously - but I don't know for sure until I see some
> use cases.

As always, I really really object to adding new methods.  There's a reason 
why I want to go _below_ HTTP to make mods like this.

> 
> And FWIW, you could specify this as a new protocol, but it would be a
> new protocol, not HTTP, though you could reuse lots of HTTP.  But if you
> read through Section 8 of 2616 while thinking about true 2-way over a
> single connection, you'd see that the complexity of both specification
> and implementation (i.e. wouldn't be able to reuse any existing HTTP
> library) would probably be nasty.  *Much* simpler extensions, such as
> draft-mogul-http-ooo-01.txt (out of order responses in pipelining), had
> this same problem with existing libraries.

You have to specify it as a new protocol because it would break existing
implementations.  However I read the spec fairly carefully to find
anything about this new protocol that was in conflict and found absolutely
nothing.  The RFC requires nothing at at the transport layer.

My working plan is to use the HTTP Upgrade: response header with a value
for the new protocol of "AC-HTTP".  "AC" meaning "alternating current."

> Alternately, you could use CONNECT to create a tunnel, and then the
> server could tunnel HTTP back through.  That would probably be simpler,
> but firewalls don't typically honour CONNECT, IIRC.

Plus you still have the rest of the problems to face.  EG, 
incompatibility.









-----------------------------------------------------------------------------------
Post ID:1809
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-11 21:22:32
Subject:Re: [rest-discuss] socket-level mods
Message:

>
> > > * event mechanisms.  given a single unidirectional connection there is
no
> > > way for a server to initiate an event, short of the knownow hack of
> > > running events along the backstream to the client.
> > Hey.. it's not a hack, its 'elegant'...
>
> hold the fort til you code it.  man what a hairy mess.  plus, requests
> received over a response channel are http tunnelled through http, which is
> a bad idea.
It's easy to code javascript clients for KN. Keeping the server from chewing
up memory is a problem - I've stopped running mine.

Why is tunneling HTTP through HTTP a bad idea? If the resource is a queue of
messages - and the representation of the message is mime type "message/http"
, then that is exactly what you are /supposed/ to do. Right?

(This leads into my 'expanding the web onto desktops works in rest/http, but
breaks in the real world' talk, which I'll have to find some time to write
up fully...)


> >
> > >
> > > The new design would still work by resource modelling.  However it
would
> > > not be oriented towards hypertext, so stuff related to connection keep
> > > alive would be hairy.  It would not work with existing proxies, but
that's
> > > not a REST issue IMO.
> > I don't think keep-alive is related to hypertext. I don't know why you
see
> > it as different than a persistent connection?
> > The handshaking is still request/response (except for
> > chunked-transfer-encoding, but I wouldn't mess with that).
>
> I'm thinking of Roy's dissertation, where he is very clear that there was
> an expected granularity of content, which is the granularity of hypertext.
Hypertext on the web has no 'bounded object set' - so the granularity is
infinite. An individual message corresponds to about the size of a single
portion of hypertext we normally call a document, so I don't see the
problem.







-----------------------------------------------------------------------------------
Post ID:1810
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-11 21:36:31
Subject:Re: [rest-discuss] socket-level mods
Message:

Lucas Gonze wrote:
> 
> before going into detail on responses, let me state the problem: I want
> to be able to do anything that Gnutella can do in a RESTy way.  If there
> is a reason why this is a bad idea, I want to hear it.

I'm not familiar with the Gnutella protocol. Maybe you could outline the
major message types, resource types and addressing facilities or point
to a good summarizing URI.

To me the most fundamental problem is the same problem with all p2p
apps: clients can be behind NAT and have no global addresses. So yes,
you do need a TURN/ETRN and it won't be backwards compatible. My
instinct is to have the client open a socket and ask for a backchannel
with a POST. The server creates a "listener" and returns the port number
and maybe some authentication data. The client connects *not* using HTTP
but using a "reversible socket protocol". The client and server
understand that on the reversed socket they have swapped roles.

You can push the idea beyond HTTP. Reversable FTP would allow machines
behind firewalls to publish FTP servers by pushing a reversed FTP
connection to a "publishing intermediary." Same with reversable telnet.
I don't have time right now to think through exactly how this differs
from regular port forwarding but it feels like push versus pull. I can
tell SSH: "forward FTP requests to my laptop" but I can't tell it: "wait
for a signal from the laptop and then and only then should you forward
FTP requests." Of course I can organize this connection out-of-band in a
proprietary way.

I doubt this idea is compatible with all existing infrastructure, but
there is no solution that will be 100% compatible with existing
infrastructure *except* tunnelling. By definition turning the existing
one-way architecture into a two-way one requires either extension or
tunnelling. If you care about the marketability of your protocol, it
should probably provide both options.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1811
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-11 22:03:19
Subject:Re: [rest-discuss] socket-level mods
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> To me the most fundamental problem is the same problem with all p2p
> apps: clients can be behind NAT and have no global addresses. So yes,
> you do need a TURN/ETRN and it won't be backwards compatible. My
> instinct is to have the client open a socket and ask for a backchannel
> with a POST. The server creates a "listener" and returns the port number
> and maybe some authentication data. The client connects *not* using HTTP
> but using a "reversible socket protocol". The client and server
> understand that on the reversed socket they have swapped roles.

Yes - this sounds good. REST by its nature has 'passive resources' and
'active clients' that initiate operations upon those resources - it
inherently implies direction of messaging. To implement this in the real
world - as with http - you naively open a connection to the resource - but
if it is behind a firewall then you can't. Hence Paul's suggestion -
separate who /initiates/ the networking from the /direction/ of messages. I
don't have a problem with the protocol for behind-the-firewall access being
non-HTTP or at least non-sanctioned HTTP clone. I don't think it is
/required/ to avoid HTTP (tunneling 'message/http' for example) for it to
work - perhaps to make it more efficient, but people are at zero today,
anything is an improvement.








-----------------------------------------------------------------------------------
Post ID:1812
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-07-11 23:21:39
Subject:Re: [rest-discuss] socket-level mods
Message:

Mike Dierken wrote:
> It's easy to code javascript clients for KN. Keeping the server from chewing
> up memory is a problem - I've stopped running mine.

Do you mean writing the javascript client from scratch or using the KN 
library, Mike?

> Why is tunneling HTTP through HTTP a bad idea? If the resource is a queue of
> messages - and the representation of the message is mime type "message/http"
> , then that is exactly what you are /supposed/ to do. Right?

Anytime I've tried to work out the details things got messy.  I have yet 
to see a situation where message-in-message made sense.  It doesn't make 
sense because messages are about streams rather than resources.  

> > I'm thinking of Roy's dissertation, where he is very clear that there was
> > an expected granularity of content, which is the granularity of hypertext.

> Hypertext on the web has no 'bounded object set' - so the granularity is
> infinite. An individual message corresponds to about the size of a single
> portion of hypertext we normally call a document, so I don't see the
> problem.

Hm, I need to think about this.  Is my sense that hypertext is a different 
thing just a mental block?  There's a lot of blather about hypertext 
as a specific kind of content, but now I realize that I really don't 
know what it means.

- Lucas








-----------------------------------------------------------------------------------
Post ID:1813
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-07-11 23:41:29
Subject:Re: [rest-discuss] socket-level mods
Message:

Paul Prescod said:
> I'm not familiar with the Gnutella protocol. Maybe you could outline the
> major message types, resource types and addressing facilities or point
> to a good summarizing URI.

It's totally brain dead but still hard to do with HTTP.  What you need to 
know is that a connection is a continuous stream of message events.  An 
outgoing message may have 0, 1, or more responses.  The mechanics of 
store-and-forward are mashed into the message along with application 
functionality.  

Documentation for the 0.4 version of the protocol:
http://www.rixsoft.com/Knowbuddy/gnutellafaq.html

There are many things about it that I don't want to emulate.  What I do 
want is how trivial it makes asynchronous messaging in a p2p context.

> To me the most fundamental problem is the same problem with all p2p
> apps: clients can be behind NAT and have no global addresses. So yes,
> you do need a TURN/ETRN and it won't be backwards compatible. My
> instinct is to have the client open a socket and ask for a backchannel
> with a POST. The server creates a "listener" and returns the port number
> and maybe some authentication data. The client connects *not* using HTTP
> but using a "reversible socket protocol". The client and server
> understand that on the reversed socket they have swapped roles.

No doubt.  but what is the reversible socket protocol?  The most
parsimonious solution to my mind is that it's 100% HTTP 1.1, except that
the transport layer underneath is different.  Is there any architectural
reason why this wouldn't work?

A total digression: the fundamental problem with p2p is that the network
is self-organizing in a way that affects your moment to moment
interactions.  With browser-oriented applications the self-organizing
macro structure is too big to be visible usually.

> I doubt this idea is compatible with all existing infrastructure, but
> there is no solution that will be 100% compatible with existing
> infrastructure *except* tunnelling. By definition turning the existing
> one-way architecture into a two-way one requires either extension or
> tunnelling. If you care about the marketability of your protocol, it
> should probably provide both options.

It's incompatible in a wierd way.  99.99% of the thought that went into
HTTP can be reused.  All HTTP implementations need a little bit of hacking
to be compatible.  All HTTP-based applications need a total rewrite.  The
loss is that it's a new protocol, the win is that the new protocol is also
HTTP.  ...that's the idea anyway.









-----------------------------------------------------------------------------------
Post ID:1814
Sender:Allan Doyle <adoyle@...>
Post Date/Time:2002-07-12 00:21:53
Subject:Re: [rest-discuss] socket-level mods
Message:

I may be totally off base here, and would need to do some experiments,
but given that HTTP runs over TCP, isn't it the case that a request
sent to a server can be held by the server nearly indefinitely before
it sends a reply? 

If so, then one thing I learned from rubbing elbows with the old
CORBUS system at BBN is something called "futures". If a client makes
a request to a server, and that server hangs onto the request while
the client merrily goes on its way, then when the response eventually
comes, the client can treat it as an asynchronous message from the
server. If the server cleverly puts content into the reply, voila,
your client can wake up and deal with it.

If the TCP connection breaks, or the HTTP server times out and shuts
it down, the client would get a different signal/error. Then client
could then decide whether to send another future request or do
something else. In any case, you are buying time and leaving open a
means for an async notification.

This would move the problem up one level and you would not have to
muck with HTTP. The only issue is whether the breakage level is too
high, causing overconsumption of resources. Then you do have to work
on some optimizations (potentially even rewriting HTTP).

     Allan


On Thursday 2002-07-11 at 19:41:29(-0400) Lucas Gonze wrote:
 > Paul Prescod said:
 > > I'm not familiar with the Gnutella protocol. Maybe you could outline the
 > > major message types, resource types and addressing facilities or point
 > > to a good summarizing URI.
 > 
 > It's totally brain dead but still hard to do with HTTP.  What you need to 
 > know is that a connection is a continuous stream of message events.  An 
 > outgoing message may have 0, 1, or more responses.  The mechanics of 
 > store-and-forward are mashed into the message along with application 
 > functionality.  
 > 
 > Documentation for the 0.4 version of the protocol:
 > http://www.rixsoft.com/Knowbuddy/gnutellafaq.html
 > 
 > There are many things about it that I don't want to emulate.  What I do 
 > want is how trivial it makes asynchronous messaging in a p2p context.
 > 
 > > To me the most fundamental problem is the same problem with all p2p
 > > apps: clients can be behind NAT and have no global addresses. So yes,
 > > you do need a TURN/ETRN and it won't be backwards compatible. My
 > > instinct is to have the client open a socket and ask for a backchannel
 > > with a POST. The server creates a "listener" and returns the port number
 > > and maybe some authentication data. The client connects *not* using HTTP
 > > but using a "reversible socket protocol". The client and server
 > > understand that on the reversed socket they have swapped roles.
 > 
 > No doubt.  but what is the reversible socket protocol?  The most
 > parsimonious solution to my mind is that it's 100% HTTP 1.1, except that
 > the transport layer underneath is different.  Is there any architectural
 > reason why this wouldn't work?
 > 
 > A total digression: the fundamental problem with p2p is that the network
 > is self-organizing in a way that affects your moment to moment
 > interactions.  With browser-oriented applications the self-organizing
 > macro structure is too big to be visible usually.
 > 
 > > I doubt this idea is compatible with all existing infrastructure, but
 > > there is no solution that will be 100% compatible with existing
 > > infrastructure *except* tunnelling. By definition turning the existing
 > > one-way architecture into a two-way one requires either extension or
 > > tunnelling. If you care about the marketability of your protocol, it
 > > should probably provide both options.
 > 
 > It's incompatible in a wierd way.  99.99% of the thought that went into
 > HTTP can be reused.  All HTTP implementations need a little bit of hacking
 > to be compatible.  All HTTP-based applications need a total rewrite.  The
 > loss is that it's a new protocol, the win is that the new protocol is also
 > HTTP.  ...that's the idea anyway.
 > 
 > 
 > 
 > 
 > 
 > To unsubscribe from this group, send an email to:
 > rest-discuss-unsubscribe@yahoogroups.com
 > 
 >  
 > 
 > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
 > 
 > 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle                         http://www.intl-interfaces.com
adoyle@...







-----------------------------------------------------------------------------------
Post ID:1815
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-12 00:48:23
Subject:Re: [rest-discuss] socket-level mods
Message:

----- Original Message -----
From: "Lucas Gonze" <lgonze@...>



> Mike Dierken wrote:
> > It's easy to code javascript clients for KN. Keeping the server from
chewing
> > up memory is a problem - I've stopped running mine.
>
> Do you mean writing the javascript client from scratch or using the KN
> library, Mike?
The javascript client isn't that hard to write from scratch - doing multiple
windows communication in a browser is hard.

>
> > Why is tunneling HTTP through HTTP a bad idea? If the resource is a
queue of
> > messages - and the representation of the message is mime type
"message/http"
> > , then that is exactly what you are /supposed/ to do. Right?
>
> Anytime I've tried to work out the details things got messy.  I have yet
> to see a situation where message-in-message made sense.  It doesn't make
> sense because messages are about streams rather than resources.
Yeah... I'd rather see the connection opened by the client & the roles
reversed via a magic command - how about a new HTTP method of 'LISTEN'?







-----------------------------------------------------------------------------------
Post ID:1816
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-07-12 00:51:49
Subject:Re: [rest-discuss] socket-level mods
Message:

> The javascript client isn't that hard to write from scratch - doing multiple
> windows communication in a browser is hard.

cool.  I didn't know that.  ...figured that the interactions with the 
server would be too intimate to make the client-side protocol generic.

> Yeah... I'd rather see the connection opened by the client & the roles
> reversed via a magic command - how about a new HTTP method of 'LISTEN'?

Not sure it's necessary!  I think that you can use the Upgrade header --  
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42

' The Upgrade header field is intended to provide a simple mechanism for 
transition from HTTP/1.1 to some other, incompatible protocol. It does so 
by allowing the client to advertise its desire to use another protocol, 
such as a later version of HTTP with a higher major version number, even 
though the current request has been made using HTTP/1.1. This eases the 
difficult transition between incompatible protocols by allowing the 
client to initiate a request in the more commonly supported protocol 
while indicating to the server that it would like to use a "better" 
protocol if available (where "better" is determined by the server, 
possibly according to the nature of the method and/or resource being 
requested). '

(major caveat emptor on everything I have to say here: the only actual
code I have is a bunch of munged Tomcat source.)







-----------------------------------------------------------------------------------
Post ID:1817
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-12 02:36:17
Subject:Re: [rest-discuss] socket-level mods
Message:

Note that I've set followups to rest-explore - I think we're well past
the introductory level here. 8-)

On Thu, Jul 11, 2002 at 04:05:28PM -0400, Lucas Gonze wrote:
> > Right, but I wouldn't call it a hack.  It seems a fundamental feature
> > of the generic interface that a client can request events with GET, as
> > long as those events stop when the connection drops.
> 
> Yes, but if the events are themselves requests you are tunnelling http in 
> http.  If that's not evil I wnat to know why not.

It is, but event notifications received on a GET aren't requests,
they're responses.  There's no tunneling going on.

> As always, I really really object to adding new methods.  There's a reason 
> why I want to go _below_ HTTP to make mods like this.

[snip]

> You have to specify it as a new protocol because it would break existing
> implementations.  However I read the spec fairly carefully to find
> anything about this new protocol that was in conflict and found absolutely
> nothing.  The RFC requires nothing at at the transport layer.

[snip]

> My working plan is to use the HTTP Upgrade: response header with a value
> for the new protocol of "AC-HTTP".  "AC" meaning "alternating current."

Those 3 paragraphs above seem contradictory to me.  In the last one,
you say that you're using the Upgrade header, and naming it akin to
HTTP, both which suggest that your protocol is an application protocol.
Yet your first and second paragraphs suggest that it's below an
application protocol.

If by "Upgrade" header, you were referring to your AC-HTTP, and
using its upgrade mechanism to upgrade to HTTP, then I think we're in
synch - at least I understand what you're suggesting.  But it doesn't
seem so.

Anyhow, I believe that the application protocol idea is the right
approach, and also this protocol should be an HTTP extension.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1818
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-12 03:06:18
Subject:Futures
Message:

On Thu, Jul 11, 2002 at 08:21:53PM -0400, Allan Doyle wrote:
> If so, then one thing I learned from rubbing elbows with the old
> CORBUS system at BBN is something called "futures". If a client makes
> a request to a server, and that server hangs onto the request while
> the client merrily goes on its way, then when the response eventually
> comes, the client can treat it as an asynchronous message from the
> server. If the server cleverly puts content into the reply, voila,
> your client can wake up and deal with it.

Right.  I've built this with the HTTP 202 response, and using the
Location header to return a URI that identifies the future.  Then I
just poll (with GET) the URI for the response.  It works well.
Very RESTful too.  Roy likes to talk about the ability for URIs to
identify resources that don't exist yet (the same way any identifier
or name can, e.g. "me in 20 years"), so this is a great demonstration
of that feature.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1819
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-12 03:02:34
Subject:Re: [rest-discuss] socket-level mods
Message:

Lucas Gonze wrote:
> 
>...
> 
> > To me the most fundamental problem is the same problem with all p2p
> > apps: clients can be behind NAT and have no global addresses. So yes,
> > you do need a TURN/ETRN and it won't be backwards compatible. My
> > instinct is to have the client open a socket and ask for a backchannel
> > with a POST. The server creates a "listener" and returns the port number
> > and maybe some authentication data. The client connects *not* using HTTP
> > but using a "reversible socket protocol". The client and server
> > understand that on the reversed socket they have swapped roles.
> 
> No doubt.  but what is the reversible socket protocol?  The most
> parsimonious solution to my mind is that it's 100% HTTP 1.1, except that
> the transport layer underneath is different.  Is there any architectural
> reason why this wouldn't work?

Right, my point was that the reversible TCP protocol would be a thin
transport layer that just reverses a TCP connection. When you use an
application protocol on top of a reverse TCP connection, whoever
initiated the TCP connection behaves as if they had received it and vice
versa.

> A total digression: the fundamental problem with p2p is that the network
> is self-organizing in a way that affects your moment to moment
> interactions.  With browser-oriented applications the self-organizing
> macro structure is too big to be visible usually.

That's true but I don't see it as particularly a problem that causes
issues for REST.

>....
> It's incompatible in a wierd way.  99.99% of the thought that went into
> HTTP can be reused.  All HTTP implementations need a little bit of hacking
> to be compatible.  All HTTP-based applications need a total rewrite.  The
> loss is that it's a new protocol, the win is that the new protocol is also
> HTTP.  ...that's the idea anyway.

I'm not sure about this rewrite stuff. For Morpheus ran an HTTP server
on each client to share files. You could browse someone else's share
just with a browser. Clueless media people treated this as a "security
hole."

 *
http://slashdot.org/comments.pl?sid=27368&cid=0&pid=0&startat=&threshold=5&mode=flat&commentsort=0&op=Change

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1820
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-12 03:57:04
Subject:rest-discuss gets some press
Message:

http://www.xml.com/pub/a/2002/07/10/rest.html

Cool, we're even "*the* REST mailing list"!

Note to Kendall; PROPFIND is unRESTful. 8-)  See;

http://lists.w3.org/Archives/Public/www-tag/2002Feb/0091

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1821
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-12 03:48:41
Subject:Re: [PMX:#] [rest-discuss] REST and HTTP
Message:

On 7/11/02 9:30 AM, "Seairth Jacobs" <seairth@...> wrote:

> Maintaining a connection implicitly means the server itself is maintaining
> state.  I agree that it may be a weak argument, but I am pretty sure IIS
> (and possibly other HTTP servers) takes advantage of this internally.  Also,
> people tend to use the tools available if they think it will help.  It is
> highly foreseeable that a server application would take advantage of the
> persistent connection to maintain state.  I am not saying that someone who
> is mindful of REST would do such a thing.  All I was saying was that HTTP
> 1.1 contains additional features over HTTP 1.0 that are less RESTful in
> nature.

Small but important point.  This is a similar confusion to that with
client-server, wherein the question of who initiates the TCP connection
isn't really the issue but rather who makes the (app-level) request and who
responds in a given interaction.

Connection lifecycle does not impact RESTfulness at all --- it is VERY
important to distinguish between the details of the lower level transport
and sessions issues and the application semantics provided by the higher
protocol stack layers.  HTTP is an application-level protocol, and REST is
*definitely* in the business of describing resources and which requests they
service / what kind of responses they give.  HTTP should not and REST does
not have anything to say about the abstraction that we call a TCP
connection.  Now in fact, earlier revs of HTTP do in fact prescribe certain
app-level semantics that are tightly tied to the TCP connection semantics,
but this should be viewed as a mistake and, indeed, later versions have
moved (albeit slowly) away from this tight coupling.  A future, superior
version of the HTTP spec will define HTTP in terms independent of its
lower-layer protocols, and describe each binding of HTTP to a lower-level
substrate independently of the application semantics.

Short version:  HTTP is conceptually independent of and REST is certainly
independent of both the direction and duration of lower-level connections /
sessions / what have you.

> 
> Another argument is that persistent connections potentially do not scale
> well.  Yes, a persistent connection does reduce network traffic and latency,
> but it also means that a given server can handle fewer connections over a
> period of time, especially if the clients and the server are keeping the
> connections open, but are otherwise idle.

This is a detail of TCP stack implementations in various operating systems,
not a limitation with the abstract notion of persistent connections.  Now,
it's an important practical concern --- but given the alternatives the right
answer may be to reimplement or at least tune / tweak the lower-layer
protocol stack.  Cf. KnowNow.  TCP doesn't really have so much state that
it's impractical for a single device to service >10k simultaneous
connections;  this typical limitation is simply an example of bad
engineering.

> 
> As for another example of a part of HTTP 1.1 I feel is not RESTful (in my
> mind):  the If-Match, If-Modified-Since, If-None-Match, If-Range, and
> If-Unmodified-Since header fields (14.24-28).  From my understanding of
> these fields, the client is effectively telling the server how to act.

I'm somewhat inclined to agree with some of this;  If-Mod* and If-Unmod* are
probably okay because they are describing what they  want in terms
independent of some representation, but the rest presuppose some particular
representation.  

> I
> was under the impression that a client could submit a representation of a
> resource to the server, but the client has no control over what the server
> actually does with the resource.  Likewise, I thought that the client has no
> control over the representation of the resource returned to it.

All they can do is ask for what they want;  this should be in terms of what
they want of the resource, not what they want as a representation.  I.e.,
mod time says something about the resource;  range does not.

Jb







-----------------------------------------------------------------------------------
Post ID:1822
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-12 03:59:37
Subject:Re: [rest-discuss] socket-level mods
Message:

On 7/11/02 5:03 PM, "S. Mike Dierken" <mdierken@...> wrote:

> ----- Original Message -----
> From: "Paul Prescod" <paul@...>
> 
>> To me the most fundamental problem is the same problem with all p2p
>> apps: clients can be behind NAT and have no global addresses. So yes,
>> you do need a TURN/ETRN and it won't be backwards compatible. My
>> instinct is to have the client open a socket and ask for a backchannel
>> with a POST. The server creates a "listener" and returns the port number
>> and maybe some authentication data. The client connects *not* using HTTP
>> but using a "reversible socket protocol". The client and server
>> understand that on the reversed socket they have swapped roles.
> 
> Yes - this sounds good. REST by its nature has 'passive resources' and
> 'active clients' that initiate operations upon those resources - it
> inherently implies direction of messaging. To implement this in the real
> world - as with http - you naively open a connection to the resource - but
> if it is behind a firewall then you can't.

Yes definitely.

Quick question - is the assumption of a friendly, non-firewalled / NAT'd
intermediary a problem?  If not, the simplest / most RESTful solution may
simply be to allow the party behind the firewall to run a regular HTTP
server, allow that "blocked" party to establish a tunnel (HTTP, presumably)
to the third party, and subsequently adopt all of the port 80 traffic to
that intermediary or, better, by engaging in a RESTful protocol *adopt* a
portion of the intermediary's HTTP namespace.  Requests to the intermediary
are then funneled down the backchannel to the client, where they are locally
dispatched onto the local HTTP server, and responses channeled back along
the reverse path.

This portion is a lot like mounting a filesystem from one server on another
server then subsequently mounting the filesystem from the second server on
some client for access --- except it deals directly with the directionality
problem of HTTP.

> Hence Paul's suggestion -
> separate who /initiates/ the networking from the /direction/ of messages. I
> don't have a problem with the protocol for behind-the-firewall access being
> non-HTTP or at least non-sanctioned HTTP clone.

Actually I do, but only in that I see it proliferating protocols and code
where it's strictly speaking neither optimal or necessary.

Jb







-----------------------------------------------------------------------------------
Post ID:1823
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-12 04:15:11
Subject:Re: [rest-discuss] rest-discuss gets some press
Message:

On 7/11/02 10:57 PM, "Mark Baker" <distobj@...> wrote:

> 
> Note to Kendall; PROPFIND is unRESTful. 8-)

Ah, this gives me such great satisfaction.  *-))


Jb







-----------------------------------------------------------------------------------
Post ID:1824
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-12 04:20:52
Subject:Re: [rest-discuss] socket-level mods
Message:

> > The javascript client isn't that hard to write from scratch - doing
multiple
> > windows communication in a browser is hard.
>
> cool.  I didn't know that.  ...figured that the interactions with the
> server would be too intimate to make the client-side protocol generic.
Just take a look at the script that comes down from a KN page - essentially
there is a hidden frame that receives the streaming response from the
server. The response is set of <form id="msg_id"> elements - which are DOM
accessible in all browsers - followed by a <script> tag which calls a parent
frame callback with the msg_id - the DOM node gets passed essentially.
Browsers parse the <form> and interpret the <script> in a streaming
fashion - so things happen right away. Simplicity itself. The only tricky
parts are the cross-frame and cross-window (and cross-domain) scripting.

>
> > Yeah... I'd rather see the connection opened by the client & the roles
> > reversed via a magic command - how about a new HTTP method of 'LISTEN'?
>
> Not sure it's necessary!  I think that you can use the Upgrade header --
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42
>
> ' The Upgrade header field is intended to provide a simple mechanism for
> transition from HTTP/1.1 to some other, incompatible protocol. It does so
> by allowing the client to advertise its desire to use another protocol,
> such as a later version of HTTP with a higher major version number, even
> though the current request has been made using HTTP/1.1. This eases the
> difficult transition between incompatible protocols by allowing the
> client to initiate a request in the more commonly supported protocol
> while indicating to the server that it would like to use a "better"
> protocol if available (where "better" is determined by the server,
> possibly according to the nature of the method and/or resource being
> requested). '
>
> (major caveat emptor on everything I have to say here: the only actual
> code I have is a bunch of munged Tomcat source.)
>
I'm thinking that taking mod_jserv (or whatever the mod it that talks the
apjserv protocol between apache & tomcat) and changing it to look for the
new method or 'upgrade' header and responding with OK and then forwarding
any further requests down the jserv connection - which what the mod_jserv
already does! The jserv startup would need configuration for what host & url
to 'attach/mount' and then do the http request with the method or header.
All the existing security (including the 'upgrade' request) would take place
in the hosted Apache server outside the firewall.

Oh, for some spare time...







-----------------------------------------------------------------------------------
Post ID:1825
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-12 04:23:48
Subject:Re: [rest-discuss] socket-level mods
Message:

> >
> > Yeah... I'd rather see the connection opened by the client & the roles
> > reversed via a magic command - how about a new HTTP method of 'LISTEN'?
> >
>
> Aaaargh!
>
> Seriously:  GET, PUT, POST, DELETE are all *clearly* about the resource
> named.  I.e., if they're the verbs, the named resources is the *direct
> object*, not the *subject.*  What resource exactly does a "LISTEN" apply
to?
> And if you tell me it's a way to subscribe to events from the named
> resource, how is that different from GET?  And if you tell me it's because
> those events are asynchronously delivered, potentially to some other
> resource named in the original request, how does that differ from i.e. The
> HTTP Events proposal and similar / related proposals?

Ok... a GET probably would work with an 'upgrade' header - I'm just looking
for some way to signal the role reversal that seems to be needed to assist
firewalled nodes.






-----------------------------------------------------------------------------------
Post ID:1826
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-12 04:30:26
Subject:Re: [rest-discuss] socket-level mods
Message:

> Yes definitely.
>
> Quick question - is the assumption of a friendly, non-firewalled / NAT'd
> intermediary a problem?  If not, the simplest / most RESTful solution may
> simply be to allow the party behind the firewall to run a regular HTTP
> server, allow that "blocked" party to establish a tunnel (HTTP,
presumably)
> to the third party, and subsequently adopt all of the port 80 traffic to
> that intermediary or, better, by engaging in a RESTful protocol *adopt* a
> portion of the intermediary's HTTP namespace.  Requests to the
intermediary
> are then funneled down the backchannel to the client, where they are
locally
> dispatched onto the local HTTP server, and responses channeled back along
> the reverse path.
Yes! I want the behind-the-firewall node to 'adopt/mount' a namespace hosted
by the intermediary.
Requests - after the 'mount' operation - would then flow down the connection
to the firewalled node. 99% of this technology already exists. The
firewalled node can attach the connection to existing HTTP/MIME parsers and
dispatch accordingly - run some JSP or ASP or whatever.

>
> This portion is a lot like mounting a filesystem from one server on
another
> server then subsequently mounting the filesystem from the second server on
> some client for access --- except it deals directly with the
directionality
> problem of HTTP.
Yes! Since REST (in my opinion) has fundamental directionality associated
with resources (the resource is always the 'server') in order to grow the
Web by the next factor of 10,000x we need to enable more machines -
desktops, etc. This is a lot more attractive at solving real world problems
than the PedanticWeb.


>
> > Hence Paul's suggestion -
> > separate who /initiates/ the networking from the /direction/ of
messages. I
> > don't have a problem with the protocol for behind-the-firewall access
being
> > non-HTTP or at least non-sanctioned HTTP clone.
>
> Actually I do, but only in that I see it proliferating protocols and code
> where it's strictly speaking neither optimal or necessary.
>
If it's not necessary, I wouldn't do it either. I envision HTTP requests
flowing down the connection and responses flowing back up in exactly the
same fashion as non-firewalled node - only there is an out-of-phase mark
when the two machines switch roles. This may confuse intermediaries, but
with Lucas' upgrade header, this may be legal.








-----------------------------------------------------------------------------------
Post ID:1827
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-12 04:26:00
Subject:Re: [rest-discuss] socket-level mods
Message:

On 7/11/02 11:23 PM, "S. Mike Dierken" <mdierken@...> wrote:

> 
> Ok... a GET probably would work with an 'upgrade' header - I'm just looking
> for some way to signal the role reversal that seems to be needed to assist
> firewalled nodes.

Granted, that's important, desirable, and appropriate.  It should IMO be a
header and / or an additional server-initiated NOTIFY "response" method,
latter of which should not be directed to a resource but (as certain other
methods, like OPTIONS) directed to a namespace / message dispatching
authority.  My reasoning for the latter is a bit involved but IIRC well
documented in the discussion of HTTP Events.

Short version:  doing it thus avoids presupposing a "model" for resources
which accept events and affords much greater flexibility for server
implementations.  Also plays nicely with caches for the purpose of cache
expiry notifications, which shouldn't be directed to a reified cache but to
an authority.  There might be other motivations for reifying caches, but
this isn't one of them.  Making subscribers authorities rather than
resources avoids some nasty recursive thinking ala the problems Lucas was
eluding to, but...  I'm flexible on that issue.

Jb







-----------------------------------------------------------------------------------
Post ID:1828
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-07-12 04:48:21
Subject:Re: [rest-discuss] socket-level mods
Message:

Allan Doyle wrote:
> I may be totally off base here, and would need to do some experiments,
> but given that HTTP runs over TCP, isn't it the case that a request
> sent to a server can be held by the server nearly indefinitely before
> it sends a reply? 

This strikes me as completely sensible.  It's interesting that it's also 
in the bag of socket-level modifications.  HTTP is exactly what it always 
was, but there are extensions happening underneath it in the transport 
layer.

(Aside to Mark: I think that Allan's comment is not about a set of
request/response pairs, but a single pair where the reply is sent in a
time frame _completely_ different from the browser timeframe.

Aside to Allan: correct me if I'm putting words in your mouth.)








-----------------------------------------------------------------------------------
Post ID:1829
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-12 04:06:05
Subject:Re: [rest-discuss] socket-level mods
Message:

On 7/11/02 7:48 PM, "S. Mike Dierken" <mdierken@...> wrote:

> 
> Yeah... I'd rather see the connection opened by the client & the roles
> reversed via a magic command - how about a new HTTP method of 'LISTEN'?
> 

Aaaargh!

Seriously:  GET, PUT, POST, DELETE are all *clearly* about the resource
named.  I.e., if they're the verbs, the named resources is the *direct
object*, not the *subject.*  What resource exactly does a "LISTEN" apply to?
And if you tell me it's a way to subscribe to events from the named
resource, how is that different from GET?  And if you tell me it's because
those events are asynchronously delivered, potentially to some other
resource named in the original request, how does that differ from i.e. The
HTTP Events proposal and similar / related proposals?

Jb








-----------------------------------------------------------------------------------
Post ID:1830
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-12 06:21:41
Subject:Re: [rest-discuss] Is REST CRUD?
Message:

fyi -
I just learned that MySQL has a 'REPLACE' SQL statement - which does a
conditional insert or update (upsert). This is equivalent to PUT in
HTTP-land. Oracle9i added 'MERGE' with funky conditional logic in the SQL
after that to do a similar thing.

Interesting that the same kind of primary data manipulation operations show
up elsewhere...








-----------------------------------------------------------------------------------
Post ID:1831
Sender:Chris Croome <chris@...>
Post Date/Time:2002-07-12 12:02:22
Subject:Architectural style or architectural principals?
Message:

Hi

I think describing REST as a 'architectural style' is questionable. I
think REST is more than just a style and could better be described as
'architectural principals'.

In architecture (the built environment) styles are essentially fads and
fashions, principals are more fundamental aspects of form and structure.

Some aspects of REST are accurately described as questions style, for
example the 'aesthetics of URI design' but to sum it up as a 'style' is
(speaking as someone from an architectural background) a mistake that
under plays it's importance.   

IMHO

Chris

-- 
Chris Croome                               <chris@...>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   
everything else                               http://chris.croome.net/  






-----------------------------------------------------------------------------------
Post ID:1832
Sender:Allan Doyle <adoyle@...>
Post Date/Time:2002-07-12 13:15:13
Subject:Re: [rest-discuss] socket-level mods
Message:

On Friday 2002-07-12 at 00:48:21(-0400) Lucas Gonze wrote:
 > 
 > Allan Doyle wrote:
 > > I may be totally off base here, and would need to do some experiments,
 > > but given that HTTP runs over TCP, isn't it the case that a request
 > > sent to a server can be held by the server nearly indefinitely before
 > > it sends a reply? 
 > 
 > This strikes me as completely sensible.  It's interesting that it's also 
 > in the bag of socket-level modifications.  HTTP is exactly what it always 
 > was, but there are extensions happening underneath it in the transport 
 > layer.
 > 
 > (Aside to Mark: I think that Allan's comment is not about a set of
 > request/response pairs, but a single pair where the reply is sent in a
 > time frame _completely_ different from the browser timeframe.
 > 
 > Aside to Allan: correct me if I'm putting words in your mouth.)

No, you got it right. The sequence is

  1. Client sends request "A"
  2. Server receives request "A"

  3. Client does other stuff, including sending more requests
  4. Server does other stuff, including servicing other requests

  5. Some time later, server has something to say to client
  6. Server sends what it has to say via response to "A"

The client did not have to poll. The server had to hang on to the
state. But in Marks request/202/poll to server also has to hang on to
the same state.

If the connection breaks, the client and server will each get an error
before step 5. The server should simply drop the state since there's
no way to recover w/o the client coming back. The client should go
back to step 1 if it still wants the channel open.

    Allan

(And it was CRONUS, not CORBUS, I had a brain cramp on that
one. CORBUS was a CORBA wrapper on CRONUS)
 > 
 > 
 > 
 > 
 > To unsubscribe from this group, send an email to:
 > rest-discuss-unsubscribe@yahoogroups.com
 > 
 >  
 > 
 > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
 > 
 > 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle                         http://www.intl-interfaces.com
adoyle@...







-----------------------------------------------------------------------------------
Post ID:1833
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-12 14:12:47
Subject:Re: [rest-discuss] Architectural style or architectural principals?
Message:

On Fri, Jul 12, 2002 at 01:02:22PM +0100, Chris Croome wrote:
> In architecture (the built environment) styles are essentially fads and
> fashions, principals are more fundamental aspects of form and structure.

An architectural style is an integrated set of architectural principles.
Roy talks about this in the context of patterns (principles) and pattern
languages (styles).

So REST, the style, encompasses such principles/patterns as "generic
interface", "stateless interactions", "hypermedia as engine of
application state", etc..

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1834
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-12 14:29:04
Subject:Re: [rest-discuss] socket-level mods
Message:

On Fri, Jul 12, 2002 at 09:15:13AM -0400, Allan Doyle wrote:
>   5. Some time later, server has something to say to client
>   6. Server sends what it has to say via response to "A"
> 
> The client did not have to poll. The server had to hang on to the
> state. But in Marks request/202/poll to server also has to hang on to
> the same state.

Ah, well historically, futures support both poll and notify modes.
I remember the Expersoft ORB from way-back-when whose Future interface
was like this;

interface Future
{
  getResponseAndBlock()
  registerCallback()
  checkForResponse()
}
  
The important feature of a Future was merely to represent the future
response, not restrict ways in which you'd expect to be able to use it.

The value of futures, in my experience, was just to simplify client
code as you didn't always have to worry about threading.  So I rarely
used them in the way you mentioned, since that required threads to be
managed.  I almost always just checked for a response.  So you could
imagine a REST based future interface that used a local proxy to manage
your "callback mailboxes", permitting a HEAD to one of those URIs to be
"checkForResponse", GET to be "getResponseAndBlock", and
"registerCallback" would be when your app code was tightly bound with
the mailbox through APIs.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1835
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-07-12 15:20:16
Subject:Re: [PMX:#] [rest-discuss] REST and HTTP
Message:

>> As for another example of a part of HTTP 1.1 I feel is not RESTful (in my
>> mind):  the If-Match, If-Modified-Since, If-None-Match, If-Range, and
>> If-Unmodified-Since header fields (14.24-28).  From my understanding of
>> these fields, the client is effectively telling the server how to act.

> I'm somewhat inclined to agree with some of this;  If-Mod* and If-Unmod*
are
> probably okay because they are describing what they  want in terms
> independent of some representation, but the rest presuppose some
particular
> representation.

I have to disagree with this.  Those headers are only cache control hints.
They specify ETag values that are compared against the ETag values that had
been supplied by the server to represent a version of whatever underlying
entity is referenced by the URL.  They aren't referencing any underlying
data in the reponse body (i.e., representation) itself, so the don't
presuppose any representation.

Also, the response may be handled by a caching proxy without ever hitting
the server itself.








-----------------------------------------------------------------------------------
Post ID:1836
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-12 16:07:44
Subject:Re: socket-level mods
Message:

Mark Baker wrote:
 
> Ah, well historically, futures support both poll and notify modes.
> I remember the Expersoft ORB from way-back-when whose Future 
interface
> was like this;
> 
> interface Future
> {
>   getResponseAndBlock()
>   registerCallback()
>   checkForResponse()
> }
>   
> The important feature of a Future was merely to represent the future
> response, not restrict ways in which you'd expect to be able to use 
it.
> 
> The value of futures, in my experience, was just to simplify client
> code as you didn't always have to worry about threading.  So I 
rarely
> used them in the way you mentioned, since that required threads to 
be
> managed.  I almost always just checked for a response.  

Would it also be possible to make a Web resource into something like 
a future?

The terms in this space are very overloaded, but call it a Commitment 
(in the speech act or REA sense, not in the database sense) or a 
Promise (related to but not quite the same as the E-Lang creature of 
the same name)?

The speech act or REA meaning of Commitment is a promise to perform 
an event in the future.  When the event occurs, it fulfills the 
promise (or doesn't, as the case may be.)  A Commitment can have a 
time constraint.

The implementation could be similar to Offer-Acceptance:  the 
Commitment has a URI to which the promisor POSTs the promised event.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1837
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-12 16:18:41
Subject:Re: [rest-discuss] Re: socket-level mods
Message:

On 7/12/02 11:07 AM, "bhaugen32" <bhaugen32@...> wrote:

> Would it also be possible to make a Web resource into something like
> a future?
> 
> The terms in this space are very overloaded, but call it a Commitment
> (in the speech act or REA sense, not in the database sense) or a
> Promise (related to but not quite the same as the E-Lang creature of
> the same name)?

Future and promise both have ample historical precedent.  However, the term
"thunk" probably has as much precedent in lazy evaluation languages like
e.g. SASL.  In these languages, a thunk (alt. "suspension") is a pairing of
a (possibly complex, nested) expression and an environment for which
evaluation is deferred until it is needed / forced.  Sort of a parameterless
closure.

Similar, and worth going back and digging around in the lazy eval lit...

Jb








-----------------------------------------------------------------------------------
Post ID:1838
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-12 17:20:22
Subject:Re: socket-level mods
Message:

Jeff Bone wrote:
> Future and promise both have ample historical precedent.  However, 
the term
> "thunk" probably has as much precedent in lazy evaluation languages 
like
> e.g. SASL.  In these languages, a thunk (alt. "suspension") is a 
pairing of
> a (possibly complex, nested) expression and an environment for which
> evaluation is deferred until it is needed / forced.  Sort of a 
parameterless
> closure.
> 
> Similar, and worth going back and digging around in the lazy eval 
lit...

Consider also Elephant:
http://www-formal.stanford.edu/jmc/elephant/node17.html







-----------------------------------------------------------------------------------
Post ID:1839
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-12 18:47:54
Subject:Re: [rest-discuss] Re: socket-level mods
Message:

On Fri, Jul 12, 2002 at 04:07:44PM -0000, bhaugen32 wrote:
> Would it also be possible to make a Web resource into something like 
> a future?

For sure.  I tried to describe that in my last (IIRC) message.

> The terms in this space are very overloaded, but call it a Commitment 
> (in the speech act or REA sense, not in the database sense) or a 
> Promise (related to but not quite the same as the E-Lang creature of 
> the same name)?
> 
> The speech act or REA meaning of Commitment is a promise to perform 
> an event in the future.  When the event occurs, it fulfills the 
> promise (or doesn't, as the case may be.)  A Commitment can have a 
> time constraint.
> 
> The implementation could be similar to Offer-Acceptance:  the 
> Commitment has a URI to which the promisor POSTs the promised event.

Yep, it would be really good for that.  We need some good APIs for
client web *server* integration, so that you can create these
mailboxes/futures/promises really easily.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1840
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-12 20:20:10
Subject:Re: socket-level mods
Message:

Mark Baker wrote:
> We need some good APIs for
> client web *server* integration, so that you can create these
> mailboxes/futures/promises really easily.

One thing Dave Winer gets right is that it's good to bootstrap these 
things.

I asked once before, and ask again, is there (preferably light, 
simple and free) environment that bunch of the correspondents here 
could agree to use for some code experiments?








-----------------------------------------------------------------------------------
Post ID:1841
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-07-13 02:52:05
Subject:Re: [rest-discuss] Re: socket-level mods
Message:

Bob Haugen said:
> I asked once before, and ask again, is there (preferably light, 
> simple and free) environment that bunch of the correspondents here 
> could agree to use for some code experiments?

I have found Tomcat pretty hackable, more than Libwww.  YMMV.

+1 on code experiments.

- Lucas










-----------------------------------------------------------------------------------
Post ID:1842
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-13 05:46:45
Subject:Re: [rest-discuss] socket-level mods
Message:

----- Original Message -----
From: "Allan Doyle" <adoyle@...>
To: <rest-discuss@yahoogroups.com>
Sent: Thursday, July 11, 2002 5:21 PM
Subject: Re: [rest-discuss] socket-level mods


> I may be totally off base here, and would need to do some experiments,
> but given that HTTP runs over TCP, isn't it the case that a request
> sent to a server can be held by the server nearly indefinitely before
> it sends a reply?
Yes.

>
> If so, then one thing I learned from rubbing elbows with the old
> CORBUS system at BBN is something called "futures". If a client makes
> a request to a server, and that server hangs onto the request while
> the client merrily goes on its way, then when the response eventually
> comes, the client can treat it as an asynchronous message from the
> server. If the server cleverly puts content into the reply, voila,
> your client can wake up and deal with it.
Yes - this is the 'KnowNow' approach mentioned by Lucas earlier. KnowNow has
an HTTP based message server that does exactly this.

>
> If the TCP connection breaks, or the HTTP server times out and shuts
> it down, the client would get a different signal/error. Then client
> could then decide whether to send another future request or do
> something else. In any case, you are buying time and leaving open a
> means for an async notification.
>
> This would move the problem up one level and you would not have to
> muck with HTTP. The only issue is whether the breakage level is too
> high, causing overconsumption of resources. Then you do have to work
> on some optimizations (potentially even rewriting HTTP).
>
There isn't any unsurmountable technical problem, the issue that several of
us want to deal with is that the response from the server will look to the
HTTP world like responses and not as requests. The communication between the
server and the client would be a 'private http' protocol - messages
initiated by the server appear as if they are merely a single response to a
previous request, and this isn't that big a deal for building apps. Longer
term there should be more visibility, but I'm all for testing it out and
documenting/'standardizing' the approach if it becomes popular.








-----------------------------------------------------------------------------------
Post ID:1843
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-07-13 17:34:52
Subject:REST and non-HTTP protocols
Message:

It's often been claimed that REST applies to all Web protocols, not just
HTTP. Is there a reference somewhere that maps GET/POST/PUT/DELETE into
all or most of the other URI (although I suspect just URL) schemes?

Cheers,


--
Mark Nottingham







-----------------------------------------------------------------------------------
Post ID:1844
Sender:"Peter Drayton" <peter@...>
Post Date/Time:2002-07-13 22:13:27
Subject:URI design question
Message:

I'm looking for references to reading material to help me design a good
set of URIs to represent a set of containers and subcontainers. Although
I realize that URIs are opaque, I'm trying to have them look reasonable
should people see them - the problem I'm having is how to differentiate
between "give me a representation of the container", and "give me a
represenation of everything inside the container", without having the
URIs seem very verbose.

Imagine a service that exposes a set of containers. Each container which
held interesting data, and one or more subcontainers. Each subcontainer
also held some interestesting data. I want to be able to support the
following use cases
o Get the list of containers in the service (UC1)
o Get the data in a container (UC2)
o Get a list of the subcontainers in a container (UC3)
o Get the data in a subcontainer (UC4)

One approach I've been consider is to model "Get the list of containers
in the service" as:
  UC1: GET http://hypothetical.com/service/containers
This would return a list of container URIs. These URIs could then be
used to "Get the data in a container", like this:
  UC2: GET  http://hypothetical.com/service/containers/1234
This would return the data in the container. One of the data items would
be a URI to "Get the list of subcontainers in a container", like this:
  UC3: GET http://hypothetical.com/service/containers/1234/subcontainers
This would return a list of subcontainer URIs. These URIs could then be
used to "Get the data in a subcontainer", like this:
  UC4: GET
http://hypothetical.com/service/containers/1234/subcontainers/5678

My concern is that this approach gets pretty verbose. Given that at each
level there is only one class of sub-item, I have considered making the
containers & subcontainers implicit. This results in a shorter set of
URLs than the above four, like this:
  UC1: GET http://hypothetical.com/service/
  UC2: GET http://hypothetical.com/service/1234
  UC3: GET http://hypothetical.com/service/1234/
  UC4: GET http://hypothetical.com/service/1234/5678

My concern is that the difference between the GETs for UC2 and UC3 seem
so trivial to be incorrect/confusing/plain wrong.

I'd appreciate any suggestions, comments, required reading or references
from the group. Thanks in advance.

--Peter







-----------------------------------------------------------------------------------
Post ID:1845
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-07-13 22:54:40
Subject:RE: [rest-discuss] URI design question
Message:

Peter Drayton wrote:
> I'm looking for references to reading material to help me design a good
> set of URIs to represent a set of containers and subcontainers. Although
> I realize that URIs are opaque, I'm trying to have them look reasonable
> should people see them - the problem I'm having is how to differentiate
> between "give me a representation of the container", and "give me a
> represenation of everything inside the container", without having the
> URIs seem very verbose.
> ...

I'm trying to understand what the difference between a container's
representation, and the container's representation of its subcontainers, is.  I
thought they would be the same thing.  But perhaps this approach doesn't fit
your situation well.  Or maybe the container resource should support both?

One thing I try to remember is that a URI could point to an entity that doesn't
physically exist.  In other words, upon receiving a GET request, the server
could determine that the URI is logical and maps (in some way only known to the
server) to a physical one.

So you might initially do a GET /foo, which returns a representation of the
server's physical container resource /foo that indicates the relative URI
'containers' would return a list of /foo sub-container representations.  Then,
you could do a GET /foo/containers and go from there.

-Philip










-----------------------------------------------------------------------------------
Post ID:1846
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-07-13 23:53:47
Subject:Re: [rest-discuss] URI design question
Message:

Peter,

If you're looking for some references, there's of course Berners-Lee's
"Universal Resource Identifiers -- Axioms of Web Architecture" [1] which as
a lot of good discussion and references to other articles, some specific to
hierarchies. Paul Prescod's short article "Creating an Extreme Web Service
in N Easy Steps" [2] might shed some light on this.  I found it interesting
anyway...

Personally, I think the way to go is similar to what you've already outlined
with a couple of changes:

The initial list of containers as you have (although I think the "service"
is implied so I dropped that):
UC1:    http://hypothetical.com/containers

The list of URIs in the returned document uses the singular "container", so
UC2:    http://hypothetical.com/container/1234

Could return the xml document with a URI to it's subcontainer as you have:
UC3:    http://hypothetical.com/container/1234/subcontainer

From there though, I don't see that you need to necessarily show the entire
hierarchy, i.e., dereferencing UC3 returns a list of URIs of the form:
UC4:    http://hypothetical.com/subcontainer/5678

... and so one down the tree.  Perhaps if your model was really a graph
(multiple parents) you might need to show the full chain but I haven't
really thought through the implications of that.

Creating a new subcontainer would be accomplished with, a POST to UC3, and
the new URI returned in the Location header of the HTTP 201 response.
Prescod also has some thoughts on doing this reliably [3].  Actually, just
go ahead and read all his stuff [4].

As for making the containers and subcontainers implicit in the URI, unless
your underlying data model is trivial, you would need something to key on in
order to reasonably obtain the entity's representation.  For example,
suppose instead of container/subcontainer you had book/chapters and
book/authors (two subcontainers); if you only had /service/1234/5678, how
would you know if "5678" referred to a chapter or an author?  What table
would you look in if this happened to be sitting on top of a relational
database?

You'd be better off using:
UC5:    http://hypothetical.com/book/1234/chapter/5678

or better yet:
UC6:    http://hypothetical.com/chapter/5678

I find this an interesting subject, and if I'm off base anywhere I'd like to
hear about it!

Thanks,

- Jeff

[1] http://www.w3.org/DesignIssues/Axioms.html
[2] http://www.prescod.net/rest/Steps_to_extreme.html
[3] http://www.prescod.net/reliable_http.html
[4] http://www.prescod.net/rest/

----- Original Message -----
From: "Peter Drayton" <peter@...>
To: <rest-discuss@yahoogroups.com>
Sent: Saturday, July 13, 2002 6:13 PM
Subject: [rest-discuss] URI design question


> I'm looking for references to reading material to help me design a good
> set of URIs to represent a set of containers and subcontainers. Although
> I realize that URIs are opaque, I'm trying to have them look reasonable
> should people see them - the problem I'm having is how to differentiate
> between "give me a representation of the container", and "give me a
> represenation of everything inside the container", without having the
> URIs seem very verbose.
>
> Imagine a service that exposes a set of containers. Each container which
> held interesting data, and one or more subcontainers. Each subcontainer
> also held some interestesting data. I want to be able to support the
> following use cases
> o Get the list of containers in the service (UC1)
> o Get the data in a container (UC2)
> o Get a list of the subcontainers in a container (UC3)
> o Get the data in a subcontainer (UC4)
>
> One approach I've been consider is to model "Get the list of containers
> in the service" as:
>   UC1: GET http://hypothetical.com/service/containers
> This would return a list of container URIs. These URIs could then be
> used to "Get the data in a container", like this:
>   UC2: GET  http://hypothetical.com/service/containers/1234
> This would return the data in the container. One of the data items would
> be a URI to "Get the list of subcontainers in a container", like this:
>   UC3: GET http://hypothetical.com/service/containers/1234/subcontainers
> This would return a list of subcontainer URIs. These URIs could then be
> used to "Get the data in a subcontainer", like this:
>   UC4: GET
> http://hypothetical.com/service/containers/1234/subcontainers/5678
>
> My concern is that this approach gets pretty verbose. Given that at each
> level there is only one class of sub-item, I have considered making the
> containers & subcontainers implicit. This results in a shorter set of
> URLs than the above four, like this:
>   UC1: GET http://hypothetical.com/service/
>   UC2: GET http://hypothetical.com/service/1234
>   UC3: GET http://hypothetical.com/service/1234/
>   UC4: GET http://hypothetical.com/service/1234/5678
>
> My concern is that the difference between the GETs for UC2 and UC3 seem
> so trivial to be incorrect/confusing/plain wrong.
>
> I'd appreciate any suggestions, comments, required reading or references
> from the group. Thanks in advance.
>
> --Peter
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:1847
Sender:"Peter Drayton" <peter@...>
Post Date/Time:2002-07-14 01:38:33
Subject:RE: [rest-discuss] URI design question
Message:

Philip Eskelin wrote:
>
> Peter Drayton wrote:
> > I'm looking for references to reading material to help me design 
> > a good set of URIs to represent a set of containers and 
> > subcontainers. Although I realize that URIs are opaque, I'm 
> > trying to have them look reasonable should people see them - 
> > the problem I'm having is how to differentiate between "give me 
> > a representation of the container", and "give me a represenation 
> > of everything inside the container", without having the URIs 
> > seem very verbose.
> 
> I'm trying to understand what the difference between a container's
> representation, and the container's representation of its 
> subcontainers, is.  I
> thought they would be the same thing.  But perhaps this 
> approach doesn't fit
> your situation well.  Or maybe the container resource should 
> support both?

I'm actually working on a couple of different cases of this. One of them
is where I have accounts (which have account data) that contain 0..n
identities (which have identity data). Another is where I have test
suites (with associated data) that have sets of client results (with
result data) and server implementations (with endpoint information).

The latter example doesn't fit my post 100%, since the container has 2
different classes of subcontainers. In this case I need to retain the
subcontainerX/ in the URI, to distinguish which subcontainer I'm going
for.

The former, OTOH, fits quite well. Should my URIs be ( removed for
brevity):

UC1: GET http://hypothetical.com/service/accounts
UC2: GET http://hypothetical.com/service/accounts/1234
UC3: GET http://hypothetical.com/service/accounts/1234/identities
UC4: GET http://hypothetical.com/service/accounts/1234/identities/5678

or 

UC1: GET http://hypothetical.com/service/ 
UC2: GET http://hypothetical.com/service/1234
UC3: GET http://hypothetical.com/service/1234/
UC4: GET http://hypothetical.com/service/1234/5678

Obviously, only works if the tree has only one subcontainer at each
level.

> One thing I try to remember is that a URI could point to an 
> entity that doesn't physically exist.  In other words, upon 
> receiving a GET request, the server could determine that the 
> URI is logical and maps (in some way only known to the 
> server) to a physical one.
> 
> So you might initially do a GET /foo, which returns a 
> representation of the
> server's physical container resource /foo that indicates the 
> relative URI
> 'containers' would return a list of /foo sub-container 
> representations.  Then,
> you could do a GET /foo/containers and go from there.

Understood, in my current design to get the data in a container (UC2) I
do a GET http://hypothetical.com/service/container/1234/ which returns
this:
<Container xmlns="http://hypothetical.com/example"
xmlns:x="http://www.w3.org/1999/xlink">
  <ContainerData1>...</ContainerData1>
  ...
  <ContainerDataN>...</ContainerDataN>
  <Subcontainers x:href="subcontainers/"/>
</Container>

Chasing the Subcontainers link to get the list of subcontainers in a
container (UC3), I do a GET
http://hypothetical.com/service/container/1234/subcontainers/ which
return this:
<?xml version="1.0"?>
<Subcontainers xmlns="http://hypothetical.com/example"
xmlns:x="http://www.w3.org/1999/xlink">
  <Subcontainer x:href="1234/"/>
  <Subcontainer x:href="5678/"/>
</Container>

Then going after subcontainer 5678 to get the data in the subcontainer
(UC4), I do a GET on
http://hypothetical.com/service/container/1234/subcontainers/5678/,
which returns this:
<Subcontainer xmlns="http://hypothetical.com/example"
xmlns:x="http://www.w3.org/1999/xlink">
  <SubcontainerData1>...</SubcontainerData1>
  ...
  <SubcontainerDataN>...</SubcontainerDataN>
</Container>

My concern was that these URIs get long, especially when you have
several level of this pattern repeating itself.

--Peter
http://www.razorsoft.net/weblog







-----------------------------------------------------------------------------------
Post ID:1848
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-14 02:05:55
Subject:Re: [rest-discuss] URI design question
Message:

At 08:13 AM 14/07/2002, Peter Drayton wrote:
>I'm looking for references to reading material to help me design a good
>set of URIs to represent a set of containers and subcontainers. Although
>I realize that URIs are opaque, I'm trying to have them look reasonable
>should people see them - the problem I'm having is how to differentiate
>between "give me a representation of the container", and "give me a
>represenation of everything inside the container", without having the
>URIs seem very verbose.

You might find 'Resource Modeling and Names' 
(http://internet.conveyor.com/RESTwiki/moin.cgi/ResourceModelingAndNames) 
of use, particularly the use of a grammar to model a hierarchical 
collection of resources.

Also :

'Opacity Myths Debunked' 
(http://internet.conveyor.com/RESTwiki/moin.cgi/OpacityMythsDebunked)
'Opacity Reconsidered' 
(http://internet.conveyor.com/RESTwiki/moin.cgi/OpacityReconsidered)
'Opacity Reconsidered Reconsidered' 
(http://internet.conveyor.com/RESTwiki/moin.cgi/OpacityReconsideredReconsidered)
'Naming Isn't Navigating' 
(http://internet.conveyor.com/RESTwiki/moin.cgi/NamingIsntNavigating)

Mark Bakers'  'An Investigation into the Opacity Properties of RFC 2396' 
(http://www.markbaker.ca/2002/01/UriOpacityInvestigation/)

and of course the definitive source on REST, Fieldings' dissertation, in 
particular Section 6.2 'REST Applied to URI' 
(http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2).

The forces at play here appear to be :

Opacity - the URI should be opaque to all but the implementor
Identity - a URI is by definition an identifier of a resource and that 
identity should be useful as an indicator of the semantics of the resource
Maintainability - the URI set should be maintainable by the implementor
Reliability - the URI set should remain as unchanged as possible for as 
long as possible

and (somewhat dubiously)
Discovery - it may be useful for clients (both human and machine) to 
utilize the nature and relationship between URIs' to discover other resources

Depending on your situation one or more of these forces might influence the 
end result more than the others. In general it seems best practice not to 
reflect your resource *model* (i.e. relationships) directly in the URI and 
as Paul says in 'Common REST mistakes' 
(http://www.prescod.net/rest/mistakes/) "In other words, your public API 
should not depend on the structure of your URIs. Instead there would 
typically be a single XML file that points to the components of your 
service. Those components would have hyperlinks that point to other 
components and so forth. Then you can introduce people to your service with 
a single URI and you can distribute the actual components across computers 
and domains however you want."

HTH

Robert







-----------------------------------------------------------------------------------
Post ID:1849
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-14 03:10:20
Subject:Re: [rest-discuss] REST and non-HTTP protocols
Message:

Mark Nottingham wrote:
> 
> It's often been claimed that REST applies to all Web protocols, not just
> HTTP. Is there a reference somewhere that maps GET/POST/PUT/DELETE into
> all or most of the other URI (although I suspect just URL) schemes?

Here is my interpretation of the claims that have been made: the REST
model is appropriate to solving all of the same problems that other
Internet application protocols solve. In other words email (for example)
could benefit from REST discipline and could use HTTP across the wire.
If that's what you're asking about then here's one preliminary mapping
I've done for email:

 * http://www.prescod.net/rest/restmail/

I would not say that "REST applies to all Web protocols." For one thing,
I don't have a clear definition of "Web protocol." Arguably HTTP is the
only widely deployed protocol that knows about "the Web" and has been
adopted by the W3C as a core technology. (One could argue that SOAP fits
too and it would probably be simpler to agree to disagree rather than
attempt to establish a test of Web-ness)

I certainly do not think of SMTP as either guided by REST or based upon
the Web.

"For example, the Web's primary transfer protocol is HTTP, but the
architecture also includes seamless access to resources that originate
on pre-existing network servers, including FTP [107], Gopher [7], and
WAIS [36]. Interaction with those services is restricted to the
semantics of a REST connector. This constraint sacrifices some of the
advantages of other architectures, such as the stateful interaction of a
relevance feedback protocol like WAIS, in order to retain the advantages
of a single, generic interface for connector semantics."

"If an application needs the additional capabilities of another
architecture, it can implement and invoke those capabilities as a
separate system running in parallel, similar to how the Web architecture
interfaces with "telnet" and "mailto" resources."

 *
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1850
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-14 03:20:13
Subject:Re: [rest-discuss] URI design question
Message:

Peter Drayton wrote:
> 
> I'm looking for references to reading material to help me design a good
> set of URIs to represent a set of containers and subcontainers. Although
> I realize that URIs are opaque, I'm trying to have them look reasonable
> should people see them - the problem I'm having is how to differentiate
> between "give me a representation of the container", and "give me a
> represenation of everything inside the container", without having the
> URIs seem very verbose.

Well GET should certainly be used for "representation of the container."
The other thing could either be an "associated URI" or a query (which is
just an associated URI that is "extensible" by the client).

> One approach I've been consider is to model "Get the list of containers
> in the service" as:
>   UC1: GET http://hypothetical.com/service/containers

Great.

> This would return a list of container URIs. These URIs could then be
> used to "Get the data in a container", like this:
>   UC2: GET  http://hypothetical.com/service/containers/1234

Great.

> This would return the data in the container. One of the data items would
> be a URI to "Get the list of subcontainers in a container", like this:
>   UC3: GET http://hypothetical.com/service/containers/1234/subcontainers

Is there any deep reason not to combine the information here with the
information above?

> This would return a list of subcontainer URIs. These URIs could then be
> used to "Get the data in a subcontainer", like this:
>   UC4: GET
> http://hypothetical.com/service/containers/1234/subcontainers/5678

Great. But I would suggest that this one would be just as good:

http://hypothetical.com/service/containers/1234/5678

5678 is logically a child of /1234, not of its "subcontainer index." And
it solves your verbosity problem.

> My concern is that this approach gets pretty verbose. Given that at each
> level there is only one class of sub-item, I have considered making the
> containers & subcontainers implicit. This results in a shorter set of
> URLs than the above four, like this:
>   UC1: GET http://hypothetical.com/service/
>   UC2: GET http://hypothetical.com/service/1234
>   UC3: GET http://hypothetical.com/service/1234/

It's only UC2 and UC3 that I dislike. Change UC3 to /1234/subcontainers
and I think you are set. 

>   UC4: GET http://hypothetical.com/service/1234/5678
> 
> My concern is that the difference between the GETs for UC2 and UC3 seem
> so trivial to be incorrect/confusing/plain wrong.
> 
> I'd appreciate any suggestions, comments, required reading or references
> from the group. Thanks in advance.

Think of "subcontainers" as "index.html". It's just an index and doesn't
need to have children of its own. Or it could be merged with the "other
content" for the resource so that one GET gives you everything.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1851
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-14 04:24:06
Subject:Re: [PMX:#] [rest-discuss] REST and HTTP
Message:

----- Original Message -----
From: "Jeffrey Winter" <j.winter@...>


> >> As for another example of a part of HTTP 1.1 I feel is not RESTful (in
my
> >> mind):  the If-Match, If-Modified-Since, If-None-Match, If-Range, and
> >> If-Unmodified-Since header fields (14.24-28).  From my understanding of
> >> these fields, the client is effectively telling the server how to act.
>
> > I'm somewhat inclined to agree with some of this;  If-Mod* and If-Unmod*
> are
> > probably okay because they are describing what they  want in terms
> > independent of some representation, but the rest presuppose some
> particular
> > representation.
>
> I have to disagree with this.  Those headers are only cache control hints.
> They specify ETag values that are compared against the ETag values that
had
> been supplied by the server to represent a version of whatever underlying
> entity is referenced by the URL.  They aren't referencing any underlying
> data in the reponse body (i.e., representation) itself, so the don't
> presuppose any representation.
>

I also disagree - the ETag based headers seem to be defined on resources,
not representations.






-----------------------------------------------------------------------------------
Post ID:1852
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-14 04:49:47
Subject:Is EDI SOAP?
Message:

We were discussing recently how it has become popular to describe XML
vocabularies in terms of the infoset instead of the XML syntax. That got
me to thinking: SOAP does not specify any message-exchange patterns. It
mandate extremely "loose" semantics. So you're allowed arbitrary syntax
and arbitrary semantics: what sort of protocol does not conform to the
SOAP model?
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1853
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-14 05:00:58
Subject:Implementing RESTful Queue with HTTP
Message:

I've been thinking about how to implement a Queue with HTTP. I'm not
interested in uber-efficiency, just the  requirement of one and only one
consumer of a message.

I've got two approaches to model the queue - a visible (i.e. list-able)
collection of messages and as a 'head' or 'next' message. I'm not sure the
'head' approach will work.

a) Visible collection
A client lists the messages and tries to process them one at a time. Tricky
clients can use some sort of hashing algorithm to avoid collisions with
other clients, but I'm not concerned with that. But how do the clients
actually 'take' a message?

1 New method - TAKE
Somebody mentioned a while back a tuple-space system that had a 'take'
operation - which sounds about what is needed for a queue.  But I don't like
this approach.

2 lock a message with PUT
The listing of pending messages includes a URI for each message and a URI
for a 'lock' for a message. The client does a conditional PUT that succeeds
only if the lock resource doesn't already exist (something like
if-none-match: * or maybe if-not-modified-since)

3 remove message from queue with DELETE
The listing provides URIs which represent /links/ to messages which have
URIs independent of being part of a queue. The client removed the message
from the queue by doing a DELETE on the URI for the 'message in outbox'
resource. It then is free to get the message (as is anybody else, like for
audits, referencing, etc.).

4 others...
Any others?

It's interesting that #2 and #3 use two URIs for each message, but different
methods. I guess the difference is #2 says "PUT the status of 'not in
queue'" and #3 says "DELETE from queue". I think I llike #2 better since it
depends on the value of a resource, rather than the existence of a resource.








-----------------------------------------------------------------------------------
Post ID:1854
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-14 18:38:11
Subject:Re: Is EDI SOAP?
Message:

Paul Prescod wrote:
> what sort of protocol does not conform to the
> SOAP model?

You mentioned EDI in the subject line.
Did you mean to suggest that EDI does not conform to the SOAP model?

"EDI" means lots of things to lots of people.

If you mean traditional EDI - ANSI X12 and EDIFACT - then:
1. The documents exchanged are not XML, but people have converted the 
EDI formats to XML, without much takeup.
2. The most common message exchange pattern for traditional EDI is 
batch over a VAN, that is, possible very large batches of documents 
being sent periodically, often weekly.  Not very SOAPy.  Or RESTful, 
either.
3. Some people are gravitating to a conversational-style EDI, still 
using the old document formats.  
4. If you consider RosettaNet and ebXML to be the "next generation of 
EDI" (I do), then RNet is a lot like "message-oriented" SOAP, and 
ebXML is exactly SOAP with a lot of business extensions for state-
alighnment transactions, security, etc.  ebXML allows people to use 
traditional EDI document formats with SOAP "transport".

Does that speak to your combination of subject line and question at 
all?

It has been my contention on this list that ebXML state-alignment 
transactions would actually work better with REST than SOAP, but that 
seems like a different topic.

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:1855
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-14 21:29:10
Subject:Re: Implementing RESTful Queue with HTTP
Message:

----- Original Message -----
From: "JulianReschke" <julian.reschke@...>
>
> Maybe this is too obvious...
>
> How about using LOCK (RFC2518) to lock the message?

I hadn't thought of that... I'm not too sure I want to bring in all the DAV
stuff though. Using LOCK would be the more standards-compliant approach
though.






-----------------------------------------------------------------------------------
Post ID:1856
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-07-14 23:23:23
Subject:RE: [rest-discuss] Implementing RESTful Queue with HTTP
Message:

Mike Dierken wrote:
> I've been thinking about how to implement a Queue with HTTP. I'm not
> interested in uber-efficiency, just the  requirement of one and only one
> consumer of a message.
>
> I've got two approaches to model the queue - a visible (i.e. list-able)
> collection of messages and as a 'head' or 'next' message. I'm not sure the
> 'head' approach will work.

Actually, this is a good problem to explore, because I it gives me a strong urge
to model the solution with verbs.  It's most certainly not a good idea to
transfer a representation of the entire queue, modify it, and transfer it back.
There must be a protocol for queue interaction that is RESTful.  How about this
approach:

1. A 'POST /myqueue' to enqueue a message representation.  The entity
   is treated as a subordinate to the '/myqueue' queue resource.
2. A 'DELETE /myqueue/head' to dequeue a representation of the first
   message in the queue.  The entity returned is a representation
   of the removed message.
3. A 'GET /myqueue' transfers a representation of the queue
   resource.  This would have a list of URIs identifying each
   message in the queue.
4. A 'GET /myqueue/messages/123' transfers a represenation of a
   message resource.

There doesn't seem to be any need for locking.  Is this consistent with what you
would need, or am I missing an issue or requirement that might make this
approach invalid?

-Philip









-----------------------------------------------------------------------------------
Post ID:1857
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-14 23:58:34
Subject:RE: [rest-discuss] Implementing RESTful Queue with HTTP
Message:

At 09:23 AM 15/07/2002, Philip Eskelin wrote:
>Mike Dierken wrote:
> > I've been thinking about how to implement a Queue with HTTP. I'm not
> > interested in uber-efficiency, just the  requirement of one and only one
> > consumer of a message.
> >
> > I've got two approaches to model the queue - a visible (i.e. list-able)
> > collection of messages and as a 'head' or 'next' message. I'm not sure the
> > 'head' approach will work.
>
>Actually, this is a good problem to explore, because I it gives me a 
>strong urge
>to model the solution with verbs.  It's most certainly not a good idea to
>transfer a representation of the entire queue, modify it, and transfer it 
>back.
>There must be a protocol for queue interaction that is RESTful.  How about 
>this
>approach:
>
>1. A 'POST /myqueue' to enqueue a message representation.  The entity
>    is treated as a subordinate to the '/myqueue' queue resource.
>2. A 'DELETE /myqueue/head' to dequeue a representation of the first
>    message in the queue.  The entity returned is a representation
>    of the removed message.

The only problem with this is that DELETE is supposed to be idempotent . -
from RFC2612 "in that (aside from error or expiration issues) the
side-effects of N > 0 identical requests is the same as for a single request"
and "Methods can also have the property of "idempotence" in that (aside from
error or expiration issues) the side-effects of N > 0 identical requests is
the same as for a single request. The methods GET, HEAD,PUT and DELETE share
this property."

I think I am leaning towards Mike's original suggestion - 3 remove message
from queue with DELETE.


Robert







-----------------------------------------------------------------------------------
Post ID:1858
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-07-15 00:44:32
Subject:Re: [rest-discuss] REST and non-HTTP protocols
Message:

I asked because of Mark's claims [1]. Granted, he only claims GET is
universal, not other RESTful methods.

1. http://lists.w3.org/Archives/Public/www-tag/2002Jul/0136.html


----- Original Message -----
From: "Paul Prescod" <paul@...>
To: "Mark Nottingham" <mnot@...>; <rest-discuss@yahoogroups.com>
Sent: Saturday, July 13, 2002 8:10 PM
Subject: Re: [rest-discuss] REST and non-HTTP protocols


> Mark Nottingham wrote:
> >
> > It's often been claimed that REST applies to all Web protocols, not
just
> > HTTP. Is there a reference somewhere that maps GET/POST/PUT/DELETE
into
> > all or most of the other URI (although I suspect just URL) schemes?
>
> Here is my interpretation of the claims that have been made: the REST
> model is appropriate to solving all of the same problems that other
> Internet application protocols solve. In other words email (for example)
> could benefit from REST discipline and could use HTTP across the wire.
> If that's what you're asking about then here's one preliminary mapping
> I've done for email:
>
>  * http://www.prescod.net/rest/restmail/
>
> I would not say that "REST applies to all Web protocols." For one thing,
> I don't have a clear definition of "Web protocol." Arguably HTTP is the
> only widely deployed protocol that knows about "the Web" and has been
> adopted by the W3C as a core technology. (One could argue that SOAP fits
> too and it would probably be simpler to agree to disagree rather than
> attempt to establish a test of Web-ness)
>
> I certainly do not think of SMTP as either guided by REST or based upon
> the Web.
>
> "For example, the Web's primary transfer protocol is HTTP, but the
> architecture also includes seamless access to resources that originate
> on pre-existing network servers, including FTP [107], Gopher [7], and
> WAIS [36]. Interaction with those services is restricted to the
> semantics of a REST connector. This constraint sacrifices some of the
> advantages of other architectures, such as the stateful interaction of a
> relevance feedback protocol like WAIS, in order to retain the advantages
> of a single, generic interface for connector semantics."
>
> "If an application needs the additional capabilities of another
> architecture, it can implement and invoke those capabilities as a
> separate system running in parallel, similar to how the Web architecture
> interfaces with "telnet" and "mailto" resources."
>
>  *
> http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
> --
> Come discuss XML and REST web services at:
>   Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
>   Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/
>







-----------------------------------------------------------------------------------
Post ID:1859
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-15 01:29:32
Subject:Re: [rest-discuss] Is EDI SOAP?
Message:

On Sat, Jul 13, 2002 at 09:49:47PM -0700, Paul Prescod wrote:
> We were discussing recently how it has become popular to describe XML
> vocabularies in terms of the infoset instead of the XML syntax. That got
> me to thinking: SOAP does not specify any message-exchange patterns. It
> mandate extremely "loose" semantics. So you're allowed arbitrary syntax
> and arbitrary semantics: what sort of protocol does not conform to the
> SOAP model?

Telnet's my canonical example.  Sure, you could wrap "a" in a SOAP
envelope, but the increased latency in transmitting and processing it
would make it suck.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1860
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-07-15 01:17:21
Subject:RE: [rest-discuss] Implementing RESTful Queue with HTTP
Message:

Robert wrote:
> I think I am leaning towards Mike's original suggestion - 3 remove
> message from queue with DELETE.

I'm not sure I totally understood Mike's description.  I read the DELETE
description in RFC 2616, and I did see that the returned entity should be a
description of the results, but didn't really acknowledge that it needed to be
idempotent.  Very good point.

But what did Mike mean by "doing a DELETE on the URI for the 'message in outbox'
resource"?  It doesn't sound idempotent the way I read it.

-Philip









-----------------------------------------------------------------------------------
Post ID:1861
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-15 01:40:56
Subject:Re: [rest-discuss] REST and non-HTTP protocols
Message:

On Sun, Jul 14, 2002 at 05:44:32PM -0700, Mark Nottingham wrote:
> I asked because of Mark's claims [1]. Granted, he only claims GET is
> universal, not other RESTful methods.

All HTTP methods are "universal" (in that they apply to all
resources).  I was just responding to Joshua's statement that GET was
only relevant for http scheme URIs.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1862
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-15 05:30:36
Subject:RE: [rest-discuss] Implementing RESTful Queue with HTTP
Message:

At 11:17 AM 15/07/2002, Philip Eskelin wrote:
>Robert wrote:
> > I think I am leaning towards Mike's original suggestion - 3 remove
> > message from queue with DELETE.
>
>But what did Mike mean by "doing a DELETE on the URI for the 'message in 
>outbox'
>resource"?  It doesn't sound idempotent the way I read it.

The reference to outbox made me think of Pauls description of the REST
implementation of email (http://www.prescod.net/rest/restmail/), so I'm
assuming something like the following:

  A 'GET /myqueue' transfers a representation of the queue resource.  This
would have a list of URIs identifying each queue entry e.g.

<queue>
    <queue_entry href='/myqueue/1'/>
    <queue_entry href='/myqueue/2'/>
     ...
    <queue_entry href='/myqueue/n'/>
</queue>

A GET on a queue entry ('myqueue/2') returns reference to a queue entry, the
contents of which would depend on how restrictive the queue needs to be,
e.g. if it is ok for others to discover the end message then it would return
something like:

<queue_entry message_href='/uri/to/real/message'/>

but if you want one and only one consumer to discover the message it might
return an empty entry and only return the message URI on a successful DELETE.

A DELETE on a queue entry does the obvious and removes the message from the
queue, returning the queue entry or message URI as a description of the
result, unless of  course someone else has pulled the entry from the queue,
in which case it returns the appropriate status code (404?)

Robert







-----------------------------------------------------------------------------------
Post ID:1863
Sender:"Philip Eskelin" <philip@...>
Post Date/Time:2002-07-15 05:56:02
Subject:RE: [rest-discuss] Implementing RESTful Queue with HTTP
Message:

Robert,

I understand now - thanks for clarifying.  Maybe I should have read Paul's
restmail page more closely.  One of the things I need to finish in my toolkit is
a queue implementation, so I'll make sure I build it to this specification.

-Philip

Robert wrote:
> At 11:17 AM 15/07/2002, Philip Eskelin wrote:
> >Robert wrote:
> > > I think I am leaning towards Mike's original suggestion - 3 remove
> > > message from queue with DELETE.
> >
> >But what did Mike mean by "doing a DELETE on the URI for the
> 'message in
> >outbox'
> >resource"?  It doesn't sound idempotent the way I read it.
>
> The reference to outbox made me think of Pauls description of the REST
> implementation of email
> (http://www.prescod.net/rest/restmail/), so I'm
> assuming something like the following:
>
>   A 'GET /myqueue' transfers a representation of the queue
> resource.  This
> would have a list of URIs identifying each queue entry e.g.
>
> <queue>
>     <queue_entry href='/myqueue/1'/>
>     <queue_entry href='/myqueue/2'/>
>      ...
>     <queue_entry href='/myqueue/n'/>
> </queue>
>
> A GET on a queue entry ('myqueue/2') returns reference to a
> queue entry, the
> contents of which would depend on how restrictive the queue
> needs to be,
> e.g. if it is ok for others to discover the end message then
> it would return
> something like:
>
> <queue_entry message_href='/uri/to/real/message'/>
>
> but if you want one and only one consumer to discover the
> message it might
> return an empty entry and only return the message URI on a
> successful DELETE.
>
> A DELETE on a queue entry does the obvious and removes the
> message from the
> queue, returning the queue entry or message URI as a
> description of the
> result, unless of  course someone else has pulled the entry
> from the queue,
> in which case it returns the appropriate status code (404?)
>
> Robert
>
>









-----------------------------------------------------------------------------------
Post ID:1864
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-15 06:06:06
Subject:Re: [rest-discuss] REST and non-HTTP protocols
Message:

Mark Nottingham wrote:
> 
> I asked because of Mark's claims [1]. Granted, he only claims GET is
> universal, not other RESTful methods.
> 
> 1. http://lists.w3.org/Archives/Public/www-tag/2002Jul/0136.html

Mark wasn't saying that REST methods apply to all protocols. He was
saying they apply to all URIs. i.e.

GET mailto:paul@... HTTP/1.1

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1865
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-15 06:09:27
Subject:Re: [rest-discuss] Implementing RESTful Queue with HTTP
Message:

"S. Mike Dierken" wrote:
>...
> 2 lock a message with PUT
> The listing of pending messages includes a URI for each message and a URI
> for a 'lock' for a message. The client does a conditional PUT that succeeds
> only if the lock resource doesn't already exist (something like
> if-none-match: * or maybe if-not-modified-since)

That's my favorite. Perhaps combined with WebDAV LOCK.

> 3 remove message from queue with DELETE
> The listing provides URIs which represent /links/ to messages which have
> URIs independent of being part of a queue. The client removed the message
> from the queue by doing a DELETE on the URI for the 'message in outbox'
> resource. It then is free to get the message (as is anybody else, like for
> audits, referencing, etc.).

I don't think this is safe. Two clients could DELETE at the same time
and both of the return messages could be lost. Then nobody knows who is
responsible for dealing with that message. A conditional PUT or POST
allows clients to "mark" the message (e.g. with a UUID or signature) to
say: "I'm in charge of this." Then they can deal with it at their
leisure. The conditionality can allow the server to ensure that there is
no race condition.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1866
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-15 06:04:32
Subject:RE: [rest-discuss] Implementing RESTful Queue with HTTP
Message:

At 03:56 PM 15/07/2002, Philip Eskelin wrote:

>One of the things I need to finish in my toolkit is
>a queue implementation, so I'll make sure I build it to this specification.

Well, you might want to wait until a REST guru gives it the ok, I am still 
a neophyte :-)

Robert








-----------------------------------------------------------------------------------
Post ID:1867
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-15 06:14:11
Subject:Re: [rest-discuss] Re: Is EDI SOAP?
Message:

bhaugen32 wrote:
> 
> Paul Prescod wrote:
> > what sort of protocol does not conform to the
> > SOAP model?
> 
> You mentioned EDI in the subject line.
> Did you mean to suggest that EDI does not conform to the SOAP model?

The opposite. I mean to point out that SOAP makes no syntactic demands
on protocols and almost no semantic ones. I believe that SOAP is
sufficiently "flexible" that ANSI X12 are *already legal SOAP messages*.
This is in contrast to REST which is much more prescriptive.

>....
> 1. The documents exchanged are not XML, but people have converted the
> EDI formats to XML, without much takeup.

Sure, but SOAP messages do not have to be XML, according to the SOAP
specification.

> 2. The most common message exchange pattern for traditional EDI is
> batch over a VAN, that is, possible very large batches of documents
> being sent periodically, often weekly.  Not very SOAPy.  Or RESTful,
> either.

But SOAP explicitly supports any message exchange pattern.

Does that clarify the question? I'm asking if SOAP is *so* flexibly
descriptive (rather than prescriptive) that any arbitrary pre-existing
protocol can be declared "SOAP compliant" without any change. Probably
few people would be silly enough to do this (but who can see the future)
but even if not, it seems to me to exemplify the opposite attidudes of
the REST literature versus the SOAP model. REST expresses constraints on
components and messages. SOAP seems designed to express as few
constraints as possible.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1868
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-16 03:47:24
Subject:Re: [rest-discuss] Implementing RESTful Queue with HTTP
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

>
> > 3 remove message from queue with DELETE
> > The listing provides URIs which represent /links/ to messages which have
> > URIs independent of being part of a queue. The client removed the
message
> > from the queue by doing a DELETE on the URI for the 'message in outbox'
> > resource. It then is free to get the message (as is anybody else, like
for
> > audits, referencing, etc.).
>
> I don't think this is safe. Two clients could DELETE at the same time
> and both of the return messages could be lost. Then nobody knows who is
> responsible for dealing with that message.
Very good point. I'd forgotten to consider lost responses.

> A conditional PUT or POST
> allows clients to "mark" the message (e.g. with a UUID or signature) to
> say: "I'm in charge of this." Then they can deal with it at their
> leisure.
The return message from a PUT can be lost just as much as a return message
from a DELETE .
But I do like the PUT, since client information can be saved by the server,
and so a lost response isn't that critical - a client will eventually
re-discover the state of the queue and notice that /it/ is responsible for a
message - even though it never got the response.

But this means clients need to know their IDs & it better be 'globally
unique' for some degree of 'global'.

Perhaps the server can hand out tokens to any client that asks for a message
and the first client that successfully puts one of them back wins. Each time
a client does a GET on the 'message-in-queue' resource a new token is
generated (i know i know 'non-idempotent get', blah blah blah, i can't hear
you....). The client saves that and confirms back to the server - it then
has either a success response, fail response, or null response. It processes
the message if a success response, drops the message on a fail response and
re-tries later on the null response.
This approach has the server control the id's and the clients don't need
id's.

> The conditionality can allow the server to ensure that there is
> no race condition.
I don't think the DELETE would cause a race condition any more than a
conditional PUT, the origin server would be responsible for ensuring only
one request is successful in either case.








-----------------------------------------------------------------------------------
Post ID:1869
Sender:richardmcguire@...
Post Date/Time:2002-07-16 12:45:16
Subject:How would like to have have customers knocking at your door? - Time:12:45:16 PM
Message:

Untitled Document We obtained your email address from a list of individuals who may have an interest in learning new ways to beat the competition in their businesses or professions. If you would like a free preview of a trend setting new book, or learn how you can obtain tele-coaching to build and/or enhance your “personal brand”, become a celebrity or develop powerful new relationships, please click here.

We look forward to sharing exciting ideas and methods with you to help you earn more money, and have more free time and enjoyment in your work than you ever thought possible.

Sincerely,
Richard McGuire

If you would like to be removed from our database, click here.






-----------------------------------------------------------------------------------
Post ID:1870
Sender:"John Evdemon" <jevdemon@...>
Post Date/Time:2002-07-16 21:23:37
Subject:Re: [rest-discuss] Re: Is EDI SOAP?
Message:

On 14 Jul 2002 at 23:14, Paul Prescod wrote:
>
> SOAP seems designed to express  as few constraints 
> as possible.

Actually, SOAP 1.2 constrains XML by defining a new infoset that is incompatible with the XML infoset.  
XML purists could use this to claim that SOAP is not XML, but that leads us into a rather ugly (and  
pointless) debate....

On another topic, you mentioned that SOAP does not  
specify any message-exchange patterns.  SOAP 1.2 defines Message Exchange Patterns (MEPs).  MEPs are templates that define patterns for the exchange of 
messages between SOAP nodes.  Part 2 of the SOAP 1.2 spec describes the MEPs provided with SOAP [1].  One of these appears to be somewhat similar to REST 
(based on my rather limited knowledge of REST) [2].

[1] http://www.w3.org/TR/soap12-part2/#soapsupmep
[2] http://www.w3.org/TR/soap12-part2/#WebMethodFeature






-----------------------------------------------------------------------------------
Post ID:1871
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-17 00:35:53
Subject:XML standards for representations
Message:

I am interested in the collective thoughts of the group on the best approach
to defining xml representations. Given the proliferation of standards across
various areas, not to mention within those areas as well, I wonder what the
most prudent approach to take is? The issues (for me at least) are:

1. Multiple standards for the same domain  - how do you choose ? Should you
try and choose something that answers 2 (below) first and let that determine
the answer here ?
2. No standards for the domain - what is the best way to define your own ?
Do you choose a component--oriented base standard such as xCBL or OAGIS and
build your implementation on top of that or reinvent the wheel completely
and implement everything from scratch.? If it is the first option then what
is the best component-oriented standard?
3. Where does the Semantic Web/RDF/DAML/etc fit in? AFAICT none of the
existing standards are implemented using this approach.


Robert







-----------------------------------------------------------------------------------
Post ID:1872
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-17 00:54:07
Subject:Re: XML standards for representations
Message:

Robert Leftwich wrote:
> 3. Where does the Semantic Web/RDF/DAML/etc fit in? AFAICT none of 
the
> existing standards are implemented using this approach.

Robert, I don't know what kind of standards you want, but:

There is a set of "Business Entity" standards being developed in 
UN/CEFACT that I think would be a good basis for a suite of business-
oriented REST resources.  An RDF representation is in the works.

Here's the latest draft:
http://www.collaborativedomain.com/standards/documents/BET%20Draft%
20Technical%20Specification_v008.zip

You can watch for further developments at:
http://www.collaborativedomain.com/standards/

UN/CEFACT grinds exceedingly slow, but the work is free for use.

It's one of those cases of a verbose and seemingly complex spec with 
a terse and simple one wanting to get out.

Disclaimer:  I was involved heavily at one point.







-----------------------------------------------------------------------------------
Post ID:1873
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-17 01:47:02
Subject:Re: [rest-discuss] Re: XML standards for representations
Message:

At 10:54 AM 17/07/2002, bhaugen32 wrote:

>Robert, I don't know what kind of standards you want, but:

As usual, I probably ended up being too general in my earlier email. At this
point in time I am looking to build a list of (preferably)
component-oriented standards for further investigation into their
use as the basis for REST representations. I don't as yet have any
specific requirements for a particular domain, but as an example, the
components in HR-XML [1] (postal address, person name, contact info, etc)
are a good starting point.. Of course, it may be that none of these
standards are sufficiently well advanced to be of real, practical use in the
near term (2-3 months), in which case I  might need to take the build it
from scratch approach. My biggest fear is that betting on the wrong standard
could be disastrous in the longer term.

>...
>Here's the latest draft:
>http://www.collaborativedomain.com/standards/documents/BET%20Draft%
>20Technical%20Specification_v008.zip
>...

Thanks.

>UN/CEFACT grinds exceedingly slow, but the work is free for use.

The slowness may be an issue - any thoughts on how you can position your
product to take advantage of this work when it is finalized?

>It's one of those cases of a verbose and seemingly complex spec with
>a terse and simple one wanting to get out.

So when is the terse and simple one coming out :-)
I'm a big fan of terse and simple !

>Disclaimer:  I was involved heavily at one point.

Good - its look like I may need an interpreter if I pursue it  :-/

Robert

[1] http://www.hr-xml.org (registration required to download)







-----------------------------------------------------------------------------------
Post ID:1874
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-17 20:21:58
Subject:Fw: [syndication] Amazon does SOAP
Message:

Amazon has both HTTP+XML and SOAP.
I downloaded the sdk & one of the references is the RESTwiki --- good job
guys! I think you've made a difference...



----- Original Message -----
From: "Ben Parker" <ben@...>
To: <syndication@yahoogroups.com>
Sent: Wednesday, July 17, 2002 7:50 AM
Subject: [syndication] Amazon does SOAP


>
> From the Amazon affiliates newsletter:
>
> "Build your own Amazon.com Product Detail Page
>
> ...with Amazon.com Web Services! Powered by XML, this new platform
> enables you to display dynamic product information and our best
> merchandising features (Customer Reviews, Customers Also Bought, Add to
> Shopping Cart, and more). Some software development skills are required
> to use this service but help can be found on our Developers Discussion
> Board. Some developers even post applications to help you get started.
> Don't have time to build an XML powered feature yourself? Send your
> ideas to webservices@.... ...
>
> We at Amazon.com want to see Web services work. We believe they are
> important to the future of the Internet. To help stimulate Web service
> innovation, we now offer software developers the opportunity to
> integrate Amazon.com features and content directly into other web sites
> using either SOAP or XML over HTTP. Partner with the leader in
> e-commerce and join the Web services revolution today!
>
>  Go to www.amazon.com/webservices here! "
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>






-----------------------------------------------------------------------------------
Post ID:1875
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-18 00:46:00
Subject:REST breaking out all over
Message:

I met these guys briefly at ETCON. Jeff Bezos was there. All week I
resisted introducing myself because I figured what was the point, he
would not be interested in seemingly tiny details like REST v. SOAP. But
then when I met the Amazon implementors they said that they *had*
discussed the issue with Jeff! Doh!

I did a webex web presentation for a huge publishing conglomerate and
they are very interested in REST. Also, I can't remember if I forwarded
the URL for the CIO of the State of Utah?

 http://www.windley.com/2002/07/03.html

The current SOAP specification says that the Google model was bad form
so it should only be a matter of time before we can count them as REST-y
also.

I am also working with Laird Popkin of the ICE consortium. Even before I
told him about REST they had been thinking about an HTTP-GET modality
for ICE to allow RSS-like usage modes.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1876
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-07-18 05:11:46
Subject:Amazon & Google & REST
Message:

I'm curious. The Amazon interface supports HTTP/URL requests with XML
returned data and some folks here refer to it as being a REST interface.

On the other hand, I've been seeing a lot of postings here and on XML-DEV
about strict adherence to the REST URL scheme (i.e.
http://.../search/isbn/123456789 vs. http://.../search?isbn=123456789).

It seems to me that as long as the service has an HTTP/URL interface vs.
SOAP packets, some folks might consider it as REST. But if you stick with
the strict URL adherence/naming scheme, neither Google nor Amazon are
strictly REST-compliant...

Any thoughts?

Best,
Ramin
---
Ramin Firoozye - Wizen Software

  -----Original Message-----
  From: Paul Prescod [mailto:paul@...]
  Sent: Wednesday, July 17, 2002 5:46 PM
  To: S. Mike Dierken; rest-discuss@yahoogroups.com
  Subject: [rest-discuss] REST breaking out all over


  I met these guys briefly at ETCON. Jeff Bezos was there. All week I
  resisted introducing myself because I figured what was the point, he
  would not be interested in seemingly tiny details like REST v. SOAP. But
  then when I met the Amazon implementors they said that they *had*
  discussed the issue with Jeff! Doh!

  I did a webex web presentation for a huge publishing conglomerate and
  they are very interested in REST. Also, I can't remember if I forwarded
  the URL for the CIO of the State of Utah?

  http://www.windley.com/2002/07/03.html

  The current SOAP specification says that the Google model was bad form
  so it should only be a matter of time before we can count them as REST-y
  also.

  I am also working with Laird Popkin of the ICE consortium. Even before I
  told him about REST they had been thinking about an HTTP-GET modality
  for ICE to allow RSS-like usage modes.
  --
  Come discuss XML and REST web services at:
    Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
    Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

        Yahoo! Groups Sponsor
              ADVERTISEMENT



  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.






-----------------------------------------------------------------------------------
Post ID:1877
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-18 05:34:36
Subject:Re: [rest-discuss] Amazon & Google & REST
Message:

> I'm curious. The Amazon interface supports HTTP/URL requests with 
> XML returned data and some folks here refer to it as being a REST 
> interface.
>  
> On the other hand, I've been seeing a lot of postings here and 
> on XML-DEV about strict adherence to the REST URL scheme (i.e. 
> http://.../search/isbn/123456789 vs.
> http://.../search?isbn=123456789).

No, actually it is strictly REST. If the client needs to generate a URI
using information only known to the client (like an ISBN number or a
date) then the URI should use a query string. But even if it wasn't
strictly REST-y, I wouldn't fuss too much about the construction of URIs
because in the web architecture URIs are typically opaque.

> It seems to me that as long as the service has an HTTP/URL interface 
> vs. SOAP packets, some folks might consider it as REST. But if 
> you stick with the strict URL adherence/naming scheme, neither 
> Google nor Amazon are strictly REST-compliant...

Some pure-HTTP services are very un-REST. 

 * http://www.prescod.net/rest/mistakes/

But Amazon does not have this problem.

During ETCON someone implied that they were using GET for things other
than queries but I don't see anything about that. They use POST for
mutations which is good. And the XSLT service looks really cool. Good
work!
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1878
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-18 09:03:24
Subject:RE: [rest-discuss] Amazon & Google & REST
Message:


> -----Original Message-----
> From: Paul Prescod [mailto:paul@...t] 
> 
> No, actually it is strictly REST. If the client needs to 
> generate a URI using information only known to the client 
> (like an ISBN number or a
> date) then the URI should use a query string. 

Why is that?

> But even if it 
> wasn't strictly REST-y, I wouldn't fuss too much about the 
> construction of URIs because in the web architecture URIs are 
> typically opaque.

URIs are hardly opaque. The schemes have structure that needs to be
parsed out.

Bill de hra
..
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:1879
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-18 12:19:45
Subject:Re: [rest-discuss] Amazon & Google & REST
Message:

Bill de h�ra wrote:
> 
> > -----Original Message-----
> > From: Paul Prescod [mailto:paul@...]
> >
> > No, actually it is strictly REST. If the client needs to
> > generate a URI using information only known to the client
> > (like an ISBN number or a
> > date) then the URI should use a query string.
> 
> Why is that?

http://www.w3.org/DesignIssues/Axioms.html#query

> > But even if it
> > wasn't strictly REST-y, I wouldn't fuss too much about the
> > construction of URIs because in the web architecture URIs are
> > typically opaque.
> 
> URIs are hardly opaque. The schemes have structure that needs to be
> parsed out.

URIs are opaque to the client application. Obviously the client's
URI-derefencing implementation needs to parse them to do the
dereferencing, but the application using the implementation doesn't need
to do that.

http://www.w3.org/DesignIssues/Axioms.html#opaque

I'm hoping those documents answer the questions but if not, ask again.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1880
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-18 12:31:18
Subject:Re: [rest-discuss] Amazon & Google & REST
Message:

On Thu, Jul 18, 2002 at 10:03:24AM +0100, Bill de h�ra wrote:
> 
> 
> > -----Original Message-----
> > From: Paul Prescod [mailto:paul@...] 
> > 
> > No, actually it is strictly REST. If the client needs to 
> > generate a URI using information only known to the client 
> > (like an ISBN number or a
> > date) then the URI should use a query string. 
> 
> Why is that?

Well, that's how it currently is because that's the only deployed
convention.  It's also the simplest, because the namespace for query
parameters is flat.

But in the future, some new spec could come out which would allow
resource publishers to communicate to clients, how to construct URIs
based on other criteria ... if folks found that useful.

The key being that the client never guesses, and so must always be
following directions provided by the resource publisher.  Otherwise it's
inferring semantics from structure, and that breaks opacity.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1881
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-18 15:14:55
Subject:URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

Bill,

Your point is well made --- there *are* in fact URI structure schemes, and
hierarchical semantics in URI paths.  However, it's dogmatic that we pretend
this is not the case.  We've had many rather ugly battles over this fact on
this list, i.e. over the dogmatic "fundamentalist" interpretation of the
Axiom of Opacity.  My suggestion to you would be:  it's not worth arguing
about.  Save yourself some grief, just do what you need to do.

I will make one point about the Axiom of Opacity, one I've made before but
which bears repeating:  it's literally and obviously incorrect vis--vis
existing Web architecture.  The axiom says that all you can do with a URI is
deference it.  In fact, it is *essential* to the Web architecture that URI
support at least two other kinds of semantics, namely:

* It must be possible to compare URI for equivalence (proxies, etc.)
  
* It must be possible to construct a URI from another complete URI and
    a relative URI.

The latter gives particular credence to your argument;  it specifically
comprehends and exploits the hierarchical nature of the path part of the
URI.  These two observations together undermine my ability to take the Axiom
seriously, and I believe that anyone approaching the issue with an open mind
will interpret the situation similarly.

Jb







-----------------------------------------------------------------------------------
Post ID:1882
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-18 15:51:18
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

Jeff Bone wrote:
> 
> .... In fact, it is *essential* to the Web architecture that URI
> support at least two other kinds of semantics, namely:
> 
> * It must be possible to compare URI for equivalence (proxies, etc.)
> 
> * It must be possible to construct a URI from another complete URI and
>     a relative URI.

IMO, a web toolkit that properly supports the web/REST model would
provide a URI object with the following three methods:

uri.dereference(method, headers, representation)
uri.compare()
uri.create(base, relative, query_params)

If *applications* stick to those three methods then you will not
accidentally treat XML as HTML by sniffing the file extension, you will
not accidentally infer hierarchical relationships that don't exist, you
will not accidentally treat a .jsp as code rather than data, you will
not accidentally make code that works with HTTP but not HTTPS (or any
other REST-compliant protocol) etc.

If your client or intermediary application only deals with URIs through
these methods then IMO, that application properly treats URIs as opaque.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1883
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-18 16:01:23
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

Paul Prescod wrote:
> 
>...
> 
> IMO, a web toolkit that properly supports the web/REST model would
> provide a URI object with the following three methods:
> 
> uri.dereference(method, headers, representation)
> uri.compare()
> uri.create(base, relative, query_params)

Perhaps not coincidentally, these are roughly the same three things you
can portably do with a C++ pointer:

foo *r,*s;

s->method(params);
cout << (s == r);
r = s+1;

Java can't do the last but I think that is because it is just a
performance hack in C++ and a minimization hack in the Web architecture.

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1884
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-18 17:32:38
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

(If you're interested in this issue, please read on... Hopefully informative
w/o being inflammatory.)


On 7/18/02 10:51 AM, "Paul Prescod" <paul@...> wrote:

> ...

Paul, you and I perpetually argue about this topic, though in fact there's
more agreement than the discussion might seem to indicate.  Let me see if I
can reframe my argument in terms you can agree with.  First, here is the
Axiom of Opacity:

"The only thing you can use an identifier for is to refer to an object. When
you are not dereferencing you should not look at the contents of the URI
string to gain other information..."

(I eliminated "as little as possible" as it's a typical TBLism that is
neither quantifiable nor objective.)

My point is this:  this is *clearly* inaccurate even with respect to
existing standardized practices.  As you yourself agree, there are at least
two other semantics:  comparison (a form of deconstruction) and construction
from relative URI.  So URI do *not* only support dereference;  it is
necessary to look at the contents of the URI string in some contexts to gain
the information necessary to use them the way they need to be used.

.:, URI are not opaque in any sense consistent with the Axiom, and perhaps
not opaque in any meaningful sense.

Despite this, you and I share and agree on an "intuitive" definition of
"opacity" that we believe is desirable for URI.  A better way to put this,
rather than calling it "opacity," would be:  URI do NOT have any implicit
semantics.  All operations and semantics on URI *must* be explicitly
specified.  I would even go further and say that these semantics must not
only be explicit, they must be universal within a given URI scheme.  In this
sense, I perhaps advocate "opacity" (really, its intent) even more strongly
than you.

> 
> If *applications* stick to those three methods then you will not
> accidentally treat XML as HTML by sniffing the file extension, you will
> not accidentally infer hierarchical relationships that don't exist, you
> will not accidentally treat a .jsp as code rather than data, you will
> not accidentally make code that works with HTTP but not HTTPS (or any
> other REST-compliant protocol) etc.

Here we agree on desired outcome but disagree on how to get there.  We agree
that URI should not e.g. have content type semantics embedded in them.  URI
are names - not type descriptions.  Parsing URI to determine type is a bad
thing, and indeed it is historically the motivation for the "Axiom" in
question.  In general, lots of problems result when you start assuming
things about the semantics of URI.

But that doesn't mean that URI *should* or even *do* have only the semantics
of dereference, or even the set of { deref, compare, construct-relative }.
There may well be other semantics of construction and deconstruction that
are both generic (universal) and useful / desirable.  My argument is
therefore the following:

Given any universal / useful mechanism for use / construction /
deconstruction of URI beyond { deref, compare, construct-relative }, there
is *no* particular reason to reject such a mechanism out of hand on the
basis of the clearly defective "Axiom" of URI Opacity alone.

Sure, such rejection is "safe" --- if we assume just those three operations,
we can be sure that programs that use just those operations work correctly.
And this is a good thing.  In general, constraints are a good thing --- the
Web gains much of its power through its constraining mechanisms.  However,
constraints should not be arbitrary, and IMO rejecting the possibility of
additional explicit / universal semantics for URI is just such an
unacceptable, arbitrary constraint.  By itself, the existence of the
so-called Axiom is not sufficient to reject the possibility that other
universal and useful semantics might be explicitly specified at some point.

$0.02,

Jb

PS - one other important bit.  It's important to distinguish between HTTP
URI and URI in general.  The Axiom of Opacity is intended to apply to all
URI, not just HTTP-scheme URI.  And while it may (or may not) be desirable
to ignore the hierarchical semantics of the path part of an HTTP URI, it's
***NOT*** the case that this is desirable in all conceivable URI schemes.
Filesystem related schemes like smb:// and nfs:// absolutely *require* that
clients of those protocols be able to deconstruct and comprehend URI
according to their hierarchical structure.  So another problem with the
Axiom of Opacity --- and its dogmatic interpretation --- is that it is
overly biased to the-Web-of-HTTP-and-hypertext.  It assumes things that it
cannot assume about non-HTTP URI schemes.










-----------------------------------------------------------------------------------
Post ID:1885
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-07-18 19:59:30
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

> IMO, a web toolkit that properly supports the web/REST model would
> provide a URI object with the following three methods:
> 
> uri.dereference(method, headers, representation)
> uri.compare()
> uri.create(base, relative, query_params)

That's what we've done for our app, actually. :)

Just to make I understand the common consensus... the URI is opaque for 
the client and the network as a whole, but not the server?  I say this 
because obviously the server has to be able to interpret that URI to 
find the object.  Am I close here?

Thanks,
Seth





-----------------------------------------------------------------------------------
Post ID:1886
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-18 20:23:49
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

From: "Seth Ladd" <seth@...>
>
> > IMO, a web toolkit that properly supports the web/REST model would
> > provide a URI object with the following three methods:
> >
> > uri.dereference(method, headers, representation)
> > uri.compare()
> > uri.create(base, relative, query_params)
>
> That's what we've done for our app, actually. :)
>
> Just to make I understand the common consensus... the URI is opaque for
> the client and the network as a whole, but not the server?  I say this
> because obviously the server has to be able to interpret that URI to
> find the object.  Am I close here?

I think he is going a step further and saying that things other than the URI
owner (the server) should be able to apply the above methods.  For instance,
your client should be able to do the compare() method to determine if the
same resource is being requested again.  When you submit a form to a
relative URI, the client must be able to use the create() method to generate
an absolute URI from from a base and a relative (and possibly a query
string).  For instance, suppose you have an html form in a resource pointed
to by http://site.com/foo.  The form method is GET and the action is
"bar/baz".  When you submit the form, the client will create a URI that will
look something like http://site.com/foo/bar/baz?field=value.  In order to do
this (or the comparison), the client must be able to understand more about
the URI (within the http scheme space) than the basic ability to dereference
it.

At least I think that's what he is saying...

---
Seairth Jacobs
seairth@...









-----------------------------------------------------------------------------------
Post ID:1887
Sender:DJ Adams <dj.adams@...>
Post Date/Time:2002-07-18 20:36:01
Subject:Q: using Accept: header
Message:

Hi all

I'm just learning about REST, and reading as much as I can. Currently
it's Roger Costello's tutorial [1] (thanks Roger). 

On slide 12 [2], I read "...allow the client to specify ... HTML ...
or XML" followed by the example URL with ?flavor=xml at the end. 

I'm not at all trying to find fault with the tutorial, but I was wondering
this: Is it more (or less?) appropriate (in a REST context) for the client
to use the HTTP Accept: header to declare what it wants (e.g. text/html or
text/xml) rather than modifying the URI?

Thanks
dj
http://www.pipetree.com/qmacro


[1] http://www.xfront.com/REST.html
[2] http://www.xfront.com/sld012.htm







-----------------------------------------------------------------------------------
Post ID:1888
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-18 20:37:42
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

Seth Ladd wrote:
> 
>...
> 
> That's what we've done for our app, actually. :)
> 
> Just to make I understand the common consensus... the URI is opaque for
> the client and the network as a whole, but not the server?  I say this
> because obviously the server has to be able to interpret that URI to
> find the object.  Am I close here?

I think that that is pretty much it!

There is a corner case where the server is just a "file storage" and
some other agent is actually inventing the URIs and storing information
with them. In that case, the agent inventing the URIs is of course the
one that can treat them as transparent rather than opaque.

Also, Jeff says that if the client and server negotiate somehow (prose
document or something else), the server could delegate the right to
interpret the URIs. I don't think that this is very often necessary in
practice but as long as permission was given explicitly it would be okay
with me.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1889
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-18 20:39:37
Subject:Re: [rest-discuss] Q: using Accept: header
Message:

Yes, I think that content negotiation is more appropriate if your
software supports it.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1890
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-18 20:45:43
Subject:Re: [rest-discuss] Fw: [syndication] Amazon does SOAP
Message:

Does anybody have the requisite access to do a REST-y analysis of EBay's
XML/HTTP APIs?
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1891
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-18 20:54:14
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

On 7/18/02 2:59 PM, "Seth Ladd" <seth@...> wrote:

> 
>> IMO, a web toolkit that properly supports the web/REST model would
>> provide a URI object with the following three methods:
>> 
>> uri.dereference(method, headers, representation)
>> uri.compare()
>> uri.create(base, relative, query_params)
> 
> That's what we've done for our app, actually. :)
> 
> Just to make I understand the common consensus... the URI is opaque for
> the client and the network as a whole, but not the server?  I say this
> because obviously the server has to be able to interpret that URI to
> find the object.  Am I close here?

Yup.  But...

Now here's the interesting question:  what about intermediaries? ;-)  In
general "opacity" is a good thing, but intermediaries by their very nature
need to have a deeper understanding of things.

Jb

> 
> Thanks,
> Seth
> 







-----------------------------------------------------------------------------------
Post ID:1892
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-18 21:10:57
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

Jeff Bone wrote:
> 
>...
> 
> My point is this:  this is *clearly* inaccurate even with respect to
> existing standardized practices.  As you yourself agree, there are at least
> two other semantics:  comparison (a form of deconstruction) and construction
> from relative URI.  So URI do *not* only support dereference;  it is
> necessary to look at the contents of the URI string in some contexts to gain
> the information necessary to use them the way they need to be used.
> 
> .:, URI are not opaque in any sense consistent with the Axiom, and perhaps
> not opaque in any meaningful sense.

If you read the whole document, Tim BL quotes both of these
"exceptions". A more formal exposition would put all of the things you
can do with URIs together. But I've always read the document as "URIs
are opaque with the exceptions listed in this document." My concern is
that we not present these "exceptions" as evidence that the dam is
leaking and therefore why not let all of the water in? A simple
editorial change on Tim BLs part could turn those "exceptions" into just
clearly described things you ARE allowed to do with URIs.

"The only thing you can use an identifier for is to refer to an object.
When you are not dereferencing, comparing or constructing absolute URIs
from relative ones, you should not look at the contents of the URI
string to gain other information..."

> Despite this, you and I share and agree on an "intuitive" definition of
> "opacity" that we believe is desirable for URI.  A better way to put this,
> rather than calling it "opacity," would be:  URI do NOT have any implicit
> semantics.  All operations and semantics on URI *must* be explicitly
> specified.  I would even go further and say that these semantics must not
> only be explicit, they must be universal within a given URI scheme.  In this
> sense, I perhaps advocate "opacity" (really, its intent) even more strongly
> than you.

If you want to make the level of opacity a scheme-specific "property"
that's okay with me. I'm pretty much the most hard-line HTTP scheme
bigot anyhow.

Do you and I also agree that the specification for HTTP URIs does not
allow you to infer that given:

http://x.com/foo/bar

that there is a resource "http://x.com/foo"?

>...
>...
> Sure, such rejection is "safe" --- if we assume just those three operations,
> we can be sure that programs that use just those operations work correctly.
> And this is a good thing.  In general, constraints are a good thing --- the
> Web gains much of its power through its constraining mechanisms.  However,
> constraints should not be arbitrary, and IMO rejecting the possibility of
> additional explicit / universal semantics for URI is just such an
> unacceptable, arbitrary constraint.  By itself, the existence of the
> so-called Axiom is not sufficient to reject the possibility that other
> universal and useful semantics might be explicitly specified at some point.

Okay, I can agree to that. But it's very different than giving people
the advice that they should just do what they feel like when it comes to
opacity. Until someone, somewhere defines other universal operators for
URIs, as far as I know the only operations available are {deref,
compare, construct-relative}. So for now, opacity "you shouldn't do
other stuff with URIs, or at least HTTP URIs."

And of course there is an ambigious "you" in the formulation. "You"
cannot include the entity (usually a server) responsible for mapping
from URIs to real resources.

>...
> PS - one other important bit.  It's important to distinguish between HTTP
> URI and URI in general.  The Axiom of Opacity is intended to apply to all
> URI, not just HTTP-scheme URI.  And while it may (or may not) be desirable
> to ignore the hierarchical semantics of the path part of an HTTP URI, it's
> ***NOT*** the case that this is desirable in all conceivable URI schemes.
> Filesystem related schemes like smb:// and nfs:// absolutely *require* that
> clients of those protocols be able to deconstruct and comprehend URI
> according to their hierarchical structure.  

We disagree on whether these non-REST resources are first-class parts of
"the Web" but that is the sort of argument that will never terminate for
lack of clear definitions.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1893
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-07-18 21:26:18
Subject:RE: [rest-discuss] Fw: [syndication] Amazon does SOAP
Message:

Sorry. Last I looked, it cost $1000+ runtime usage fees to even take a look
at their APIs. I also seem to recall there were restrictions on being able
to discuss them openly once you signed their agreement.

I'm guessing they're so strict with their terms because there are people out
there who have tried to sneak around the backdoor and run automated mass
postings and bids, so I can't say I blame them too much.

Ramin
  -----Original Message-----
  From: Paul Prescod [mailto:paul@...]
  Sent: Thursday, July 18, 2002 1:46 PM
  To: S. Mike Dierken; rest-discuss@yahoogroups.com
  Subject: Re: [rest-discuss] Fw: [syndication] Amazon does SOAP


  Does anybody have the requisite access to do a REST-y analysis of EBay's
  XML/HTTP APIs?
  --
  Come discuss XML and REST web services at:
    Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
    Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

        Yahoo! Groups Sponsor
              ADVERTISEMENT



  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.






-----------------------------------------------------------------------------------
Post ID:1894
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-07-18 21:36:36
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

> There is a corner case where the server is just a "file storage" and
> some other agent is actually inventing the URIs and storing information
> with them. In that case, the agent inventing the URIs is of course the
> one that can treat them as transparent rather than opaque.
> 
> Also, Jeff says that if the client and server negotiate somehow (prose
> document or something else), the server could delegate the right to
> interpret the URIs. I don't think that this is very often necessary in
> practice but as long as permission was given explicitly it would be okay
> with me.

I think it's actually too hard to give semantic meaning to the URI, 
which is probably which everyone says they should be outwardly opaque. 
How do you convey that meaning to a global audience?

It might have meaning to some participants, but there is no way to 
formally publish those meanings, so no systems should be built having to 
understand the URI.  One merely has to GET that URI and use (hopefully) 
RDF to understand what that object is.  And to understand the encoding 
of that object, use the MIME type.

OK, *phew*.

Thanks!
Seth





-----------------------------------------------------------------------------------
Post ID:1895
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-18 21:49:11
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

On 7/18/02 4:10 PM, "Paul Prescod" <paul@...> wrote:

> Jeff Bone wrote:
>> 
>> ...
>> 
>> My point is this:  this is *clearly* inaccurate even with respect to
>> existing standardized practices.  As you yourself agree, there are at least
>> two other semantics:  comparison (a form of deconstruction) and construction
>> from relative URI.  So URI do *not* only support dereference;  it is
>> necessary to look at the contents of the URI string in some contexts to gain
>> the information necessary to use them the way they need to be used.
>> 
>> .:, URI are not opaque in any sense consistent with the Axiom, and perhaps
>> not opaque in any meaningful sense.
> 
> If you read the whole document, Tim BL quotes both of these
> "exceptions". A more formal exposition would put all of the things you
> can do with URIs together.

No confusion here, that's always been quite evident.

> But I've always read the document as "URIs
> are opaque with the exceptions listed in this document."

And I agree that this is the intended interpretation.  BUT --- I disagree
that this interpretation is "healthy" for the overall architecture of the
Web.  The Axiom of Opacity is, historically, exactly and only a reaction to
the early and broken use of filename extensions in HTTP URI to determine
filetype.

The problem I have is that it goes to far.  A single axiom, particularly one
as poorly stated and overly general as the one in question, constrains the
entire architecture of the Web.

So the question is what's the "real" intent of the axiom?  Is it to
constrain the semantics of all URI, HTTP and otherwise, to the one (or two,
or three...) operations explicitly called out?  Or is it to say that the
semantics of URI should be minimal, explicit, and universal --- and that URI
should not be used otherwise?

IMO, in the absence of rationale for the former - in the absence of some
kind of rigorous and compelling argument that demonstrates that indeed,
those three operations form a complete and expressive operational semantics
for all URI of all types - I prefer to assume the latter intent.  It
provides a framework of constraint without being overly or arbitrarily
constraining.

> My concern is
> that we not present these "exceptions" as evidence that the dam is
> leaking and therefore why not let all of the water in? A simple
> editorial change on Tim BLs part could turn those "exceptions" into just
> clearly described things you ARE allowed to do with URIs.

But in fact the dam is leaking, and it's not a matter of letting all the
water in.  It's a matter of fixing the leak.  The leak is the that, I
believe, the Axiom doesn't achieve its true intent.

> 
> "The only thing you can use an identifier for is to refer to an object.
> When you are not dereferencing, comparing or constructing absolute URIs
> from relative ones, you should not look at the contents of the URI
> string to gain other information..."
> 

So, are you talking about all URI or just HTTP URI?  If all URI, I'll tell
you that you're wrong to constrain things thus, because other applications
*require* deeper semantics of names.

> Do you and I also agree that the specification for HTTP URIs does not
> allow you to infer that given:
> 
> http://x.com/foo/bar
> 
> that there is a resource "http://x.com/foo"?
>

I do agree that the inference above is not a safe assumption in today's
world.  Whether or not that's a good or bad thing is open to debate and
rationale / justification for such debate differs between applications.  In
the absence of specific knowledge that the provider x.com made such a
guarantee, making this kind of an inference is a mistake.

> Okay, I can agree to that. But it's very different than giving people
> the advice that they should just do what they feel like when it comes to
> opacity. 

I think you're over-interpreting what I've said.

> Until someone, somewhere defines other universal operators for
> URIs, as far as I know the only operations available are {deref,
> compare, construct-relative}. So for now, opacity "you shouldn't do
> other stuff with URIs, or at least HTTP URIs."
> 
> And of course there is an ambigious "you" in the formulation. "You"
> cannot include the entity (usually a server) responsible for mapping
> from URIs to real resources.

What of an entity that maps URI into other URI according to some
algorithm...?

jb







-----------------------------------------------------------------------------------
Post ID:1896
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-18 22:57:37
Subject:Re: [rest-discuss] Amazon & Google & REST
Message:

> ----- Original Message -----
> From: Ramin Firoozye

> On the other hand, I've been seeing a lot of postings here and on XML-DEV
about
> strict adherence to the REST URL scheme (i.e.
http://.../search/isbn/123456789 vs. http://.../search?isbn=123456789).
There is no such thing as 'the REST URL scheme'.
The identifier of a resource - the URI or URL - is the /whole/ text string,
not just the segments with '/' characters. This is an important point and I
myself didn't realize it for a long time. The resource is identifed by
path+query - not just the 'path'. Appending a query string onto a path
identifies a /different/ resource. There are many more resources than you
would think at first.

The query string (after the '?' character) is a part of the whole resource
identifier. It happens to be a part that is easy to describe to developers
when they want to construct the full identifier. If you can't construct the
identifier, you have to harvest it from some sort of XML (or other media
format) and that is just as complex as telling people how to construct the
darn URI in the first place...

Anyway... both formats are equally fine, but the query string approach is
easier to document.








-----------------------------------------------------------------------------------
Post ID:1897
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-18 23:28:51
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>
>
> Also, Jeff says that if the client and server negotiate somehow (prose
> document or something else), the server could delegate the right to
> interpret the URIs. I don't think that this is very often necessary in
> practice but as long as permission was given explicitly it would be okay
> with me.

I would think that the HTML FORM element gives us a real-world example of
this.

For example:

<form action='bizdocs'>
 <input name='doc-type' />
 <input name='doc-id' />
</form>

is enough for todays browsers to construct URIs:
 http://current-domain/bizdocs?doc-type=catalog&doc-id=72

I should be able to use this markup to know how to GET and PUT and DELETE
this resource - with the major assumption that the value-space is something
the client knows. Mapping value-space between systems - especially across
organizational boundaries - is another ball of wax that people don't
normally talk about.

<flames-go-here target='/dev/null' />








-----------------------------------------------------------------------------------
Post ID:1898
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-18 23:37:09
Subject:Re: [rest-discuss] Q: using Accept: header
Message:

----- Original Message -----
From: "DJ Adams" <dj.adams@...>

>
> I'm just learning about REST, and reading as much as I can. Currently
> it's Roger Costello's tutorial [1] (thanks Roger).
>
> On slide 12 [2], I read "...allow the client to specify ... HTML ...
> or XML" followed by the example URL with ?flavor=xml at the end.
>
> I'm not at all trying to find fault with the tutorial, but I was wondering
> this: Is it more (or less?) appropriate (in a REST context) for the client
> to use the HTTP Accept: header to declare what it wants (e.g. text/html or
> text/xml) rather than modifying the URI?

For a pure 'automatable Web' application then it is much better to use the
Accept header.
If you have to interoperate with browsers you may need to resort to these
sorts of hacks - and if so, I'd recommend using a naming convention that can
easily point to the HTTP semantics. for example: ...?do:accept=text/xml
where the 'do:' part is equivalent to an HTTP header of the same name. I
would have used 'http:' but that would have been really confusing...

All that said, I think the separation of resource and representation is the
part of REST that almost all tools (servers, clients, etc.) have the most
problem with. Think of all the ASP, JSP, PHP, etc that have the content to
be output hardcoded right there in the file - not very easy to switch based
upon the Accept header (unless you use internal server-side redirects).

I think all of todays 'visual Web' applications are doing fine at exposing
/user interface/ with HTTP, but I have a sinking feeling that for an
'automatable Web' we are going to need new server environments and new
clients. The new clients aren't that hard, its re-using exising server
technology that might be a problem. But maybe I'm being pessimistic.








-----------------------------------------------------------------------------------
Post ID:1899
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-18 23:41:27
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> Do you and I also agree that the specification for HTTP URIs does not
> allow you to infer that given:
>
> http://x.com/foo/bar
>
> that there is a resource "http://x.com/foo"?

There is an /identifier/ however and when you check via GET or HEAD it may
or may not exist.







-----------------------------------------------------------------------------------
Post ID:1900
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-19 02:50:50
Subject:URIs, GET, and dynamic resources
Message:

I am having a bit of trouble understanding how RESTful web services serve up
dynamic content when using GET.  For instance, suppose you have the
following URL:

http://www.seairth.com/time.php

Now, suppose that this each time the URL is submitted, it returns the
current time in GMT.  From what I understand, GET is ideally suppose to have
the same resource/representation returned each time it is submitted.
However, this would not be the case here.  So is GET not the appropriate
verb to use here, or does it not matter what is returned each time?

I understand that GET is not supposed to change the state of the the
resource being requested.  Suppose you had the following URL:

http://www.seairth.com/hitcount.php

Now, in this case, each time it the URL is submitted, the server increments
an internal hit counter and returns the current hit count.  In this case,
the actual act of making the request has cause the state to change.  Should
GET not be used in a case like this, or is the GET request not actually the
thing which is changing the resource state?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:1901
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-19 03:48:25
Subject:Re: [rest-discuss] URIs, GET, and dynamic resources
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>
To: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Thursday, July 18, 2002 7:50 PM
Subject: [rest-discuss] URIs, GET, and dynamic resources


> I am having a bit of trouble understanding how RESTful web services serve
up
> dynamic content when using GET.  For instance, suppose you have the
> following URL:
>
> http://www.seairth.com/time.php
>
> Now, suppose that this each time the URL is submitted, it returns the
> current time in GMT.  From what I understand, GET is ideally suppose to
have
> the same resource/representation returned each time it is submitted.
Actually it is supposed to be the current value of the resource - if the
resource has changed, a new value will be sent.

> However, this would not be the case here.  So is GET not the appropriate
> verb to use here, or does it not matter what is returned each time?
If the resource is 'current time' then it the content will always vary over
time. Using GET is just fine.
If you have a resource that is a clock and you want to re-set the time to
some value, then GET is not the right method.

>
> I understand that GET is not supposed to change the state of the the
> resource being requested.  Suppose you had the following URL:
>
> http://www.seairth.com/hitcount.php
>
> Now, in this case, each time it the URL is submitted, the server
increments
> an internal hit counter and returns the current hit count.  In this case,
> the actual act of making the request has cause the state to change.
Should
> GET not be used in a case like this, or is the GET request not actually
the
> thing which is changing the resource state?
Kind of a catch-22 sure, but the 'not change state' constraint has to do
with the intent of the GET - sending a GET request in order to modify state
and as the documented mechanism for that resource is what should be avoided.

The hit-counter problem is a fuzzy area of the 'GET is safe and idempotent'
requirement, but I don't think the requirement is so constraining that
hit-counters are not allowed. I believe a resource can be defined in terms
of the history of that resource and not just some static data values
somewhere.







-----------------------------------------------------------------------------------
Post ID:1902
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-19 09:29:02
Subject:RE: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:


> -----Original Message-----
> From: Paul Prescod [mailto:paul@...t] 
>
> If you read the whole document, Tim BL quotes both of these 
> "exceptions". A more formal exposition would put all of the 
> things you can do with URIs together. But I've always read 
> the document as "URIs are opaque with the exceptions listed 
> in this document." 

Axioms shouldn't have exceptions, axioms are necessary, foundational
truths. Correct me if I'm wrong, but I thought the exception to an axiom
is another contradictory axiom. That's not to dismiss the document
outright, it has excellent principles within it.

Bill de hra

..
Propylon
www.propylon.com 








-----------------------------------------------------------------------------------
Post ID:1903
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-19 14:59:43
Subject:GET Query String or POST content? (was Re: [rest-discuss] Amazon & Google & REST)
Message:

> The identifier of a resource - the URI or URL - is the /whole/ text
string,
> not just the segments with '/' characters. This is an important point and
I
> myself didn't realize it for a long time. The resource is identifed by
> path+query - not just the 'path'. Appending a query string onto a path
> identifies a /different/ resource. There are many more resources than you
> would think at first.
>
> The query string (after the '?' character) is a part of the whole resource
> identifier. It happens to be a part that is easy to describe to developers
> when they want to construct the full identifier. If you can't construct
the
> identifier, you have to harvest it from some sort of XML (or other media
> format) and that is just as complex as telling people how to construct the
> darn URI in the first place...

Okay, suppose you had an html form that looked something like:

<form action="http://seairth.com/getinformation">
<input name="userid" type="text">
</form>

Now, if I were to submit it using the GET method, you would have a URL that
looked like:

http://seairth.com/getinformation?userid=seairth

On the other hand, if I were to submit it using POST, you would have:

http://seairth.com/getinformation

and the content of the message would have:

userid=seairth


Now, you are saying that the two resulting URLs above are different
identifiers.  On the on hand, I would say that the GET should be used here
since the intent of this request is idempotent.  On the other hand, using a
GET allows the client to create it's own identifier (of which their could be
an unlimited number of variations).  Using a POST would mean that the same
identifier was is every time.  Also, since the client does not know whether
it's action is idempotent or not, using POST acknowledges this possibility.
However, using POST would not allow effective caching since the same URL
(identifier) may return different results for each request.

So, in REST fashion, what would be the more appropriate method here?


Part of the reason I am asking this has to do with GTP [1].  After reading
some of the discussions on this list and reading the Axioms of Web
Architecture [2] piece, I had thought that I could make the following
requirement:

In the {from} and {to} nodes, the URI used is always controlled by the owner
of the URI.  In other words, the recipient of the URI is never allowed to
modify the URI and thereby create a new identifier.  Instead, anything
generated by the recipient would go inside a {get}, {put}, {add}, {edit}, or
{delete} node.  In this case, the difference between {get} and {put} here
are their intent, specifically that {get} should be used for idempotent
messages while {put} does not have that restriction.  In the above example,
you would end up with a GTP message that looked something like:

{onx
    {gtp
        {to [URI "gtp://seairth.com/getinformation"]}
        {get [userid "seairth"]}
    }gtp
}onx

or

{onx
    {gtp
        {to [URI "gtp://seairth.com/getinformation"]}
        {put [userid "seairth"]}
    }gtp
}onx


where the actual choice of which verb is used is based on the intent (in
this case, more likely the {get}).  As a note, I have no problem with the
URI containing a query string as long as the owner of the URI set the query
string (e.g. to maintain a session id).  I would not expect this usage to be
common, but I don't see any reason for disallowing it.

Then you come along and pointed out that query strings (the part that the
client has the ability to create) are (or can be) part of the identifier.
So this got me to wondering if enforcing this separation in GTP was a good
thing or not.  I think it helps to provide a clean and consistant set of
rules as to how URIs should be used.  But, is this RESTful?

[1] www.seairth.com/web/rpc/gtp.html
[2] www.w3.org/DesignIssues/Axioms.html

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:1904
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-19 17:10:04
Subject:Order changes and hyperlinks
Message:

Thinking more about the recent discussion of order changes on the ws-
arch mailing list: 

There was a missing dimension to the discussion that points out 
something important about REST:
Order changes have ripple effects.

Orders are seldom isolated activities.
Instead they are connected in networks of economic exchanges.

For example, your computer order to e.g. Dell is connected to 
dependent demands for all of the components of the computer, none of 
which are manufactured by Dell, but only assembled and shipped.

If all of those dependent activities have URIs, then they can be 
hyperlinked together.  

And if you change your order to Dell, the ripple effects of that 
change can traverse those hyperlinks.

Now I know that all of those rippling notifications can happen 
without hyperlinks.  Via expensive proprietary software.  Hyperlinks 
could turn at least the links into infrastructure.

There are similar dependencies and ripple effects of change in many 
other domains, e.g. software development.

There should be a terrific REST story rippling through these links.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1905
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-19 17:31:09
Subject:Re: [rest-discuss] Order changes and hyperlinks
Message:

Right.  This is old news, isn't it?  The big story is application layer
routing.  You could imagine suppliers subscribed to "demand resources"
via HTTP WATCH/MONITOR/SUBSCRIBE, etc..

Basically, treating the entire supply network as one huge coordination
problem.

MB

On Fri, Jul 19, 2002 at 05:10:04PM -0000, bhaugen32 wrote:
> Thinking more about the recent discussion of order changes on the ws-
> arch mailing list: 
> 
> There was a missing dimension to the discussion that points out 
> something important about REST:
> Order changes have ripple effects.
> 
> Orders are seldom isolated activities.
> Instead they are connected in networks of economic exchanges.
> 
> For example, your computer order to e.g. Dell is connected to 
> dependent demands for all of the components of the computer, none of 
> which are manufactured by Dell, but only assembled and shipped.
> 
> If all of those dependent activities have URIs, then they can be 
> hyperlinked together.  
> 
> And if you change your order to Dell, the ripple effects of that 
> change can traverse those hyperlinks.
> 
> Now I know that all of those rippling notifications can happen 
> without hyperlinks.  Via expensive proprietary software.  Hyperlinks 
> could turn at least the links into infrastructure.
> 
> There are similar dependencies and ripple effects of change in many 
> other domains, e.g. software development.
> 
> There should be a terrific REST story rippling through these links.
> 
> -Bob Haugen
> 
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 

-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1906
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-07-19 18:15:12
Subject:Another approach
Message:

rest-folks:

We just released a new software package called NetGlue.
It lets you turn code libraries, databases, web-sites, and
web-service into 'plug-in' components. These can be invoked from 
a variety of languages, and via both SOAP and HTTP URLs.
 
Services exposed using NetGlue are automatically HTTP/URL-accessible.
I won't go so far as to call it REST-compliant, but its approach is 
closer to REST than SOAP (URL invocation vs. messaging) even 
though it does both. If it catches on, you should see a lot more
REST-compatible web-services out there.

More info is at <http://www.wizen.com> or <http://www.netglue.net>.
It's free for developer and personal use.

I've been following the REST discussion and would be interested 
in hearing your thoughts on our approach.

Thanks,
Ramin
---
Ramin Firoozye
Wizen Software. San Francisco, California.
---







-----------------------------------------------------------------------------------
Post ID:1907
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-19 18:21:30
Subject:Re: Order changes and hyperlinks
Message:

Mark Baker wrote:
> Right.  This is old news, isn't it?  

Well, yeah, but who's doing it?
The people who wanted to solve the problem bought i2 etc. for lots of 
money and implementation headaches.
The people on the ws-arch and xml-dev lists assume the links go into 
internal proprietary systems.
The idea of doing it with URI hyperlinks hasn't crossed many people's 
minds - except some of the people on this list, of course, and maybe 
some of the dist-obj gang, although I don't know there.

> The big story is application layer routing.  

Say more?

> You could imagine suppliers subscribed to "demand resources"
> via HTTP WATCH/MONITOR/SUBSCRIBE, etc..

And I do, I do!
http://www.supplychainlinks.com/Rea4scm.htm#REAInAction

Problem at that stage is that I hadn't really grokked REST in total.
(No rash claims now, but it's coming...)

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1908
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-19 18:40:53
Subject:Re: [rest-discuss] Re: Order changes and hyperlinks
Message:

On Fri, Jul 19, 2002 at 06:21:30PM -0000, bhaugen32 wrote:
> Mark Baker wrote:
> > Right.  This is old news, isn't it?  
> 
> Well, yeah, but who's doing it?

KnowNow.

Some of our technology does something similar, but not with that exact
problem domain in mind.  KnowNow's stuff would be off-the-shelf usable
for this, I expect.

> > You could imagine suppliers subscribed to "demand resources"
> > via HTTP WATCH/MONITOR/SUBSCRIBE, etc..
> 
> And I do, I do!

8-)

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1909
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-07-19 18:43:43
Subject:Content-Location and Apache's mod_dir
Message:

As most Web servers do, Apache (through mod_dir) automagically resolves
requests for URIs with trailing slashes to contained resources, usually
index.html.

Shouldn't such responses have a Content-Location in the headers? E.g.,

GET /foo/ HTTP/1.1
Host: www.example.com

--8<--

HTTP/1.1 200 OK
Content-Location: index.html

...

I'm thinking we should get a patch to Apache together... this would make
the relationship between the resources explicit, helping Google, etc. if
they want to take advantage of the info.

Thoughts?

--
Mark Nottingham







-----------------------------------------------------------------------------------
Post ID:1910
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-19 18:57:41
Subject:Re: [rest-discuss] Order changes and hyperlinks
Message:

On 7/19/02 12:10 PM, "bhaugen32" <bhaugen32@...> wrote:

> Thinking more about the recent discussion of order changes on the ws-
> arch mailing list:
> 
> There was a missing dimension to the discussion that points out
> something important about REST:
> Order changes have ripple effects.
> 

That's exactly right.  In fact, a general observation is in order:  the
mechanism by which an operation or change in one part of a system of
interacting components causes operations or changes in another part, and the
combinatorics of those operations or changes changes, is the heart of
software architectural complexity.

My late-night research project over the last year - inspired by discussion
on FoRK and this list - has been an effort to come up with a generic and
formal mathematical framework for characterizing and analyzing this kind of
complexity.  It's nowhere near done yet, but it's been an interesting
endeavor so far.  Current computer science gives us good tools for analyzing
the time and space complexity of algorithms, but no or poor tools for
analyzing software architectural complexity.

My hope is that if this research bears fruit it will provide us with good
tools for that purpose;  my intuition, though I'm not letting it bias the
research, is that generic compositional frameworks (pure functional
composition, UNIX-like dataflow composition, Linda-like coordination
frameworks, REST) are quantifiably "simpler" in various ways than other
compositional frameworks (procedural composition with side-effects,
object-oriented composition.)

$0.02,

Jb







-----------------------------------------------------------------------------------
Post ID:1911
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-19 19:57:50
Subject:Re: GET Query String or POST content? (was Re: [rest-discuss] Amazon & Google & REST)
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

>
> Okay, suppose you had an html form that looked something like:
>
> <form action="http://seairth.com/getinformation">
> <input name="userid" type="text">
> </form>
>
> Now, if I were to submit it using the GET method, you would have a URL
that
> looked like:
>
> http://seairth.com/getinformation?userid=seairth
>
> On the other hand, if I were to submit it using POST, you would have:
>
> http://seairth.com/getinformation
>
> and the content of the message would have:
>
> userid=seairth
>
Good point.
The message with the GET is asking to retrieve the information.
The message with the POST method is asking the server to accept the content
of "userid=seairth" - perhaps to log it, or add it to a list or whatever.
What would happen with a FORM like this?
 <form action="http://seairth.com/getinformation?userid=mike">
 <input name="userid" type="text">
 </form>

You would have a message sent to
 http://seairth.com/getinformation?userid=mike

 and the content of the message would be "userid=seairth"

The message might be asking to add 'seairth' to the contact list for 'mike'.

Many server tools have a problem with this. In Java servlets, you can say
request.getParameter("userid") - but that will automatically pull content
out of the body if the content-type is x-www-form-urlencoded. The problem
comes from the 'getParameter' method talking about a non-existent concept in
HTTP. Things become ambiguous and confusing & programmers end up creating
workarounds that move away from the power and utility of HTTP itself.

For myself, I don't care that HTML browsers do or don't do things with FORM
elements, and I don't care that server tools do or don't make it easy to get
parts of the request. For the 'automatable Web' people will be using their
own clients and talking to more intelligent server tools.








-----------------------------------------------------------------------------------
Post ID:1912
Sender:"rdilipk" <rdilipk@...>
Post Date/Time:2002-07-19 20:05:15
Subject:RESTful implementation of Interop Registry
Message:

http://www.razorsoft.net/weblog/2002/07/19.html#a313

--Dilip








-----------------------------------------------------------------------------------
Post ID:1913
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-19 20:17:53
Subject:Re: [rest-discuss] Content-Location and Apache's mod_dir
Message:

----- Original Message -----
From: "Mark Nottingham" <mnot@...>


> As most Web servers do, Apache (through mod_dir) automagically resolves
> requests for URIs with trailing slashes to contained resources, usually
> index.html.
>
> Shouldn't such responses have a Content-Location in the headers? E.g.,
>
> GET /foo/ HTTP/1.1
> Host: www.example.com
>
> --8<--
>
> HTTP/1.1 200 OK
> Content-Location: index.html
>
> ...
>
> I'm thinking we should get a patch to Apache together... this would make
> the relationship between the resources explicit, helping Google, etc. if
> they want to take advantage of the info.
>

Would the content be returned or would it be a 'redirect'?
Does the 200+"Content-Location" response mean that the entity body returned
is actually more properly accessible via Content-Location value?








-----------------------------------------------------------------------------------
Post ID:1914
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-07-20 02:58:27
Subject:Re: [rest-discuss] Content-Location and Apache's mod_dir
Message:

> Would the content be returned or would it be a 'redirect'?

The content would be returned.

> Does the 200+"Content-Location" response mean that the entity body
returned
> is actually more properly accessible via Content-Location value?

Not more properly accessible; just also available at.

From 2616:

The Content-Location entity-header field MAY be used to supply the
resource location for the entity enclosed in the message when that
entity is accessible from a location separate from the requested
resource's URI.
[...]
The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource
corresponding to this particular entity at the time of the request.
Future requests MAY specify the Content-Location URI as the request-
URI if the desire is to identify the source of that particular
entity.








-----------------------------------------------------------------------------------
Post ID:1915
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-21 00:17:59
Subject:Re: [rest-discuss] URIs, GET, and dynamic resources
Message:

"S. Mike Dierken" wrote:
> 
>...
> Kind of a catch-22 sure, but the 'not change state' constraint has to do
> with the intent of the GET - sending a GET request in order to modify state
> and as the documented mechanism for that resource is what should be avoided.
> 
> The hit-counter problem is a fuzzy area of the 'GET is safe and idempotent'
> requirement, but I don't think the requirement is so constraining that
> hit-counters are not allowed. I believe a resource can be defined in terms
> of the history of that resource and not just some static data values
> somewhere.

I agree. Here is the way I think about it: if you make a POST operation
with side effects and some stupid client calls it a million times, any
side effects are THEIR fault. If you make a GET operation with side
effects and some stupid client calls it a million times, any side
effects are YOUR fault and YOUR problem. If you don't mind a massively
inflated hit counter then go ahead, use GET. If it is important to
maintain an accurate count of intentional client actions, then use POST.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1916
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-21 00:30:10
Subject:Re: [rest-discuss] URIs, GET, and dynamic resources
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>
> "S. Mike Dierken" wrote:
> >
> > Kind of a catch-22 sure, but the 'not change state' constraint has to do
> > with the intent of the GET - sending a GET request in order to modify
state
> > and as the documented mechanism for that resource is what should be
avoided.
> >
> > The hit-counter problem is a fuzzy area of the 'GET is safe and
idempotent'
> > requirement, but I don't think the requirement is so constraining that
> > hit-counters are not allowed. I believe a resource can be defined in
terms
> > of the history of that resource and not just some static data values
> > somewhere.
>
> I agree. Here is the way I think about it: if you make a POST operation
> with side effects and some stupid client calls it a million times, any
> side effects are THEIR fault. If you make a GET operation with side
> effects and some stupid client calls it a million times, any side
> effects are YOUR fault and YOUR problem. If you don't mind a massively
> inflated hit counter then go ahead, use GET. If it is important to
> maintain an accurate count of intentional client actions, then use POST.

So... the difference between GET and POST in terms of "dynamic" resources is
entirely in the intent.  GET say "given this identifier, give me whatever
you've got", while POST says "given this identifier and addtional data, do
whatever you are going to do with it, then give me whatever you've got
afterwards".  Either can return a representation of a resource that changes
with each request, but only POST does this by intent.  Yes?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:1917
Sender:Paul Prescod <paulp@...>
Post Date/Time:2002-07-21 01:06:29
Subject:Re: [rest-discuss] URIs, GET, and dynamic resources
Message:

Seairth Jacobs wrote:
> 
>...
> 
> So... the difference between GET and POST in terms of "dynamic" resources is
> entirely in the intent.  GET say "given this identifier, give me whatever
> you've got", while POST says "given this identifier and addtional data, do
> whatever you are going to do with it, then give me whatever you've got
> afterwards".  Either can return a representation of a resource that changes
> with each request, but only POST does this by intent.  Yes?

That is my understanding, yes. It sounds vaguely bogus to have a
distinction with a primary goal of establishing who is at fault for a
screw-up but then when you think of it, that's the whole point of
standards anyhow. If I leave off quotes in an XML attribute, the other
party and I can both consult the XML specification to determine who is
at fault. Interoperability is achieved when the party at fault
consistently corrects to line up with the party who was correct. Or vice
versa, in which case the "wrong" behaviour becomes a defacto standard.

Wrong behaviours seldom became defacto standards on the real Web because
the browsers kind of enforce a certain level of compliance. If you use
POST to mean GET then you can't use bookmarks. If you use GET to mean
POST then you get users hitting "reload" or "print" and changing your
database. In the XML world we don't have those natural checks so for a
while it was common to use POST to mean GET with SOAP. But XSLT and
other declarative languages serve a similar purpose in the XML world.
Using POST to mean GET destroys compatibility with those languages.

(many Web apps respond the same way to GET and POST but if the HTML
interface only ever advertises one method then the other is effectively
non-existent)
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1918
Sender:Paul Prescod <paulp@...>
Post Date/Time:2002-07-22 19:19:14
Subject:A few thoughts on REST+SOAP
Message:

Sam offers a melded REST+SOAP architecture here:

http://radio.weblogs.com/0101679/stories/2002/07/20/restSoap.html

I am all for using SOAP syntax in REST services where it provides value.
Still, I disagree on some points with the essay.
====

Resources and URIs:
==================
> Start by modeling the persistent resources that you wish to expose.  
> By persistent resources, I am referring to entities that have a 
> typical life expectancy of days or greater.  Ensure that each 
> instance has a unique URL. When possible, assign meaningful 
> names to resources.

I *think* you mean to say that you should also assign URIs to transient
resources. But I'm not sure. Of course I think that transient resources
should have URIs.

Merging Architectures
=====================

You say that your model is different from a resource-centric REST view
in these ways:

1. "POST operations explicitly have the possibility of modifying
multiple resources."

Actually, I would say that PUT and DELETE operations also explicitly
have the possibility of modifying multiple resources. For instance if
you DELETE a Toolkit then the "index" document that refers to the
toolkit should also change. So I do not see this as being an extension
to REST but a core REST concept. None of the lists of REST best
practices I have seen have ever said that operations should only ever
modify a single resource.

Deleting an "account record" will probably also delete all kinds of
related resources. And arguably the deletion could move the resource's
associated data to a "recycle bin" container.

2. "PUT and DELETE operations are rarely used, if ever."

I see no reason for that rule. If what you want to accomplish is
semantically equivalent to a PUT or DELETE then why not use the
standardized method for doing it? I think we need more generic, globally
understood methods, not fewer. That increases interoperability.

I think that this rule follows from the view that a "true" deletion or
update should only change one resource. I do not hold that view so I do
not think that this rule is necessary.

3. "GETs may contain query arguments."

I don't think that anybody ever disputed this. I have made the point on
a few occasions that a service that is query-centric rather than
link-centric is not as discoverable. I can ask Google what it knows
about "Prescod" but I cannot easily get the list of words that co-occurs
with the word REST. In a perfect world with infinite money, Google would
support both modes. I could follow hyperlinks from the page representing
words that co-occur with REST to a page listing words that co-occur with
REST and SOAP etc.

GET with query arguments is fine. Just understand that you lose
discoverability if this is the primary entry point to your resource set.

"If you are encoding parameters on the URL, you are probably making an
RPC request of a service, not retrieving the representation of a
resource."

I disagree.

"It is worth reading Roy Fielding's thoughts on the subject." 
  * http://lists.w3.org/Archives/Public/www-tag/2002Apr/0181.html

I don't see Roy Fielding saying what Sam says about URIs and query
parameters. What *I* think Roy is talking about is services that misuse
POST, not query parameters. Misuse of POST is the most common REST abuse
in my experience.

What SOAP Gives REST
====================

You say that what SOAP adds to REST is stored procedures. I think that
this falls out of the belief that REST-people think that operations
should always only modify one resource. Insofar as a single POST, PUT or
DELETE can have far-reaching effects, each such message is as powerful
as an invocation of a stored procedure. Also, we all speak loosely
sometimes about "SOAP" versus "REST" but now that SOAP is not Web
antaognistic we should be more clear in our terminology. SOAP (the
syntax and messaging framework) does not really add stored procedures to
REST (the architecture). 

Everything is a GET
===================
One other nit, you characterize four different points of view on REST,
SOAP and web services. One of them is "Everything is a get."
Actually, I do not see this as a very common point of view at all. I
rarely run into state-changing GETs and anyone who uses GET in this way
can usually be talked out of it in about five minutes. In other words,
it isn't a "camp" in the debate, AFAIK, it is a simple misunderstanding.

In fact, a much more common misunderstanding than "everything is a GET"
is "everything is a POST". After all, POST is much more "flexible" in
its input and output.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1919
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-22 19:45:35
Subject:MEPs
Message:

I remember reading about Paul's "reduced SOAP" here, but can't find the
message.  In there, he said he took out MEPs, and the reason was that
REST only defines one.

If I understood that correctly, I disagree.  REST doesn't prescribe a
MEP, HTTP does.  But clearly the Web benefitted from having such a
simple MEP to start with since it hid some complexity from developers
(e.g. request/response correlation).  However, that doesn't mean it
requires one.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1920
Sender:Paul Prescod <paulp@...>
Post Date/Time:2002-07-23 16:03:31
Subject:Re: [rest-discuss] MEPs
Message:

Mark Baker wrote:
> 
> I remember reading about Paul's "reduced SOAP" here, but can't find the
> message.  In there, he said he took out MEPs, and the reason was that
> REST only defines one.

No, it was an offlist discussion and the document doesn't mention REST:

http://www.prescod.net/soap/simplesoap

(THAT'S A VERY ROUGH IDEA SO FAR)

For anyone who doesn't know, MEP means "Message Exchange Pattern".

'SOAP 1.2 describes different "message exchange patterns" and even
allows the implementor to invent new ones. SimpleSOAP uses only one
message exchange pattern, request-reply. On top of this you may of
course build asychronous systems like the current mail system if you
wish. Therefore, once you declare you are using SimpleSOAP, there is no
need to also declare what MEP you are using.'

> If I understood that correctly, I disagree.  REST doesn't prescribe a
> MEP, HTTP does.  But clearly the Web benefitted from having such a
> simple MEP to start with since it hid some complexity from developers
> (e.g. request/response correlation).  However, that doesn't mean it
> requires one.

I don't know whether there is really anything we disagree upon. My
opinions on MEP are as follows:

 * request/response is the best choice of primitive MEP for a system
that depends heavily on the results of dereferencing URIs. Plus, today's
Internet topology makes request/response essentially always available
but bidirectional asynch is much harder to roll out. Businesses and ISPs
mostly do not want people outside making connections in, therefore the
only way to get information in is through a response to an outgoing
connection. (with the exception of email, but we know how happy
businesses are with random people sending email to their employees)

 * A highly interoperable system like the Web could have multiple MEPs,
as long as *all server implementations* support all of them. If you must
"configure" your client to contact a server by informing it what MEP to
use then you are starting down a slippery slope that ends in WSDL and
UDDI -- not as options but as requirements for getting actual work done.
This is what I object to in SOAP.

 * Nevertheless, if a system like the Web has only a single MEP, others
can built on top of it. Whether these others are standardized or not is
orthogonal to whether they are primitive. At the very least,
notification should be standardized. Making new MEPs primitive is
probably too difficult at this point.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1921
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-23 16:56:23
Subject:Attention REST promoters
Message:

http://internet.conveyor.com/RESTwiki/moin.cgi/ExplainingRest

A repository for strategies people have used to explain REST.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1922
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-23 16:47:20
Subject:Re: MEPs
Message:

Paul Prescod wrote:
> if a system like the Web has only a single MEP, others
> can built on top of it. Whether these others are standardized or 
not is
> orthogonal to whether they are primitive. At the very least,
> notification should be standardized. 

I think Web business conversation patterns will become standardized, 
too.  Certainly built on top of request-response, probably 
notification, I think much like the Offer-Acceptance whatchamacallit 
we discussed on this list.

Supply chain change propagation, which we discussed more recently, 
could be just a hyperlinked chain of Offer-Acceptance conversations, 
where accepted changes get propagated to dependent links.

In other words, I think REST is a good base for complex MEPs.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1923
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-07-23 16:53:32
Subject:HTTP can't support web services
Message:

A while back, Don Box (of Microsoft) gave a talk in which he stated that
HTTP couldn't support
long-term transactions, one specific reason was because of issues with
intermediaries.
An article about his talk is here:

   http://zdnet.com.com/2100-1105-845220.html

The specific comment from the article is:

"...when Web services start running transactions that take some time to
complete over the protocol, the model fails. "If it takes three minutes for
a response, it is not really HTTP any more," Box said. The problem, said
Box, is that the intermediaries--that is, the companies that own the routers
and cables between the client and server--will not allow single transactions
that take this long."

What exactly is it about the intermediaries that wouldn't allow for a long
transaction time?








-----------------------------------------------------------------------------------
Post ID:1924
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-23 17:13:32
Subject:Re: [rest-discuss] HTTP can't support web services
Message:

On 7/23/02 11:53 AM, "Jeffrey Winter" <j.winter@...> wrote:

> 
> The specific comment from the article is:
> 
> "...when Web services start running transactions that take some time to
> complete over the protocol, the model fails. "If it takes three minutes for
> a response, it is not really HTTP any more," Box said. The problem, said
> Box, is that the intermediaries--that is, the companies that own the routers
> and cables between the client and server--will not allow single transactions
> that take this long."
> 
> What exactly is it about the intermediaries that wouldn't allow for a long
> transaction time?
> 

I'll admit that I'm not a Don Box fan by any stretch of the imagination, but
this comment of his is so obviously braindead wrong that it's embarrassing
even for him.

Who said that a Web services "transaction" needs to fit in a single HTTP
request-response cycle?  Hmm?

Jb







-----------------------------------------------------------------------------------
Post ID:1925
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-07-23 17:35:28
Subject:RE: [rest-discuss] HTTP can't support web services
Message:

Personally, I have never seen this happen and I suspect it's a little bit of
a head-fake. The theory is that a TCP socket opened from client to server,
if inactive for an extended period of time, might be timed out by routers
that are doling out scarce resources. I don't think I've ever seen a
three-minute limit though.

*If* that happens AND you have a (very badly designed) transaction-oriented
web-service, the request will be dropped from the client side before the
server side has had time to respond, so the client might have to reissue the
request again and that will screw up the transaction. Again, I've never seen
this happen and I've never heard of anyone complain about this, but maybe I
don't hang around the right people (:-)

In practice, any reasonable transaction-oriented web-service will have
multiple states, so you could have it go through an 'initialize -> invoke ->
commit' cycle and if it doesn't finish all the way, you don't get the money
deducted from your bank account.

It's a little like saying 'because some web-servers return error 404 they
should not be used for serious purposes.' HTTP is very useful for
web-services. Just about any application that can do HTTP can become a
client. An easy solution to Don's problem is to design proper stateful
web-services (but I'm guessing Don and Microsoft already knew this (;-)

Ramin
---
Ramin Firoozye -  Wizen Software
---
  -----Original Message-----
  From: Jeffrey Winter [mailto:j.winter@...]
  Sent: Tuesday, July 23, 2002 9:54 AM
  To: rest-discuss@yahoogroups.com
  Subject: [rest-discuss] HTTP can't support web services


  A while back, Don Box (of Microsoft) gave a talk in which he stated that
  HTTP couldn't support
  long-term transactions, one specific reason was because of issues with
  intermediaries.
  An article about his talk is here:

     http://zdnet.com.com/2100-1105-845220.html

  The specific comment from the article is:

  "...when Web services start running transactions that take some time to
  complete over the protocol, the model fails. "If it takes three minutes
for
  a response, it is not really HTTP any more," Box said. The problem, said
  Box, is that the intermediaries--that is, the companies that own the
routers
  and cables between the client and server--will not allow single
transactions
  that take this long."

  What exactly is it about the intermediaries that wouldn't allow for a long
  transaction time?



        Yahoo! Groups Sponsor
              ADVERTISEMENT



  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.






-----------------------------------------------------------------------------------
Post ID:1926
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-23 17:49:56
Subject:Re: HTTP can't support web services
Message:

> An easy solution to Don's problem is to design proper stateful
> web-services (but I'm guessing Don and Microsoft already knew this 
(;-)

RosettaNet has a resource-state-alignment transaction model that 
works over the Web.  It is very compatible with REST, as we've 
discussed on this list.

If you know who designed the RNet transaction model, and know where 
they work now, you will have the confirmation of your guess.







-----------------------------------------------------------------------------------
Post ID:1927
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-07-23 19:09:55
Subject:Re: [rest-discuss] HTTP can't support web services
Message:

Don was likely misquoted. It's not* the routers and other lower-layer
infrastructure that will cause problems, it's HTTP application-layer
intermediaries. They're unwilling to keep a persistent connection open for
any period of time, because of the resources that it consumes, and their
sensitivity to performance.

Most common implementations will only keep a connection open for a few
seconds; more radical approaches use an event loop instead of
select()/poll(), enabling them to hold many thousands of connections open,
but they'll still be closed if the workload is high.

While it's true that you can use a separate HTTP connection to get the
response back to the client, this leaves you with a sub-optimal choice; a)
expose an HTTP server on the client, and hope that it is accessible and
addressable (in many of the situations where there is an HTTP
intermediary, this isn't the case), or b) have the client poll the server
for the response. Icky.


* Mostly. Firewalls also have resource limitations, especially if they're
doing NAT.



----- Original Message -----
From: "Ramin Firoozye" <ramin@...>
To: <rest-discuss@yahoogroups.com>
Sent: Tuesday, July 23, 2002 10:35 AM
Subject: RE: [rest-discuss] HTTP can't support web services


> Personally, I have never seen this happen and I suspect it's a little
bit of
> a head-fake. The theory is that a TCP socket opened from client to
server,
> if inactive for an extended period of time, might be timed out by
routers
> that are doling out scarce resources. I don't think I've ever seen a
> three-minute limit though.
>
> *If* that happens AND you have a (very badly designed)
transaction-oriented
> web-service, the request will be dropped from the client side before the
> server side has had time to respond, so the client might have to reissue
the
> request again and that will screw up the transaction. Again, I've never
seen
> this happen and I've never heard of anyone complain about this, but
maybe I
> don't hang around the right people (:-)
>
> In practice, any reasonable transaction-oriented web-service will have
> multiple states, so you could have it go through an 'initialize ->
invoke ->
> commit' cycle and if it doesn't finish all the way, you don't get the
money
> deducted from your bank account.
>
> It's a little like saying 'because some web-servers return error 404
they
> should not be used for serious purposes.' HTTP is very useful for
> web-services. Just about any application that can do HTTP can become a
> client. An easy solution to Don's problem is to design proper stateful
> web-services (but I'm guessing Don and Microsoft already knew this (;-)
>
> Ramin
> ---
> Ramin Firoozye -  Wizen Software
> ---
>   -----Original Message-----
>   From: Jeffrey Winter [mailto:j.winter@...]
>   Sent: Tuesday, July 23, 2002 9:54 AM
>   To: rest-discuss@yahoogroups.com
>   Subject: [rest-discuss] HTTP can't support web services
>
>
>   A while back, Don Box (of Microsoft) gave a talk in which he stated
that
>   HTTP couldn't support
>   long-term transactions, one specific reason was because of issues with
>   intermediaries.
>   An article about his talk is here:
>
>      http://zdnet.com.com/2100-1105-845220.html
>
>   The specific comment from the article is:
>
>   "...when Web services start running transactions that take some time
to
>   complete over the protocol, the model fails. "If it takes three
minutes
> for
>   a response, it is not really HTTP any more," Box said. The problem,
said
>   Box, is that the intermediaries--that is, the companies that own the
> routers
>   and cables between the client and server--will not allow single
> transactions
>   that take this long."
>
>   What exactly is it about the intermediaries that wouldn't allow for a
long
>   transaction time?
>
>
>
>         Yahoo! Groups Sponsor
>               ADVERTISEMENT
>
>
>
>   To unsubscribe from this group, send an email to:
>   rest-discuss-unsubscribe@yahoogroups.com
>
>
>
>   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>







-----------------------------------------------------------------------------------
Post ID:1928
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-23 19:23:10
Subject:URI/identifier creation/ownership
Message:

In REST, are there any rule that govern who has the ability to create
URIs/identifiers?

For instance, if I were to use my web browser to access
http://www.seairth.com/, my browser didn't create the URI; it was already in
existence (and created by the authority/owner of the server to which it
points).  Now, if that request returns an HTML page that has additional URIs
in it (in the form of <a href=''>, for instance), then my browser can use
them.  Again, the browser did not create these URIs.  Now, suppose I submit
one of the returned URIs and get back some more HTML.  This time, the html
contains a form that looks like <form method='get'
action='http://www.seairth.com/scripts/process.cgi'>.  At this point, the
URI given was not created by the browser.  However, this time, when the
browser submits the form, it appends a query to the end of the URI (e.g.
http://www.seairth.com/scripts/process.cgi?id=seairth). According to
statements made on this list, the browser has created a new URI/identifier.
This means that the browser is identifying a different resource than the one
that the server identified.  This is unlike all other URIs it was given or
used.

In terms of REST, is this okay?  Or is this issue delegated to the
application-level (e.g. http in the example above)?  It seems to me that
REST would have something to say about this, but what is it?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:1929
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-07-23 19:38:02
Subject:RE: [rest-discuss] Re: HTTP can't support web services
Message:

By the way, Don is on xml-dev. I suppose we can always ask him what he meant
with that comment (;-)

Ramin
  -----Original Message-----
  From: bhaugen32 [mailto:bhaugen32@...]
  Sent: Tuesday, July 23, 2002 10:50 AM
  To: rest-discuss@yahoogroups.com
  Subject: [rest-discuss] Re: HTTP can't support web services


  > An easy solution to Don's problem is to design proper stateful
  > web-services (but I'm guessing Don and Microsoft already knew this
  (;-)

  RosettaNet has a resource-state-alignment transaction model that
  works over the Web.  It is very compatible with REST, as we've
  discussed on this list.

  If you know who designed the RNet transaction model, and know where
  they work now, you will have the confirmation of your guess.


        Yahoo! Groups Sponsor
              ADVERTISEMENT



  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.






-----------------------------------------------------------------------------------
Post ID:1930
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-07-23 19:55:35
Subject:Re: [rest-discuss] Re: HTTP can't support web services
Message:

I actually did email Box directly this morning and he did respond a moment ago.

To paraphrase him, he said that he was referring to the firewall/proxy infrastructure.  So I suppose that this would be correct.  If a proxy establishes a connection to some server on your behalf, then it would need to maintain information about how to route an HTTP response back to you.  Eventually most proxy servers are going to have to timeout the connection.

In the article he seemed to be talking about routers specifically which don't need to maintain state, just route packets, so I wasn't sure what he was getting at.


I think the article was a bit confusing because there seem to be several issues in play: it's conceivable to construct a service that would have a very long transaction time (such as an "apply for mortgage" service) which might take a day or two to "respond" in some fashion, but Ramin pointed out in an earlier message, to do this under HTTP would require a different mode of thinking through the problem - maybe with a 202 response etc.?  On the other hand, if you just have a poorly written service or one that just have "medium"-scale transaction times, maybe there are other approaches.

Is SOAP designed to handle Very Long Transactions directly, ones that could take on the order of days and not minutes?

- Jeff



----- Original Message ----- 
From: Ramin Firoozye 
To: rest-discuss@yahoogroups.com 
Sent: Tuesday, July 23, 2002 3:38 PM
Subject: RE: [rest-discuss] Re: HTTP can't support web services


By the way, Don is on xml-dev. I suppose we can always ask him what he meant with that comment (;-)

Ramin
  -----Original Message-----
  From: bhaugen32 [mailto:bhaugen32@...]
  Sent: Tuesday, July 23, 2002 10:50 AM
  To: rest-discuss@yahoogroups.com
  Subject: [rest-discuss] Re: HTTP can't support web services


  > An easy solution to Don's problem is to design proper stateful
  > web-services (but I'm guessing Don and Microsoft already knew this 
  (;-)

  RosettaNet has a resource-state-alignment transaction model that 
  works over the Web.  It is very compatible with REST, as we've 
  discussed on this list.

  If you know who designed the RNet transaction model, and know where 
  they work now, you will have the confirmation of your guess.



  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


      Yahoo! Groups Sponsor 
            ADVERTISEMENT
           
     

To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 






-----------------------------------------------------------------------------------
Post ID:1931
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-07-23 20:12:59
Subject:RE: [rest-discuss] Re: HTTP can't support web services
Message:

Hi Jeffrey,

<shameless-plug>
Actually, our product (NetGlue) supports this right now. You can create
'component instances' through a single HTTP or SOAP request. It returns an
'instance-id' back to you. The instance stays alive on the server for as
long as you want it to (and gets the work done). You can then come back
*any* time later, reference the same instance id (through HTTP or SOAP), and
see how it's doing.

The NetGlue client API does this behind the scenes and supports asynchronous
I/O and background thread requests. NetGlue components can be Java, COM,
Perl, HTTP requests, SOAP services, or Javascript so even if the underlying
code doesn't have this ability, they get it for free. We're working on docs
to explain this a little better...

BTW: the software's free for developer and personal use.
</shameless-plug>

Ramin
  I think the article was a bit confusing because there seem to be several
issues in play: it's conceivable to construct a service that would have a
very long transaction time (such as an "apply for mortgage" service) which
might take a day or two to "respond" in some fashion, but Ramin pointed out
in an earlier message, to do this under HTTP would require a different mode
of thinking through the problem - maybe with a 202 response etc.?  On the
other hand, if you just have a poorly written service or one that just have
"medium"-scale transaction times, maybe there are other approaches.

  Is SOAP designed to handle Very Long Transactions directly, ones that
could take on the order of days and not minutes?

  - Jeff






-----------------------------------------------------------------------------------
Post ID:1932
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-07-23 20:15:07
Subject:Re: [rest-discuss] Re: HTTP can't support web services
Message:

> Is SOAP designed to handle Very Long Transactions directly, ones that
could take on the order of days and not minutes.

This was certainly in the design goals, and is very possible with SOAP,
but I don't think that it 'directly' supports them, because to me
supporting 'very long transactions' means asynchronous, or intermittantly
connected, messaging. As such, you'd need a message correlation ID, among
other facilities, which core SOAP doesn't provide, but does leave hooks
for.

SOAP itself doesn't mandate any particular architectural style (unlike
REST, it isn't one), but it does encourage looking at the world in terms
of messages, not state transfers.

Cheers,







-----------------------------------------------------------------------------------
Post ID:1933
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-23 20:21:30
Subject:Re: [rest-discuss] Re: HTTP can't support web services
Message:

On 7/23/02 2:55 PM, "Jeffrey Winter" <j.winter@...> wrote:

> I actually did email Box directly this morning and he did respond a moment
> ago.
>  
> To paraphrase him, he said that he was referring to the firewall/proxy
> infrastructure.  So I suppose that this would be correct.  If a proxy
> establishes a connection to some server on your behalf, then it would need to
> maintain information about how to route an HTTP response back to you.
> Eventually most proxy servers are going to have to timeout the connection.
> 
> ----
> 
> Still  this issue is completely orthogonal to the issue of long-term
> transactions.  Bottom line, end of story.  This is another half-ass Don Box
> swipe at HTTP, an attempt to fool the fools into thinking that theres
> something wrong with HTTP.  Oh, yeah, of course it sucks for transactions,
> because we cant keep a connection open.  Oooh, shit, HTTP sucks!
> 
> I guess that means that e.g. long-duration HTTP sessions, etc. dont work
> either.  Weve been fooling ourselves all this time.
> 
> jb
> 
> PS  if you sense some rancor here, go reread Dons opus.  Theres absolutely
> no doubt at all that hes gunning for HTTP, and theres very little doubt (in
> my mind anyway) why.
> 






-----------------------------------------------------------------------------------
Post ID:1934
Sender:"Mark McEahern" <marklists@...>
Post Date/Time:2002-07-23 20:58:24
Subject:RE: [rest-discuss] Re: HTTP can't support web services
Message:

[Jeff Bone]
> PS � if you sense some rancor here, go reread Don�s opus.
> There�s absolutely no doubt at all that he�s gunning for HTTP,
> and there�s very little doubt (in my mind anyway) why.

Was Cringely right?

  http://www.pbs.org/cringely/pulpit/pulpit20010802.html

// mark

-







-----------------------------------------------------------------------------------
Post ID:1935
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-07-23 21:39:07
Subject:Re: [rest-discuss] Re: HTTP can't support web services
Message:

Re: [rest-discuss] Re: HTTP can't support web services>> Still - this issue
is completely orthogonal to the issue of long-term transactions.  Bottom
line, end of story.  This is another half-ass Don Box swipe at HTTP, an
attempt to fool the fools into thinking that there's something wrong with
HTTP.  "Oh, yeah, of course it sucks for transactions, because we can't keep
a connection open.  Oooh, shit, HTTP sucks!"

>> I guess that means that e.g. long-duration HTTP sessions, etc. don't work
either.  We've been fooling ourselves all this time.

Okay, on this I agree (if I understand your point): there's nothing about
the HTTP protocol per se the rules out long term transactions - and even if
the practical support of the protocol demands that connections time out in
certain configurations (e.g., if you're using a proxy server) there are
patterns of HTTP use that would have the same effect.

I guess my follow up question would be then: are these patterns of use being
codified anywhere by the REST community?

It seems to me one of the reason, among others, why SOAP is gaining traction
is that support for problems like these (e.g., routing, security) are going
through some level of standardization.  See ws-security [1], ws-routing [2].
And are getting built into packages solutions.

By the way, I heard Box say that he thought that ws-routing is one of the
more interesting/important web services specs under development right now.

>> PS - if you sense some rancor here, go reread Don's opus.  There's
absolutely no doubt at all that he's  gunning for HTTP, and there's very
little doubt (in my mind anyway) why.

Well it certainly seems like they'd be happy to gain control of the
interoperability protocols again if that's what you're getting at.

[1] http://msdn.microsoft.com/ws/2002/04/Security/
[2] http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-routing.asp







-----------------------------------------------------------------------------------
Post ID:1936
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-07-23 22:01:12
Subject:RE: [rest-discuss] Re: HTTP can't support web services
Message:

I'm not sure what Don's problem with HTTP is, but if it had been coming from
someone not associated with Microsoft, I'm sure that particular opinion
would have sunk quietly into the briny deep...

When that Cringley piece first came out, I thought he had lost it. Then I
read about 'Palladium' ...

Hoo boy.

Ramin

  -----Original Message-----
  From: Mark McEahern [mailto:marklists@...]
  Sent: Tuesday, July 23, 2002 1:58 PM
  To: rest-discuss@yahoogroups.com
  Subject: RE: [rest-discuss] Re: HTTP can't support web services


  [Jeff Bone]
  > PS � if you sense some rancor here, go reread Don�s opus.
  > There�s absolutely no doubt at all that he�s gunning for HTTP,
  > and there�s very little doubt (in my mind anyway) why.

  Was Cringely right?

    http://www.pbs.org/cringely/pulpit/pulpit20010802.html

  // mark

  -





-----------------------------------------------------------------------------------
Post ID:1937
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-07-23 22:04:42
Subject:RE: [rest-discuss] Re: HTTP can't support web services
Message:

By the way, I heard Box say that he thought that ws-routing is one of the
more interesting/important web services specs under development right now.

>> PS - if you sense some rancor here, go reread Don's opus.  There's
absolutely no doubt at all that he's  gunning for HTTP, and there's very
little doubt (in my mind anyway) why.

Well it certainly seems like they'd be happy to gain control of the
interoperability protocols again if that's what you're getting at.

[1] http://msdn.microsoft.com/ws/2002/04/Security/


Cool, the security spec really works!
I clicked on this link and it told me I don't have permission to read it!
(;-)

Ramin






-----------------------------------------------------------------------------------
Post ID:1938
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-23 22:23:49
Subject:RE: [rest-discuss] Re: HTTP can't support web services
Message:


From: Jeffrey Winter [mailto:j.winter@...] 
>>
Is SOAP designed to handle Very Long Transactions directly, ones that
could take on the order of days and not minutes?
>>

It's not designed not to ;) Seriously, SOAP+HTTP can be used just fine
thanks with something like the ebXML reliable messaging protocol. 

More specifically, HTTP+SMTP are all you need. With a minute's thought
this should be clear to anyone who's ever ordered a book online. There's
no a priori requirement for using a single protocol to get the job done.
SOAP and reliable messaging protocols are good, but they are gravy for a
lot of tasks. 

I heard a rationale espoused recently for a very big messaging system
that a proprietary MOM is a preferable and practical baseline
architecture because there is no webservice-like standard for reliable
messaging. Now, it's my opinion that ex-cathedra pronouncements about
the unsuitability of running highly asynchronous services over the web
will tend to lead you into the arms of messaging vendors. But it's for
each to decide whether that is harm's way or a righteous path.

Bill de hra







-----------------------------------------------------------------------------------
Post ID:1939
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-23 22:57:29
Subject:Re: HTTP can't support web services
Message:

Bill de hra wrote:

> From: Jeffrey Winter [mailto:j.winter@n...] 
> >>
> Is SOAP designed to handle Very Long Transactions directly, ones 
that
> could take on the order of days and not minutes?
> >>
> 
> It's not designed not to ;)
> Seriously, SOAP+HTTP can be used just fine
> thanks with something like the ebXML reliable messaging protocol. 

The ebXML/RosettaNet business transaction protocol can work with 
REST, too.  Check this list for previous discussions about REST 
transactions and state transitions, or Paul Prescod's article:
http://www.prescod.net/rest/state_transition.html
Or this discussion and its links on Rest Wiki, which is still 
incomplete but at least suggestive:
http://internet.conveyor.com/RESTwiki/moin.cgi/StateMachineAsHypertext

In most of these discussions, for long transactions, we used the HTTP 
response as a receipt ack, and a later HTTP interaction for the 
transaction response.

> More specifically, HTTP+SMTP are all you need. With a minute's 
thought
> this should be clear to anyone who's ever ordered a book online. 

Yeah, no kidding...

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1940
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-23 23:00:49
Subject:Re: [rest-discuss] HTTP can't support web services
Message:

----- Original Message -----
From: "Jeffrey Winter" <j.winter@...>

>
> "...when Web services start running transactions that take some time to
> complete over the protocol, the model fails. "If it takes three minutes
for
> a response, it is not really HTTP any more," Box said. The problem, said
> Box, is that the intermediaries--that is, the companies that own the
routers
> and cables between the client and server--will not allow single
transactions
> that take this long."
>
> What exactly is it about the intermediaries that wouldn't allow for a long
> transaction time?
>
DonB is mixing application-level transaction and network-socket-level
connection.
The problem mentioned with intermediaries refers to network socket level
connections.

This whole issue comes up when you map application-level concepts of request
and response to protocol level concepts of request and response.
It becomes worse when you try to do /generic/ requests on top of HTTP which
has specific semantics for each of its request message types.

Long-lived application transactions are definitely doable with HTTP - wish
lists on shopping sites for example - all you have to do is try, and DonB
isn't willing to do that.








-----------------------------------------------------------------------------------
Post ID:1941
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-23 23:16:56
Subject:Re: [rest-discuss] URI/identifier creation/ownership
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

> However, this time, when the
> browser submits the form, it appends a query to the end of the URI (e.g.
> http://www.seairth.com/scripts/process.cgi?id=seairth). According to
> statements made on this list, the browser has created a new
URI/identifier.
> This means that the browser is identifying a different resource than the
one
> that the server identified.  This is unlike all other URIs it was given or
> used.
>
> In terms of REST, is this okay?  Or is this issue delegated to the
> application-level (e.g. http in the example above)?  It seems to me that
> REST would have something to say about this, but what is it?
>
I think this is 'okay' - but that it increases coupling between the systems.
In some cases you may have no choice, but it is nice to know that there is a
simpler more de-coupled approach is available for most cases.

I don't think Roy's paper talks about this directly, but it does talk about
the critical 'loose coupling' that URI opacity provides. The conclusion that
I make from this is that whenever two system coordinate on something which
should be loosely coupled, then you should try to make that area of
coordination loosely coupled as well. In the case of constructing URIs, then
I would interpret that to mean provide an explicit description of the
construction rules.








-----------------------------------------------------------------------------------
Post ID:1942
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-24 00:55:27
Subject:Re: [rest-discuss] URI/identifier creation/ownership
Message:

----- Original Message -----
From: "S. Mike Dierken" <mdierken@...>
>
> I don't think Roy's paper talks about this directly, but it does talk
about
> the critical 'loose coupling' that URI opacity provides. The conclusion
that
> I make from this is that whenever two system coordinate on something which
> should be loosely coupled, then you should try to make that area of
> coordination loosely coupled as well. In the case of constructing URIs,
then
> I would interpret that to mean provide an explicit description of the
> construction rules.

Let me make sure I have this correct.  If a browser were to use a URI as it
was given, then this is loose coupling.  This is due to the fact that the
browser can be entirely brainless and will take whatever it gets.  The URI
is opaque.  On the other hand, if the browser modifies the URI (by adding a
query, for instance), then the particular system is not as loosely coupled
and the URI is no longer considered to be opaque.  This is because the
browser and the server now have to agree on a "standard" modification
practice (e.g. "?" plus a URL-encoded string where each field is separated
by a "&" and each name is separated by it's associated value with a "="),
which effectively binds them together.

The more loosely coupled the system is, the more RESTlike it is (ignoring
all other issues).

If this is the case, then does it make sense to always use POST in an html
form, regardless of whether the actual request is idempotent (and therefore
could be handled with a GET) or not?  POST would treat the URI as opaque,
whereas the GET would not.  POST would be more loosely coupled than GET.

Frankly, I agree with this view.  Quite coincidentally, I follow this this
practice in my web applications.  The only way a URL contains a query string
is if the server created it.  As far as the browser is concerned, the URL is
entirely opaque.  What would people who say that POST is often misused say
about this? (I can already imagine...)

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:1943
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-24 03:23:47
Subject:Re: [rest-discuss] URI/identifier creation/ownership
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

>
> The more loosely coupled the system is, the more RESTlike it is (ignoring
> all other issues).
No, the more RESTlike a system is, the more RESTlike it is. You have to
measure against the components identified by the REST architectural style
(client, gateway, origin server, intermediary, stateless messages,
resources/representations, etc. etc.) to be RESTlike.

>
> If this is the case, then does it make sense to always use POST in an html
> form, regardless of whether the actual request is idempotent (and
therefore
> could be handled with a GET) or not?
GET .vs. POST isn't about idempotent or not, its about read .vs. write.

> POST would treat the URI as opaque,
> whereas the GET would not.  POST would be more loosely coupled than GET.
POST treats the URI as opaque, but if the resource you want to interact with
is identified by URI+message.body then you have very tight coupling going
on.
If you /did/ use POST all the time - then you lose the addressability
aspect, since servers and clients need to know both URI + body in order to
do a retrieval (and you'd need yet another piece to indicate that POST isn't
trying to modify, its trying to read).

In a Web browser the content of the POST is constructed according to similar
rules as the URL.
This also results in coupling between server and client - but it is easier
to manage, since the submitted content (the message body) has a declared
type identified by the Content-Type header in the request. And it isn't
/required/ to be "application/x-www-form-urlencoded" you can POST text/xml
or image/jpg or whatever you want .

The POST and GET are values exposed in HTTP messages in order to allow at
least a minimal amount of processing on /any/ message encountered by any
component.


>
> Frankly, I agree with this view.  Quite coincidentally, I follow this this
> practice in my web applications.  The only way a URL contains a query
string
> is if the server created it.  As far as the browser is concerned, the URL
is
> entirely opaque.  What would people who say that POST is often misused say
> about this? (I can already imagine...)
It's a better system that keeps URI construction close to the origin server.
How do you provide discovery of URIs for resources that are logically
related to resources on other systems?
For example, if I have the UPC code for a pair of tennis shoes, and you have
tennis shoes for sale, how do I learn what your URI is for that particular
shoe?








-----------------------------------------------------------------------------------
Post ID:1944
Sender:"Mark McEahern" <marklists@...>
Post Date/Time:2002-07-24 12:10:46
Subject:RE: [rest-discuss] HTTP can't support web services
Message:

["Jeffrey Winter"]
> Long-lived application transactions are definitely doable with HTTP - wish
> lists on shopping sites for example - all you have to do is try, and DonB
> isn't willing to do that.

Is Box saying that the problem with doing long-lived application
transactions over HTTP that there is no standard, canonical way to do it?
Or is he saying it's technically impossible?

Even if he isn't saying the former, is it true?  If so, are there efforts to
standardize these things?

// mark

-







-----------------------------------------------------------------------------------
Post ID:1945
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-07-24 12:25:18
Subject:Re: [rest-discuss] HTTP can't support web services
Message:

Mike Dierken wrote:
> DonB is mixing application-level transaction and network-socket-level
> connection. The problem mentioned with intermediaries refers to network
> socket level connections.

Per the recent conversation on socket-level aspects of HTTP, it strikes me
that they are deliberately not a part of the protocol.  There are actually
two protocols, an application-level protocol defined by the HTTP RFCs and
a socket-level protocol defined by standard practice.  Don Box's comment
refers to the socket-level protocol.

At the same time, limited duration of connections is a deliberate part of
the REST architectural style.  It is expected that HTTP is mainly used for
hypertext documents, not messages, and it is reasonable for proxies to
assume that well-behaved connections will be short lived.

Short lived connections follow from stateless transactions, and stateless
transactions follow from HTTP's scalability requirements.  HTTP web
services should be architected to avoid the need for long lived streams
because long lived streams expend too many server resources.  Web
applications that need long lived streams imply a less scalable web!

- Lucas








-----------------------------------------------------------------------------------
Post ID:1946
Sender:Serdar Kilic <serdar@...>
Post Date/Time:2002-07-24 12:36:43
Subject:Re: [rest-discuss] Re: HTTP can't support web services
Message:

Try:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp

-- 
Kind Regards,
 Serdar K.

Ramin, said:

RF> Cool, the security spec really works!
RF> I clicked on this link and it told me I don't have permission to read it!
RF> (;-)







-----------------------------------------------------------------------------------
Post ID:1947
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-07-24 12:31:49
Subject:RE: [rest-discuss] HTTP can't support web services
Message:

On Wed, 24 Jul 2002, Mark McEahern wrote:
> Is Box saying that the problem with doing long-lived application
> transactions over HTTP that there is no standard, canonical way to do it?
> Or is he saying it's technically impossible?
> 
> Even if he isn't saying the former, is it true?  If so, are there efforts to
> standardize these things?

I think he's referring to the unreliability of HTTP streams, specifically 
the fact that proxies are free to cut off streams that last too long.

The canonical approach, I think, is to keep streams and transactions
orthogonal.  A persistent stream has to be considered a convenience, and
not be used as required support to maintain transaction state.

- Lucas










-----------------------------------------------------------------------------------
Post ID:1948
Sender:"John Evdemon" <jevdemon@...>
Post Date/Time:2002-07-24 12:42:40
Subject:FYI - ACM's Transactions on Internet Technology
Message:

I just received the latest issue in the mail - it includes a paper from Fielding and Taylor entitled "Principled Design of Modern Web Architecture".  

Seems to be an overview of REST principles, illustrating how other network-based architectural styles (client-server, virtual machine, etc) are merged to form a REST 
architectural style.






-----------------------------------------------------------------------------------
Post ID:1949
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-07-24 12:40:23
Subject:Re: [rest-discuss] HTTP can't support web services
Message:

On Tue, 23 Jul 2002, Jeff Bone wrote:
> I'll admit that I'm not a Don Box fan by any stretch of the imagination, but
> this comment of his is so obviously braindead wrong that it's embarrassing
> even for him.

He's really setting himself up as an apologist for SOAP-RPC.  There are
probably other technical arguments against HTTP that are cluesome -- too
bad he's not finding them.

In my experience as a REST acolyte the biggest lesson I've learned is that
you can't go around HTTP, you have to go through it.  All new protocols
that fail to understand why HTTP works will ultimately fail to add
anything new on an architectural level.









-----------------------------------------------------------------------------------
Post ID:1950
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-24 14:40:32
Subject:Re: [rest-discuss] FYI - ACM's Transactions on Internet Technology
Message:

Yah, Roy said he updated it recently.  An older version is referenced
from the RestResources page on the REST Wiki.

MB

On Wed, Jul 24, 2002 at 08:42:40AM -0400, John Evdemon wrote:
> I just received the latest issue in the mail - it includes a paper from Fielding and Taylor entitled "Principled Design of Modern Web Architecture".  
> 
> Seems to be an overview of REST principles, illustrating how other network-based architectural styles (client-server, virtual machine, etc) are merged to form a REST 
> architectural style.
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 

-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1951
Sender:lucas@...
Post Date/Time:2002-07-24 16:37:33
Subject:xoomle
Message:

So close and yet so far:
http://www.dentedreality.com.au/xoomle/docs/

http://xoomle.dentedreality.com.au/?key=YourGoogleDeveloperKey&method=doGoogleSearch&q=dented+reality
==> method=doGoogleSearch.










-----------------------------------------------------------------------------------
Post ID:1952
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-24 17:31:03
Subject:Clarification on REST, GET and CGI
Message:

David Orchard wrote:
> 
> ....  To compare, if I were to document REST as it is
> done today, I'd probably ignore HTTP PUT/DELETE and I'd say that GET/POST
> can be used interchangeably except for some bookmarking applications where
> GET is a little better.  

That's a severe misrepresentation of the way the Web is used today. GET
is used whenever safe references are important. Bookmarking is a tiny
example. I can send you this link because of GET:

http://search.bea.com/query.html?qt=REST

I didn't bookmark it and probably you won't either. That fact that I can
email it to you -- communicate it to you -- is what is important. You
can interoperably, using any Web client, anywhere in the world,
dereference that link. Bookmarking is a side effect of that general
improvement in interoperability. I am confident that BEA's web designers
understand this issue because they work with these safe information
references ("hyperlinks") all day.

> ... And I'd say that CGIs are great.  

CGIs *can be* great. I may be wrong, but I think that you're
interpreting something from this mail by Roy Fielding. I've seen this
post misinterpreted (IMO) in other places so I'm going to address it
once and for all.

 * http://lists.w3.org/Archives/Public/www-tag/2002Apr/0181.html

Note the last sentence: 'The fact of the matter is that
most CGI scripts are not HTTP compliant.  Most CGI scripts, in fact,
provide interfaces to applications that suck. The "G" stands for
Gateway.
What people should realize is not that "CGI scripts should be banned",
but rather that if the CGI script is written such that it behaves
like a proper Web interface, then it won't suck.'

CGI is a *gateway* interface. You can either use it to just publish some
functionality through a URL (tunnelling) or you can use it to build a
proper gateway between your software and the Web: URIs for all
resources, hyperlinks as the engine of application state, etc. Some of
the most REST-ful applications in the world are CGI and many of the
least are not.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1953
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-24 18:38:30
Subject:Xoomle review
Message:

Xoomle is really cool!

Here are some of my ideas for improvement in order of importance.

* Rather than "method=", I'd say that there should be three top-level
URIs. Among reasons this is better in theory, it is easier to build HTML
forms that have different ACTION= attributes. This is the only thing
that would stop the REST community from using XooMLe as a perfect case
study. It's a tiny thing to change but sort of goes to the heart of REST
philosophy. Priority = 8 out of 10.

* I'd suggest that the key should be passed using HTTP authentication
(at least as an option). Then developers could share references without
sharing their keys. As I recall, if you really want, you can embed HTTP
authentication information in URIs *anyhow*. Priority = 7/10

* <?xml-stylesheet?> could be used to provide a nice HTML-based
rendition. I would be happy to provide this XSLT stylesheet. Priority =
6/10

* I'd use a namespace on the returned XML (with default prefix) so that
it is a little easier to associate namespace-triggered behaviour with
the XML. It would just take one attribute value to be "namespace aware".
6/10

 * It would be great if you would publish a schema. I believe there is
one embedded in Google's WSDL but you could extract that modulo
copyright issues. You could also use a schemaLocation attribute to point
to it. 6/10

 * <url>...</url> could become <url xlink:href="...">...</url>. I have
mixed feelings about XLink but it *is* the standard way to do linking in
XML. More or less this will endear you to people who have developed
XLink processors. 5/10

 * You could build on the way HTTP/REST works to add some interesting
features. 

 1. For instance you could embed a link to the cached page in each item: 
    <URL>http://www.cse.unsw.edu.au/~norman/</URL> 
   
<cached>http://xooomle..../cached?url="http://www.cse.unsw.edu.au/~norman/"</cached>

 2. You could have a link from each page that is a "sub-query". So let's
say I send you a link like
"http://.../?hl=en&ie=ISO-8859-1&method=doGoogleSearch&q=Paul", it would
embed within it a link like this:

    * <subquery
xlink:href="http://.../doGoogleSearch/hl=en&ie=ISO-8859-1&method=doGoogleSearch&q=Paul/"/>

Then I could do a *subquery* just by appending "?q=Prescod". By subquery
I mean that it would be interpreted as the same as "Paul+Prescod". This
somewhat goes back to the first issue: you need a way for the method to
be part of the path, not part of the query, but you also need a way for
a representation for the "query" to be part of the path. Once it is
moved into the path it is opaque so it doesn't matter if you use some
compression scheme or something:

 * <subquery
xlink:href="http://.../doGoogleSearch/fj4fjefe0fa9e8w09i03fj/"/>

====

Now that you can think of the Google database as a set of resources,
you'll find that there are a bunch of ideas like this where we can do
interesting things by associating these resources.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1954
Sender:"nixerman" <nixerman@...>
Post Date/Time:2002-07-24 20:53:09
Subject:Re: Xoomle review
Message:

I am very interested in the subquery idea. I am working on something 
similar. PPrescond mentioned three top level urls to expose the 
different functionality like spellchecking and searches and I'd 
definitely agree. Something like:

http://xoomle.../searches/Paul+Prescond

would be very nice. You might imagine a folder on a hard drive 
called 'searches' and in this folder is a 'file' corresponding to 
every conceivable Google search. It would be nice to be able to 
search this folder--that is search searches. Especially if 
information can be stored about searches indicating how successful 
they are. (Find me searches containing the word Prescond where the 
last time the search was performed X condition was met). This makes 
no sense, but that's okay.

I just like the idea of making every search a real URL and being able 
to dynamically extend a search by appending to a URL. Keep up the 
good work.

- codaland @ http://codaland.blogspot.com

--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
> Xoomle is really cool!
> 
> Here are some of my ideas for improvement in order of importance.
> 
> * Rather than "method=", I'd say that there should be three top-
level
> URIs. Among reasons this is better in theory, it is easier to build 
HTML
> forms that have different ACTION= attributes. This is the only thing
> that would stop the REST community from using XooMLe as a perfect 
case
> study. It's a tiny thing to change but sort of goes to the heart of 
REST
> philosophy. Priority = 8 out of 10.
> 
> * I'd suggest that the key should be passed using HTTP 
authentication
> (at least as an option). Then developers could share references 
without
> sharing their keys. As I recall, if you really want, you can embed 
HTTP
> authentication information in URIs *anyhow*. Priority = 7/10
> 
> * <?xml-stylesheet?> could be used to provide a nice HTML-based
> rendition. I would be happy to provide this XSLT stylesheet. 
Priority =
> 6/10
> 
> * I'd use a namespace on the returned XML (with default prefix) so 
that
> it is a little easier to associate namespace-triggered behaviour 
with
> the XML. It would just take one attribute value to be "namespace 
aware".
> 6/10
> 
>  * It would be great if you would publish a schema. I believe there 
is
> one embedded in Google's WSDL but you could extract that modulo
> copyright issues. You could also use a schemaLocation attribute to 
point
> to it. 6/10
> 
>  * <url>...</url> could become <url xlink:href="...">...</url>. I 
have
> mixed feelings about XLink but it *is* the standard way to do 
linking in
> XML. More or less this will endear you to people who have developed
> XLink processors. 5/10
> 
>  * You could build on the way HTTP/REST works to add some 
interesting
> features. 
> 
>  1. For instance you could embed a link to the cached page in each 
item: 
>     <URL>http://www.cse.unsw.edu.au/~norman/</URL> 
>    
> <cached>http://xooomle..../cached?
url="http://www.cse.unsw.edu.au/~norman/"</cached>
> 
>  2. You could have a link from each page that is a "sub-query". So 
let's
> say I send you a link like
> "http://.../?hl=en&ie=ISO-8859-1&method=doGoogleSearch&q=Paul", it 
would
> embed within it a link like this:
> 
>     * <subquery
> xlink:href="http://.../doGoogleSearch/hl=en&ie=ISO-8859-
1&method=doGoogleSearch&q=Paul/"/>
> 
> Then I could do a *subquery* just by appending "?q=Prescod". By 
subquery
> I mean that it would be interpreted as the same as "Paul+Prescod". 
This
> somewhat goes back to the first issue: you need a way for the 
method to
> be part of the path, not part of the query, but you also need a way 
for
> a representation for the "query" to be part of the path. Once it is
> moved into the path it is opaque so it doesn't matter if you use 
some
> compression scheme or something:
> 
>  * <subquery
> xlink:href="http://.../doGoogleSearch/fj4fjefe0fa9e8w09i03fj/"/>
> 
> ====
> 
> Now that you can think of the Google database as a set of resources,
> you'll find that there are a bunch of ideas like this where we can 
do
> interesting things by associating these resources.
> -- 
> Come discuss XML and REST web services at:
>   Open Source Conference: July 22-26, 2002, 
conferences.oreillynet.com
>   Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/







-----------------------------------------------------------------------------------
Post ID:1955
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-24 21:50:14
Subject:Re: [rest-discuss] HTTP can't support web services
Message:

----- Original Message -----
From: "Mark McEahern" <marklists@...>

>
> Even if he isn't saying the former, is it true?  If so, are there efforts
to
> standardize these things?

There is something called AS2 which is a 'standard' mechanism for exchanging
busines documents with MIME over HTTP. AS1 is MIME over SMTP. I haven't
spent much time examining AS2 - perhaps BobH can fill us in - but it looks
like a protocol on top of HTTP. It probably can be easily re-factored into a
more REST-like approach, but until I get paid to do that sort of thing, I
don't have the time right now to attempt that...

http://www.uc-council.org/news/ne_081401.html








-----------------------------------------------------------------------------------
Post ID:1956
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-24 14:24:11
Subject:Re: [rest-discuss] URI/identifier creation/ownership
Message:

Seairth Jacobs wrote:
> 
>...
> 
> In terms of REST, is this okay?  Or is this issue delegated to the
> application-level (e.g. http in the example above)?  It seems to me that
> REST would have something to say about this, but what is it?

This is related to the ongoing debate on opaque URIs. I think that the
rough concensus is that this is okay but you lose some benefits of the
Web if you rely on it too heavily. In particular, hyperlinks are great
because they are discoverable. Query parameters require a little more a
priori knowledge of how to construct the query values. On the other
hand, rendering everything as hyperlinks can be unacceptably inefficient
sometimes. For instance, to find the kinkos in a particular zip code,
you could either use a query parameter or build a big hypertext document
that associates zip codes with documents. The former is better from a
performance point of view. The latter is better from a discovery and
"semantic web" point of view. Given sufficient time and money, I would
suggest you do both. Otherwise, just weigh the costs and benefits and do
what makes sense.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/








-----------------------------------------------------------------------------------
Post ID:1957
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-24 22:05:12
Subject:Re: [rest-discuss] HTTP can't support web services
Message:

----- Original Message -----
From: "Lucas Gonze" <lucas@...>
>
> Short lived connections follow from stateless transactions, and stateless
> transactions follow from HTTP's scalability requirements.
I don't believe that stateless transactions imply short lived connections.
Short lived connections are allowable as a resource saving optimization
without impacting the logic of the application sending the messages.

Stateless transactions allow you to do multiple request/response on a single
network connection - without being stateless, the protocol designer might be
tempted on associated security credentials with the socket connection, which
prevents that resource being used by multiple users at once (I think IMAP
has a problem like this, where you have to close the socket & reopen it to
view a different inbox).

> HTTP web
> services should be architected to avoid the need for long lived streams
> because long lived streams expend too many server resources.  Web
> applications that need long lived streams imply a less scalable web!
I sort of agree - apps that just won't work without long-lived streams are
going to suffer, but allowing long-lived streams is a nice optimization that
improves scalability (from a performance point of view).







-----------------------------------------------------------------------------------
Post ID:1958
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-24 22:12:34
Subject:Re: [rest-discuss] Re: Xoomle review
Message:

----- Original Message -----
From: "nixerman" <nixerman@...>
To: <rest-discuss@yahoogroups.com>
Sent: Wednesday, July 24, 2002 1:53 PM
Subject: [rest-discuss] Re: Xoomle review


>
> I am very interested in the subquery idea. I am working on something
> similar. PPrescond mentioned three top level urls to expose the
> different functionality like spellchecking and searches and I'd
> definitely agree. Something like:
>
> http://xoomle.../searches/Paul+Prescond
>

You'd probably want to use %20 rather than '+' if it is part of a path
segment (if you mean that the '+' is a space character).







-----------------------------------------------------------------------------------
Post ID:1959
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-07-24 22:10:03
Subject:Re: [rest-discuss] HTTP can't support web services
Message:

me:
> > services should be architected to avoid the need for long lived streams
> > because long lived streams expend too many server resources.  Web

Mike Dierken:
> > applications that need long lived streams imply a less scalable web!
> I sort of agree - apps that just won't work without long-lived streams are
> going to suffer, but allowing long-lived streams is a nice optimization that
> improves scalability (from a performance point of view).

Interesting.  Don't know if my interpretation of Roy's thesis(*) is right
then.  My reading was that 'scalability' meant the quantity of clients
that a single server can handle.

- Lucas

(*) Can't this get another name by now?  This one is awkward.  I don't
know Roy, so I don't like saying "Roy's thesis" with a first name, but
"Roy Fielding's thesis" is too formal, and quoting the whole title makes
no sense, and "The Thesis" is funny but too biblical.  Also, I think that
attributing REST purely to the thesis is wrong -- the idea is really a
group invention of the HTTP 1.1 drafters.











-----------------------------------------------------------------------------------
Post ID:1960
Sender:"David Orchard" <dorchard@...>
Post Date/Time:2002-07-24 22:45:56
Subject:RE: Clarification on REST, GET and CGI
Message:

Paul,

You didn't refute my point at all, which is that REST is not used
appropriately in many ways on the web but we don't document all the
inappropriate usages in the web architecture document and Roy's thesis.  We
still can talk about the architectural principles that the web embodies, as
described by REST.  Mark is proposing that the w3c web services group should
only document those architectures that have running code, and it should
document all the usages.  And he's specifically pointing out areas where
SOAP is used in different ways that he finds "sucky".  If the criteria is
running code, I would argue that a web architecture (aka REST) description
would include all the inappropriate uses.  And the "running code criteria"
precludes things like SOAP 1.2 which don't have much running code yet.  So
the running code criteria doesn't seem useful to specify architectures to
help people build better web/web services systems and standards.

So it's my opinion that the w3c web services architecture group should spend
some of it's time working on web services architectural principles, not
simply documenting what current systems do.  And the same goes for the TAG
wrt web principles.

Just because I mention REST usage (the generic method usage) and CGI usage
does not mean I want a REST vs whatever discussion.  In fact, I'm utterly
and completely exhausted by that particular topic area.  Roy's quote is the
reason why I mentioned CGI and I think his quote supports the notion that
some running code "sucks".  And I again assert that w3c groups shouldn't
document the sucky usages in our architecture documents, except perhaps as
being sucky.  But again again again, this is not a REST discussion per se.

I don't intend to follow through much more with this discussion about what
the group is going to do.  I'm more interested in writing up text to
describe the architecture and discussing the text of such.  "Do stuff rather
than talk about doing stuff".

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@... [mailto:www-ws-arch-request@...]On
> Behalf Of Paul Prescod
> Sent: Wednesday, July 24, 2002 10:31 AM
> To: David Orchard
> Cc: 'Mark Baker'; www-ws-arch@...; rest-discuss@yahoogroups.com;
> fielding@...
> Subject: Clarification on REST, GET and CGI
>
>
>
> David Orchard wrote:
> >
> > ....  To compare, if I were to document REST as it is
> > done today, I'd probably ignore HTTP PUT/DELETE and I'd say
> that GET/POST
> > can be used interchangeably except for some bookmarking
> applications where
> > GET is a little better.
>
> That's a severe misrepresentation of the way the Web is used
> today. GET
> is used whenever safe references are important. Bookmarking is a tiny
> example. I can send you this link because of GET:
>
> http://search.bea.com/query.html?qt=REST
>
> I didn't bookmark it and probably you won't either. That fact
> that I can
> email it to you -- communicate it to you -- is what is important. You
> can interoperably, using any Web client, anywhere in the world,
> dereference that link. Bookmarking is a side effect of that general
> improvement in interoperability. I am confident that BEA's
> web designers
> understand this issue because they work with these safe information
> references ("hyperlinks") all day.
>
> > ... And I'd say that CGIs are great.
>
> CGIs *can be* great. I may be wrong, but I think that you're
> interpreting something from this mail by Roy Fielding. I've seen this
> post misinterpreted (IMO) in other places so I'm going to address it
> once and for all.
>
>  * http://lists.w3.org/Archives/Public/www-tag/2002Apr/0181.html
>
> Note the last sentence: 'The fact of the matter is that
> most CGI scripts are not HTTP compliant.  Most CGI scripts, in fact,
> provide interfaces to applications that suck. The "G" stands for
> Gateway.
> What people should realize is not that "CGI scripts should be banned",
> but rather that if the CGI script is written such that it behaves
> like a proper Web interface, then it won't suck.'
>
> CGI is a *gateway* interface. You can either use it to just
> publish some
> functionality through a URL (tunnelling) or you can use it to build a
> proper gateway between your software and the Web: URIs for all
> resources, hyperlinks as the engine of application state, etc. Some of
> the most REST-ful applications in the world are CGI and many of the
> least are not.
> --
> Come discuss XML and REST web services at:
>   Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
>   Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/
>
>







-----------------------------------------------------------------------------------
Post ID:1961
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-07-24 23:05:10
Subject:REST, UML and MDA
Message:

Not having picked up a copy of Software Development magazine for a while, I
recently stumbled across David Carlson's series of articles on 'Modeling XML
Applications with UML' [1]. From there I read more on MDA [2], [3] and
additional papers by Carlson [4] as well as the OMG's release of the EDOCS
(Enterprise Distributed Object Computing) UML profile [5] which, as is
mentioned below is undergoing a platform specific mapping (PSM) to Web
Services. This got my interest and I wondered if it might be worth looking
into further from the perspective of using a REST approach as a PSM. So
before I get too carried away I thought I would ask for the groups input on 
this,
has anyone with a deeper understanding of MDA/EDOC/etc had thoughts
along these lines?

Robert

PS Sometimes I wish Fielding had coined a name other than REST, as it makes
Google searching somewhat more difficult!

[1] http://www.sdmagazine.com/documents/sdm0202f/ (registration required) or
the Feb, Apr, May Jun 2002 issues of SD

[2] MDA home page - http://www.omg.org/mda

[3] Model Driven Architecture - A Technical Perspective -
http://www.omg.org/cgi-bin/doc?ormsc/01-07-01.pdf

[4] http://www.xmlmodeling.com/articles/

[5] http://www.omg.org/cgi-bin/doc?ptc/02-02-05.pdf (The UML Profile for
EDOC is used to build PIMs (Platform Independent  Model) of enterprise
applications. It defines representations for entities, events, process,
relationships, patterns, and an Enterprise Collaboration Architecture. As a
PIM profile, it needs mappings to platform-specific profiles. A mapping to
Web Services is underway now; additional mappings will follow. )







-----------------------------------------------------------------------------------
Post ID:1962
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-25 03:41:10
Subject:Re: [rest-discuss] MEPs
Message:

On Tue, Jul 23, 2002 at 09:03:31AM -0700, Paul Prescod wrote:
> No, it was an offlist discussion and the document doesn't mention REST:

Eek, sorry.  That explains why I couldn't find it in my rest-discuss
folder. 8-)

> I don't know whether there is really anything we disagree upon. My
> opinions on MEP are as follows:

Yah, we're in agreement.  Just a couple of observations ...

>  * request/response is the best choice of primitive MEP for a system
> that depends heavily on the results of dereferencing URIs. Plus, today's
> Internet topology makes request/response essentially always available
> but bidirectional asynch is much harder to roll out. Businesses and ISPs
> mostly do not want people outside making connections in, therefore the
> only way to get information in is through a response to an outgoing
> connection. (with the exception of email, but we know how happy
> businesses are with random people sending email to their employees)

Maybe just a terminology issue, but I don't know that anybody's
questioning request/response.  All messages can be characterized as one
of those.  I think the simplicity you're referring to, has to do with
the implicit correlation of requests and responses by virtue of them
reusing the same connection, and that each request has a single
response.  I concur with that.

>  * A highly interoperable system like the Web could have multiple MEPs,
> as long as *all server implementations* support all of them. If you must
> "configure" your client to contact a server by informing it what MEP to
> use then you are starting down a slippery slope that ends in WSDL and
> UDDI -- not as options but as requirements for getting actual work done.
> This is what I object to in SOAP.

MEPs don't do anything except describe ways in which the underlying
protocol can be used.  So there's no issue of extended agreement, since
by virtue of using a protocol, you already know what needs to be known
in order to support any MEP that fits.

This isn't quite as straightforward as it sounds.  For example, one
could built a multicast MEP with HTTP.  Obviously HTTP doesn't support
that by itself, but by using a URI to identify a multicast group, then
defining what the HTTP methods should do on it (e.g. GET blocks until
all members of the group have responded, then returns a multipart
message/http envelope - or whatever), you have built something new that
can be deployed without new agreement.

>  * Nevertheless, if a system like the Web has only a single MEP, others
> can built on top of it. Whether these others are standardized or not is
> orthogonal to whether they are primitive. At the very least,
> notification should be standardized. Making new MEPs primitive is
> probably too difficult at this point.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1963
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-25 03:45:59
Subject:Re: [rest-discuss] Content-Location and Apache's mod_dir
Message:

On Fri, Jul 19, 2002 at 11:43:43AM -0700, Mark Nottingham wrote:
> I'm thinking we should get a patch to Apache together... this would make
> the relationship between the resources explicit, helping Google, etc. if
> they want to take advantage of the info.
> 
> Thoughts?

Yah, for sure.  Let me know how I can help.  I'd love to learn how to
develop an Apache module.  I've got other ideas for them too.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1964
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-25 04:13:25
Subject:Re: [rest-discuss] RE: Clarification on REST, GET and CGI
Message:

David Orchard wrote:
> 
> Paul,
> 
> You didn't refute my point at all, which is that REST is not used
> appropriately in many ways on the web but we don't document all the
> inappropriate usages in the web architecture document and Roy's thesis.  

I didn't intend to refute your point. I wanted to correct a persistent
misinterpretation that Roy Fielding said something against CGI or
against "excessive gatewaying". Hopefully he'll correct me if I'm wrong
but I think that his opinion is that gatewaying (CGI or whatever) is the
right way to integrate non-Web systems with the Web and is a core part
of web architecture. You have repeatedly cited that message in a manner
I believe to be incorrect and I felt it was necessary to inform you (no
matter what the topic of discussion).
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1965
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-25 04:42:13
Subject:Re: [rest-discuss] HTTP can't support web services
Message:

----- Original Message -----
From: "Lucas Gonze" <lucas@...>
>
> Interesting.  Don't know if my interpretation of Roy's thesis(*) is right
> then.  My reading was that 'scalability' meant the quantity of clients
> that a single server can handle.

For me - and this isn't directly reflecting the wording in The Thesis (tm) -
scalability has technology aspects and social/organizational aspects. Pure
performance, number of clients or 'participating nodes', amount of data,
differing data types, etc. are some of the technical scalability areas,
whereas the number of organizational domains that can participate in another
aspect of scalability.

Anyway... as long as multiple messages on one connection is a performance
enhancement, rather than a requirement for basic functionality, I'm not too
worried about it.

As a note - which you are probably familiar with - it's not too difficult to
get on the order of 10K concurrent connections on a good size machine. This
isn't the same as 10K full-bore, saturated data streams, but it is a
boundary condition to be aware of.






-----------------------------------------------------------------------------------
Post ID:1966
Sender:"David Orchard" <dorchard@...>
Post Date/Time:2002-07-25 04:49:47
Subject:RE: [rest-discuss] RE: Clarification on REST, GET and CGI
Message:

hmm.  Roy said that many CGI scripts suck because they don't implement REST
properly.  Don't think I'm misquoting him.  I'm pointing out that we don't
look at the sucky CGI scripts when determine web architecture because, well,
they suck.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@... [mailto:www-ws-arch-request@...]On
> Behalf Of Paul Prescod
> Sent: Wednesday, July 24, 2002 9:13 PM
> To: David Orchard
> Cc: www-ws-arch@...; rest-discuss@yahoogroups.com;
> fielding@...
> Subject: Re: [rest-discuss] RE: Clarification on REST, GET and CGI
>
>
>
> David Orchard wrote:
> >
> > Paul,
> >
> > You didn't refute my point at all, which is that REST is not used
> > appropriately in many ways on the web but we don't document all the
> > inappropriate usages in the web architecture document and
> Roy's thesis.
>
> I didn't intend to refute your point. I wanted to correct a persistent
> misinterpretation that Roy Fielding said something against CGI or
> against "excessive gatewaying". Hopefully he'll correct me if
> I'm wrong
> but I think that his opinion is that gatewaying (CGI or
> whatever) is the
> right way to integrate non-Web systems with the Web and is a core part
> of web architecture. You have repeatedly cited that message
> in a manner
> I believe to be incorrect and I felt it was necessary to
> inform you (no
> matter what the topic of discussion).
> --
> Come discuss XML and REST web services at:
>   Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
>   Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/
>
>







-----------------------------------------------------------------------------------
Post ID:1967
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-07-25 05:36:15
Subject:Re: [rest-discuss] Content-Location and Apache's mod_dir
Message:

Hmm, I've got an old book that explains them... will dig...

----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "Mark Nottingham" <mnot@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Wednesday, July 24, 2002 8:45 PM
Subject: Re: [rest-discuss] Content-Location and Apache's mod_dir


> On Fri, Jul 19, 2002 at 11:43:43AM -0700, Mark Nottingham wrote:
> > I'm thinking we should get a patch to Apache together... this would
make
> > the relationship between the resources explicit, helping Google, etc.
if
> > they want to take advantage of the info.
> >
> > Thoughts?
>
> Yah, for sure.  Let me know how I can help.  I'd love to learn how to
> develop an Apache module.  I've got other ideas for them too.
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:1968
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-25 06:31:47
Subject:Long lived transactions, business documents and REST
Message:

As I was thinking about whether long-lived transactions can be done with
HTTP or not - from that message with DonB's comments - I thought of some
ideas that may help communicate the ideas behind REST.

A business protocol - like sending and receiving purchase orders and
invoices - looks like a really simple thing to do with HTTP. You just send
the purchase order in a request and get the purchase order acknowledgement
in the response. The problem with this is that the idea that you are sending
documents with HTTP is incorrect. A /messaging/ protocol would be
appropriate to send documents with. For HTTP, what you are sending are
messages /about a resource/.
A business protocol is an abstract conceptual thing - with concepts like
purchase order, invoice, etc. Resources are also abstract conceptual
things - they can represent anything, even things /before/ they actually
'exist'.

When you use HTTP to implement business protocols, the messages you send
will be about resources that you and your partners have agreed are necessary
in order to conduct business. The HTTP message will be /about/ a purchase
order, it won't /be/ a purchase order.
For example, a business protocol may specify that a PO has a PO-ACK to
confirm its receipt and an Invoice to request payment (ignoring the
role-dependent document naming issues). Rather than describe who sends what
and when, an HTTP based business protocol would describe what documents (and
other pieces) are resources and who is responsible for creating them and
what operations are legal at certain points in the transaction. With this
approach the resource can have an identifier regardless of how many messages
have been exchanged and the resource can 'exist' independent of the exchange
of content.

For example, a big partner could pre-allocate a range of document IDs for
their small partners and over time these would be echoed back to the big
partner - the resource identifier exists and is valid to talk about and
message about independent of any exchange of content.

I have a growing sense that systems built on REST principles tend to not
look like document messaging systems - you tend to interact with documents,
rather than send and receive documents (where 'document' is a higher level
concept like purchase order, etc.).

Anyway... just some thoughts.








-----------------------------------------------------------------------------------
Post ID:1969
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-25 07:25:06
Subject:RE: [rest-discuss] RE: Clarification on REST, GET and CGI
Message:


> From: David Orchard [mailto:dorchard@...] 
>
> hmm.  Roy said that many CGI scripts suck because they don't 
> implement REST properly.  Don't think I'm misquoting him.  
> I'm pointing out that we don't look at the sucky CGI scripts 
> when determine web architecture because, well, they suck.

David,

Yes, on the other hand worst practices and antipatterns are highly
valuable guides to developers in the trenches, especially given the
amount of trench and the way people tend to cut and paste web systems
together (CGI being a prime example). For example, saying it's better to
not invent a new URI scheme is not quite the same as saying an arbitrary
new scheme sucks (cue: reason). As one example, the OO world has learned
much via antipatterns. Today, I suggest that saying non RESTful CGIs
suck is less useful that concrete examples; REST is not exactly
mainstream thinking yet.

There's a good amount of physical architecture in the world that is
based on what not to do as much as what to do. One thing the TAG could
say to the web community is, look we can't do it all, you guys start
writing the anti-patterns down and let us concentrate on the
architecture in a positive form.

regards,
Bill de hra 

..
Propylon
www.propylon.com 







-----------------------------------------------------------------------------------
Post ID:1970
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-25 07:59:16
Subject:Re: [rest-discuss] RE: Clarification on REST, GET and CGI
Message:

I apologize for cross-posting. It's just that the CGI misunderstanding
has come up in other forums by people who watch rest-discuss.

Bill, David was not discussing CGI in his role on the TAG. I proposed no
action item for him. I just wanted to correct a misunderstanding.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:1971
Sender:"oldieshome2002" <bill.oldroyd@...>
Post Date/Time:2002-07-25 10:13:24
Subject:Re: Long lived transactions, business documents and REST
Message:

--- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote:
> 
> As I was thinking about whether long-lived transactions can be done with
> HTTP or not - from that message with DonB's comments - I thought of some
> ideas that may help communicate the ideas behind REST.
> 
> A business protocol - like sending and receiving purchase orders and
> invoices - looks like a really simple thing to do with HTTP. You
just send
> the purchase order in a request and get the purchase order
acknowledgement
> in the response. The problem with this is that the idea that you are
sending
> documents with HTTP is incorrect. A /messaging/ protocol would be
> appropriate to send documents with. For HTTP, what you are sending are
> messages /about a resource/.
> A business protocol is an abstract conceptual thing - with concepts like
> purchase order, invoice, etc. Resources are also abstract conceptual
> things - they can represent anything, even things /before/ they actually
> 'exist'.
> 
> When you use HTTP to implement business protocols, the messages you send
> will be about resources that you and your partners have agreed are
necessary
> in order to conduct business. The HTTP message will be /about/ a
purchase
> order, it won't /be/ a purchase order.
> For example, a business protocol may specify that a PO has a PO-ACK to
> confirm its receipt and an Invoice to request payment (ignoring the
> role-dependent document naming issues). Rather than describe who
sends what
> and when, an HTTP based business protocol would describe what
documents (and
> other pieces) are resources and who is responsible for creating them and
> what operations are legal at certain points in the transaction. With
this
> approach the resource can have an identifier regardless of how many
messages
> have been exchanged and the resource can 'exist' independent of the
exchange
> of content.
> 
> For example, a big partner could pre-allocate a range of document
IDs for
> their small partners and over time these would be echoed back to the big
> partner - the resource identifier exists and is valid to talk about and
> message about independent of any exchange of content.
> 
> I have a growing sense that systems built on REST principles tend to not
> look like document messaging systems - you tend to interact with
documents,
> rather than send and receive documents (where 'document' is a higher
level
> concept like purchase order, etc.).
> 
> Anyway... just some thoughts.







-----------------------------------------------------------------------------------
Post ID:1972
Sender:"oldieshome2002" <bill.oldroyd@...>
Post Date/Time:2002-07-25 12:41:03
Subject:Re: Long lived transactions, business documents and REST
Message:

My apologies for the previous message which was due to my inexperience
with Yahoo.

The comment I wished to make with respect to the question of
processing documents is :

My understanding of the model is :

The resource is the "trade" between the purchaser and the supplier.
The "trade" records progressively more and more information as the
state of the "trade" changes over time. The puchase order, payments,
etc, are messages that change the state of the trade.

The trade can also contain at any one time, information that describes
how to make a valid state change from the current state. In other
words, it can contain information that allows the customer to
acknowledge receipt of the item, or for the supplier to send the bill,
or for either to cancel the trade.

The question that this raises in my mind is that if the "trade" is
addressed through a single URI, how is the view of each party, the
supplier or the purchaser, restricted to the state changes that they
can make.

Bill

 











-----------------------------------------------------------------------------------
Post ID:1973
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-25 13:03:23
Subject:Re: Long lived transactions, business documents and REST
Message:

"S. Mike Dierken" wrote:
> As I was thinking about whether long-lived transactions can be done 
with
> HTTP or not - from that message with DonB's comments - I thought of 
some
> ideas that may help communicate the ideas behind REST.

Mike, these are really interesting ideas.  Your ideas and mine are 
getting much close to convergence.  I'll try some tweaks below and 
see if we can do a complete mind meld.

> A business protocol - like sending and receiving purchase orders and
> invoices - looks like a really simple thing to do with HTTP. You 
just send
> the purchase order in a request and get the purchase order 
acknowledgement
> in the response. 

The business protocol for purchase orders is Offer-Acceptance.
Sending and receiving is only the beginning of the business protocol.
A purchase order is an offer to buy.  You do want to get a receipt 
acknowledgment, but the receipt acknowledgment may or may not 
constitute formal acceptance.  Thus the discussions we've had on this 
list about acceptance as a separate-but-related possibly much later 
interaction.

When you send a PO in a request and get a receipt ack in the 
response, the PO resource is in the "Offered" state, but most likely 
not yet in the "Accepted" state.

> The problem with this is that the idea that you are sending
> documents with HTTP is incorrect. A /messaging/ protocol would be
> appropriate to send documents with. For HTTP, what you are sending 
are
> messages /about a resource/.
> A business protocol is an abstract conceptual thing - with concepts 
like
> purchase order, invoice, etc. 

This is a really important insight.  
A purchase order is an economic contract.
Each purchase order line item represents two or more economic 
commitments:  usually a commitment from one party to deliver some 
goods or services, and a commitment from the other party to pay for 
them.

In a negotiation situation, there could be several messages or 
documents-sent-over-the-wire involved in coming to agreement on those 
commitments.  The resource would represent the current states of 
those commitments - although the audit trail of documents sent over 
the wire could also be saved as dependent resources.

> When you use HTTP to implement business protocols, the messages you 
send
> will be about resources that you and your partners have agreed are 
necessary
> in order to conduct business. The HTTP message will be /about/ a 
purchase
> order, it won't /be/ a purchase order.

Yes! Excellent!
I think of each message as a speech act in a conversation about an 
economic exchange.  The speech acts may change the states of 
resources involved in the exchange.
The economic exchange conversation has stages, for example:
* agreeing on commitments - promises to deliver goods and services 
and to pay for them;
* delivering the goods or services and payments and agreeing that the 
commitments were fulfilled (or not).

> Rather than describe who sends what
> and when, an HTTP based business protocol would describe what 
documents (and
> other pieces) are resources and who is responsible for creating 
them and
> what operations are legal at certain points in the transaction. 

I think the preceding statement needs some rewording, but the idea is 
correct.  "Legality" and "certain points" would best be defined in 
terms of states of resources involved in the economic exchange.
For example, don't deliver the goods if the order is in the Rejected 
state.  Or, you can't cancel the order if the goods have been shipped.

> Anyway... just some thoughts.

Good ones!  Thanks,
Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1974
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-25 13:28:08
Subject:Re: HTTP can't support web services
Message:

"S. Mike Dierken" wrote:
> 
> From: "Mark McEahern" <marklists@m...>
> > are there efforts to standardize these things?
> 
> There is something called AS2 which is a 'standard' mechanism for 
exchanging
> busines documents with MIME over HTTP. AS1 is MIME over SMTP. I 
haven't
> spent much time examining AS2 - perhaps BobH can fill us in - but 
it looks
> like a protocol on top of HTTP. 

I'm most familiar with the efforts in ebXML and UN/CEFACT to 
standardize business protocols.  AS2 was a predecessor.
For example, the Drummond group, conductor of the test in the UCC 
press release, was heavily involved in ebXML.  And UCC has said that 
they are migrating to ebXML, too.

I've followed (with increasing personal involvement) several 
generations of standardization efforts for business protocols. 
As far as I know, those efforts began in the Telecommunication 
Management Forum, then moved to RosettaNet, then to UN/CEFACT and 
ebXML, and then to UN/CEFACT eBTWG.

Here is a document that describes UN/CEFACT transaction and 
interaction patterns:
http://www.gefeg.com/tmwg/files/Chapter%208%20MetamodelR10.pdf

UN/CEFACT intends for their patterns to be technology-independent.
I think those transaction patterns can be refactored into REST.

For example, one aspect they discuss with some transaction patterns 
is "residual effects", as in the formation of business contracts and 
commitments.  I think REST resources are the embodiment of those 
residual effects.

UN/CEFACT eBTWG is also developing a standard set of economic 
elements for business exchanges that could be the basis for a 
standard set of REST resources.  It's not soup yet, but I'll post 
something here and on REST-Wiki when it is.

> It probably can be easily re-factored into a
> more REST-like approach, but until I get paid to do that sort of 
thing, I
> don't have the time right now to attempt that...

Same for me.  I just finished helping a company develop a demo of Web 
contract negotiation that was fairly RESTful, so we'll see if they 
can sell it to their prospects. It will be proprietary, though - 
unfortunately.

In the meantime, I pick away at the problem in these 
discussions...but would also be interested in a group development 
project using simple free tools.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1975
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-25 13:34:16
Subject:Re: OOPS, wrong URL
Message:

> Here is a document that describes UN/CEFACT transaction and 
> interaction patterns:
> http://www.gefeg.com/tmwg/files/Chapter%208%20MetamodelR10.pdf

Wrong, wrong wrong! This is the patterns section:
http://www.gefeg.com/tmwg/files/Chapter%209%20PatternsR10.pdf
 
Now, if I could do a PUT to revise the previous message, ...

Sorry about that,
Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1976
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-25 13:44:28
Subject:Re: Long lived transactions, business documents and REST
Message:

"oldieshome2002" <bill.oldroyd@b...> wrote:
> The comment I wished to make with respect to the question of
> processing documents is :
> 
> My understanding of the model is :
> 
> The resource is the "trade" between the purchaser and the supplier.
> The "trade" records progressively more and more information as the
> state of the "trade" changes over time. The puchase order, payments,
> etc, are messages that change the state of the trade.

Yes!  

> The trade can also contain at any one time, information that 
describes
> how to make a valid state change from the current state. In other
> words, it can contain information that allows the customer to
> acknowledge receipt of the item, or for the supplier to send the 
bill,
> or for either to cancel the trade.

Yes!

> The question that this raises in my mind is that if the "trade" is
> addressed through a single URI, how is the view of each party, the
> supplier or the purchaser, restricted to the state changes that they
> can make.

The "trade" will be one URI, but there will be several sub-resources 
hyperlinked to it for the order, each line item, each shipment, each 
payment, etc. and possibly each conversation or transaction about 
each of those resources.

The view of each party depends on the configuration:
* if centralized, either in a marketplace or in the extranet of the 
dominant trading partner, there will be one set of resources.
* if P2P, each trading partner will maintain their own set of 
resources.  It's like a HOPP or Half-Object Plus Protocol pattern, 
where each corresponding resource is a half-object and the business 
transaction protocol keeps their states aligned.

We've already discussed on this list several times different ways to 
implement state alignment transactions in REST.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1977
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-25 13:54:50
Subject:Re: Long lived transactions, business documents and REST
Message:

"oldieshome2002" wrote:
> The question that this raises in my mind is that if the "trade" is
> addressed through a single URI, how is the view of each party, the
> supplier or the purchaser, restricted to the state changes that they
> can make.

I neglected to speak to the "restrictions" issue in my previous 
reply. These issues are also being addressed by UN/CEFACT.  Their 
goal is to be able to conduct legally-binding business trades 
electronically.

In general, the rules for electronic business trades need to be 
spelled out in a computable form that is published and accessible to 
both trading partners.  

ebXML has a SOAPy version of such rules in XML documents in their 
Business Process Specification Schema. Version 1.01 was accepted by 
UN/CEFACT and OASIS and can be found here:
http://www.ebxml.org/specs/index.htm

Version 2 just went into public review.

UN/CEFACT is refining the rules in terms of states of business 
resources as we speak, due to be published in the fall.  That's the 
stuff that I think will be suitable for REST.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1978
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-25 18:10:46
Subject:HTTP "CONNECT" method
Message:

I didn't realize it, but HTTP already has a CONNECT method which could be
used for tunneling.
Anybody know anything more about this?


http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.9
==
9.9 CONNECT
This specification reserves the method name CONNECT for use with a proxy
that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]).







-----------------------------------------------------------------------------------
Post ID:1979
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-25 18:25:52
Subject:Re: [rest-discuss] HTTP "CONNECT" method
Message:

On Thu, Jul 25, 2002 at 11:10:46AM -0700, S. Mike Dierken wrote:
> 
> I didn't realize it, but HTTP already has a CONNECT method which could be
> used for tunneling.

Yah, exactly.  I've pointed it out a couple times here.

It's a Good Thing, because you have to *ask* to tunnel.

> Anybody know anything more about this?

See RFC 2817 for a good example.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:1980
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-25 19:00:53
Subject:Re: [rest-discuss] HTTP "CONNECT" method
Message:


> >
> > I didn't realize it, but HTTP already has a CONNECT method which could
be
> > used for tunneling.
>
> Yah, exactly.  I've pointed it out a couple times here.
>
> It's a Good Thing, because you have to *ask* to tunnel.
>
> > Anybody know anything more about this?
>
> See RFC 2817 for a good example.
>

It seems like Upgrade is all that is needed to deal with the 'client behind
firewall' situation.
The CONNECT is an end-to-end thing, which isn't what I was looking for.

Thanks for the bits.






-----------------------------------------------------------------------------------
Post ID:1981
Sender:"David Orchard" <dorchard@...>
Post Date/Time:2002-07-25 16:50:42
Subject:RE: [rest-discuss] RE: Clarification on REST, GET and CGI
Message:

Bill,

Very interesting suggestion, thank you for taking the time to write it.  I
take it from your comments that you are at least pleased that we, the TAG,
can write architecture in the positive sense.  One of the mechanisms we have
been using is the difference between the architecture document and the
findings.  We are trying to put "the positive" into the architecture doc,
and have the extended discussion in the findings.  I think this goes partway
to what you are looking for, but not as far as you'd like.  I wonder how we
could get an ongoing, useful and open discussion going.  Thinking aloud
(electronically so to speak), maybe we could have TAG findings refer to well
written patterns or anti-patterns..  At any rate, the TAG is certainly open
to ideas on how to better communicate with the various constituents, and how
to receive feedback/input.  Much of a successful architect's job is
communicating.

FWIW, I believe that we have a real disconnect and inability to talk about
various architectural styles in a detailed and positive manner.  I know I'll
get into trouble saying this on the REST discussion list, but none of us are
really shrinking violets...

Any architecture, REST or otherwise, makes certain trade-offs that hinder
some users or agents, and help others.  There may be a REST anti-pattern -
such as methods in the SOAP body anybody? - that are patterns in another
architecture.  Now there are trade-offs to either.  One of Roy's points
about why methods are bad in the body is because it adds another element to
the security context, particularly encumbering the firewall admin.  On the
ws-arch list, I wrote up 3 various ways that a simple GET/SET stockquote
could be done using 1) method names in body, 2) GET/POST; 3) different URLs.
And then I drilled into the way the firewall admin would administer each of
the designs.  This unfortunately didn't spark much discussion.  When I've
spent time with others - such as Mark Baker - and tried to drill into this
issue, it's not clear to me how significant the down side is.  So I admit
that even though I can quote scripture - even wrote up some REST/shared
information space scripture for the TAG bible - I haven't gotten the "faith"
that there is only one acceptable architecture for what we want to do with
much of machine to machine communications.

What I would ask from the REST community is that it be open to rationale,
detailed and reasoned discussion about the trade-offs associated with
diverse architectural styles.  Too much of the debate so far has been simply
n party broadcast monologues, to paraphrase MLK.

Cheers,
Dave


> -----Original Message-----
> From: www-ws-arch-request@... [mailto:www-ws-arch-request@...]On
> Behalf Of Bill de h�ra
> Sent: Thursday, July 25, 2002 12:25 AM
> To: 'David Orchard'; 'Paul Prescod'
> Cc: www-ws-arch@...; rest-discuss@yahoogroups.com;
> fielding@...
> Subject: RE: [rest-discuss] RE: Clarification on REST, GET and CGI
>
>
>
>
>
> > From: David Orchard [mailto:dorchard@...]
> >
> > hmm.  Roy said that many CGI scripts suck because they don't
> > implement REST properly.  Don't think I'm misquoting him.
> > I'm pointing out that we don't look at the sucky CGI scripts
> > when determine web architecture because, well, they suck.
>
> David,
>
> Yes, on the other hand worst practices and antipatterns are highly
> valuable guides to developers in the trenches, especially given the
> amount of trench and the way people tend to cut and paste web systems
> together (CGI being a prime example). For example, saying
> it's better to
> not invent a new URI scheme is not quite the same as saying
> an arbitrary
> new scheme sucks (cue: reason). As one example, the OO world
> has learned
> much via antipatterns. Today, I suggest that saying non RESTful CGIs
> suck is less useful that concrete examples; REST is not exactly
> mainstream thinking yet.
>
> There's a good amount of physical architecture in the world that is
> based on what not to do as much as what to do. One thing the TAG could
> say to the web community is, look we can't do it all, you guys start
> writing the anti-patterns down and let us concentrate on the
> architecture in a positive form.
>
> regards,
> Bill de h�ra
>
> ..
> Propylon
> www.propylon.com
>
>







-----------------------------------------------------------------------------------
Post ID:1982
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-07-25 19:15:59
Subject:RE: [rest-discuss] HTTP "CONNECT" method
Message:

I knew it was there but I've never actually seen it used in practice. Anyone
knows if it's even implemented by various user-agents?

On a separate but related topic, I re-read the document, especially the
"partial GET" directive. I'm wondering if it makes sense, in light of the
growing use of GET to return XML data, to have the Range Header specify an
XPath filter (or a begin-end XPath pair).

Any thoughts?

Ramin
  -----Original Message-----
  From: S. Mike Dierken [mailto:mdierken@...]


  I didn't realize it, but HTTP already has a CONNECT method which could be
  used for tunneling .  Anybody know anything more about this?






-----------------------------------------------------------------------------------
Post ID:1983
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-07-25 20:22:51
Subject:RE: [rest-discuss] xoomle
Message:

[ Please tell me to shut-up if I start sounding too much like a TV pitchman
(:-) ]

Get NetGlue (http://www.netglue.net). Install it. Crank up the server.
Assuming you already have a Google key. Point your browser at:

http://localhost/netglue/factory$Google.GoogleSearch.glu?key={google-key}&q=
{query}

and let it rip.

Or just browse through http://localhost/netglue and drill down to the Google
API which you can invoke visually from the browser itself. All the Google
parameter options are there. The package already comes with the Google HTTP
to SOAP component (there's also a two-way Amazon SOAP to HTTP bridge we're
releasing in a day or two).

If you want to format the result using XSLT or filter it using XPath, call
the same 'function' inside the Stage II pipeline, then drop in a 'transform'
action after it (or a 'Select' filter action) and format it into HTML or WML
or whatever. It should take about 30-seconds to set up (minus XSLT transform
writing time, of course (;-) It runs on your own box, so *you're* the
gateway not some remote site.

You can build your own bridge for other web-services with the provided
tools. It took us all of a minute to put together the Google (and Amazon)
bridges.

Okay, I'll shut-up now.
Ramin

  So close and yet so far:
  http://www.dentedreality.com.au/xoomle/docs/


http://xoomle.dentedreality.com.au/?key=YourGoogleDeveloperKey&method=doGoog
leSearch&q=dented+reality
  ==> method=doGoogleSearch.








-----------------------------------------------------------------------------------
Post ID:1984
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-07-25 20:29:59
Subject:Re: [rest-discuss] xoomle
Message:

Python?

(You do realize that rest-discuss is the secret Python Illuminati list,
right Ramin? :-)

Jb







-----------------------------------------------------------------------------------
Post ID:1985
Sender:Lucas Gonze <lucas@...>
Post Date/Time:2002-07-25 21:17:09
Subject:RE: [rest-discuss] HTTP "CONNECT" method
Message:

On Thu, 25 Jul 2002, Ramin Firoozye wrote:

> I knew it was there but I've never actually seen it used in practice. Anyone
> knows if it's even implemented by various user-agents?

It's there for HTTPS, so it's used constantly.  It's implemented in 
proxies, not user-agents.

- Lucas







-----------------------------------------------------------------------------------
Post ID:1986
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-07-26 14:34:24
Subject:Implementing a Purchase Order the REST way
Message:

Hi Folks,

I am working on creating a step-by-step, hands-on tutorial on creating
XML-based REST web services.  My tutorial guides the reader through the
creation of an actual set of Web services.  Things have been proceeding
fine for all of the services that involve clients getting something
(i.e., doing an HTTP GET).  I am now at the point where I want to
provide a service to allow clients to submit a Purchase Order (PO). 
Presumably, before a client submits a PO he/she 
 - gets "something" from the Web service, 
 - takes some actions (e.g., fills in a form), and then 
 - responds with a completed PO. 
I am stuck on what that "something" should be.  I need your help in
identifying what that "something" should be.

A relevant side note: One fundamental doctrine of my tutorial is that
you should design for maximum usability of your web services.  That is,
web services should be usable both by browser-based clients, and by
machine-based clients (i.e., machine-to-machine processing). 
Furthermore, the document that is served up by a Web service should be
usable by both types of clients.  Thus, I recommend serving up XML
documents containing a stylesheet processing instruction (PI).  Browsers
will automatically style the XML using the stylesheet PI (I am gearing
this towards the latest versions of the browsers.  I realize earlier
versions don't support this).  Machines will simply consume the raw XML.

Okay, back to the Purchase Order.  What resource does a client access
prior to submitting a PO?  My tutorial says "Step 1. Identify the
resources you wish to make available".  Hmm, it is not clear to me what
the resource is.  I don't think that the resource is "PurchaseOrder". 
That is what the client is composing.  Clearly the resource is not
"MakePurchaseOrder" as resources are nouns not verbs.  Perhaps it is
"PurchaseOrderTemplate"?  I don't like that but it's the best that I can
think of at the moment.  What do you think the resource is?

Let's suppose that the resource is "PurchaseOrderTemplate".  My tutorial
says "Step 2. Create a logical URL to the resource".  I propose this
URL: (this is a purchase order for a company, parts-depot, which sells
auto, bicycle, and rollerblade parts)

http://www.parts-depot/purchase-order-template

That seems like a reasonable logical URL.  What do you think?

Now the question is: if a client enters this URL what does he/she get
back?  Clearly, if the client is sitting at a browser then he/she would
like to see an HTML form that can be filled in.  What about the
machine-based client, what does it want?  Do we want to send to it an
empty PO XML document (i.e., tags but no data)?  Do we want to send to
it a pointer to a DTD/Schema?  Any either case, recall that I want to
send the same XML to all clients; with a stylesheet PI for browser
clients.

The last step, what the client returns, is easy - a completed PO.

So, to summarize my questions:

1. What should be the resource in this scenario?
2. What should be the URL to that resource?
3. I want to serve up an XML representation of the resource, so that I
can be consistent to all clients.  What XML should I serve up?

Thanks!  /Roger







-----------------------------------------------------------------------------------
Post ID:1987
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-07-26 16:24:17
Subject:Re: [rest-discuss] Implementing a Purchase Order the REST way
Message:

Roger L. Costello wrote:
> My tutorial guides the reader through the
> creation of an actual set of Web services.  Things have been proceeding
> fine for all of the services that involve clients getting something
> (i.e., doing an HTTP GET).  I am now at the point where I want to
> provide a service to allow clients to submit a Purchase Order (PO). 
> Presumably, before a client submits a PO he/she 
>  - gets "something" from the Web service, 
>  - takes some actions (e.g., fills in a form), and then 
>  - responds with a completed PO. 
> I am stuck on what that "something" should be.  I need your help in
> identifying what that "something" should be.

i suggest that the something is a 'catch-all' resource in the form web
page where you can create purchase orders, search for purchase orders,
browse indexes of purchase orders, and so on.  if you would like to see
a prototype of this email me and i will create one.  however this is
only really relevant for human user agents.  at the risk of tossing
around unsubstantiated buzzwords, i think that for machine user agents
this is a question of service discovery.  (see zeroconf.org for one
definition of service discovery, e.g. finding a printer on an IP network).

> A relevant side note: One fundamental doctrine of my tutorial is that
> you should design for maximum usability of your web services.  That is,
> web services should be usable both by browser-based clients, and by
> machine-based clients (i.e., machine-to-machine processing). 
> Furthermore, the document that is served up by a Web service should be
> usable by both types of clients.  Thus, I recommend serving up XML
> documents containing a stylesheet processing instruction (PI).  Browsers
> will automatically style the XML using the stylesheet PI (I am gearing
> this towards the latest versions of the browsers.  I realize earlier
> versions don't support this).  Machines will simply consume the raw XML.

i have been thinking about this issue as well.  i think it basically
boils down to the (jaded) topic of content negotiation.  i see the
Accept-Encoding (sp?) header as a reasonable way to achieve this.  i
think its difficult to support with existing httpd server tools though.

from a seperate perspective, i don't think xml support is adequate in
human user agents.  e.g. take mozilla.  the xlink support is dodgy (am i
the only one who thinks xlink is way too complicated?).  don't even ask
about IE.

i'm rambling on here.  basically, i think that at this stage it's better
to have human-only and machine-only representations.  for machine user
agents to use human-oriented (HTML/flash/etc) representations you need
screen scraping, which is a short-term kludge; for human user agents to
use machine-oriented (XML) representations, you need decent XML
infrastructure in the browsers; frankly i don't think the technology is
anywhere near mature enough.  clearly the way forward is to migrate
human user agents to XML, but this isn't where it needs to be for REST
to use just XML representations, IMHO.  sorry if i come across as a
pessimist; i welcome challenges to this point of view.

> Okay, back to the Purchase Order.  What resource does a client access
> prior to submitting a PO?  My tutorial says "Step 1. Identify the
> resources you wish to make available".  Hmm, it is not clear to me what
> the resource is.  I don't think that the resource is "PurchaseOrder". 
> That is what the client is composing.  Clearly the resource is not
> "MakePurchaseOrder" as resources are nouns not verbs.  Perhaps it is
> "PurchaseOrderTemplate"?  I don't like that but it's the best that I can
> think of at the moment.  What do you think the resource is?

referring to my first point above, i would call it

http://www.parts-depot.com/purchase-orders

(you could make it purchaseOrders, purchaseorders, or whatever, but
that's 'just' a question of style.)

further PUTs or POSTs that create purchase orders can create URIs of the
form

http://www.parts-depot.com/purchase-orders/foo

incidentally, i can't decide which is more appropriate here; a POST or a
PUT.  arguably, a POST makes sense as you are inserting a purchase order
into the set of all purchase orders.  i think a PUT could make a lot of
sense as well though.  i haven't investigated whether contemporary HTML
user agents support PUT either; anyone have any input on this?

> Let's suppose that the resource is "PurchaseOrderTemplate".  My tutorial
> says "Step 2. Create a logical URL to the resource".  I propose this
> URL: (this is a purchase order for a company, parts-depot, which sells
> auto, bicycle, and rollerblade parts)
> 
> http://www.parts-depot/purchase-order-template
> 
> That seems like a reasonable logical URL.  What do you think?

i prefer mine.  :)  i don't know whether 'template' is too specific.  i
would have envisaged this resource as something more general, a 'portal'
(if you'll forgive the use of that dot-com era word) into everything you
could want to do with purchase orders, and i think my name better
reflects such generality.

> Now the question is: if a client enters this URL what does he/she get
> back?  Clearly, if the client is sitting at a browser then he/she would
> like to see an HTML form that can be filled in.  What about the
> machine-based client, what does it want?  Do we want to send to it an
> empty PO XML document (i.e., tags but no data)?  Do we want to send to
> it a pointer to a DTD/Schema?  Any either case, recall that I want to
> send the same XML to all clients; with a stylesheet PI for browser
> clients.

see my point re: service discovery.  prescod's web pages (thanks paul!)
refer to an ongoing effort to provide a mechanism for describing REST
web services, if you could call them that.

> The last step, what the client returns, is easy - a completed PO.

agreed.  however the devil is in the details.  for me the details are
like this:

the client returns a specific /representation/ of the resource it
created; in this case a completed PO.  for machines this can be XML, for
 humans (X)HTML.

> So, to summarize my questions:

i'll summarise my (entirely subjective, nowhere near definitive) answers..

> 1. What should be the resource in this scenario?

a portal to everything to do with purchase orders.  indexes, search
forms, other forms, everything.

> 2. What should be the URL to that resource?

http://www.parts-depot.com/purchase-orders or equivalent.

> 3. I want to serve up an XML representation of the resource, so that I
> can be consistent to all clients.  What XML should I serve up?

i would serve up seperate (X)HTML/XML representations based on content
negotiation.  i just think that is the more pragmatic way forward given
the status quo in browser technology, and glacial progress in adopting
new technology (though my hope is that mozilla will breath new life into
user agent innovation if it becomes more mainstream).

however if you want to serve up a single XML representation, one
approach i have which i haven't experimented with yet is to use XML
namespaces; leave XHTML using the default root namespace, and use your
own namespace for the XML bits.

> Thanks!  /Roger

and thank you being an effective REST pioneer..

-vincent







-----------------------------------------------------------------------------------
Post ID:1988
Sender:"Mark McEahern" <marklists@...>
Post Date/Time:2002-07-26 18:11:47
Subject:RE: [rest-discuss] Implementing a Purchase Order the REST way
Message:

> further PUTs or POSTs that create purchase orders can create URIs of the
> form
>
> http://www.parts-depot.com/purchase-orders/foo
>
> incidentally, i can't decide which is more appropriate here; a POST or a
> PUT.  arguably, a POST makes sense as you are inserting a purchase order
> into the set of all purchase orders.  i think a PUT could make a lot of
> sense as well though.  i haven't investigated whether contemporary HTML
> user agents support PUT either; anyone have any input on this?

My impression is that PUT would only make sense if the client is specifying
the URI of the resource-to-be-created.  That's what PUT means, doesn't it?
I'm still learning this, of course.

// mark







-----------------------------------------------------------------------------------
Post ID:1989
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-26 19:14:22
Subject:Re: [rest-discuss] Implementing a Purchase Order the REST way
Message:

----- Original Message -----
From: "Roger L. Costello" <costello@...>

>
> A relevant side note: One fundamental doctrine of my tutorial is that
> you should design for maximum usability of your web services.  That is,
> web services should be usable both by browser-based clients, and by
> machine-based clients (i.e., machine-to-machine processing).

After building things in a nearly-REST way at a previous company for a few
years, I've come to the conclusion that the 'application resource model'
will be different for the two situations.
I would honestly build the machine-to-machine system without regard to user
interface, browser idiosyncrosies, etc. This is similar to muli-tier
application development. If you build one system to satisfy two goals -
automation and user interaction - then when the implementations conflict,
the user interaction will win out, mainly because it is visible and
touchable by 'decision makers'. Just as J2EE has entity-beans (data layer)
and session-beans (logic) separate from user interface, I think Web
applications also should be built with this separation.

There are many ways of building user interface based apps across the Web -
not the most architecturally pure things, but they work - but the new
territory for me is building automation based apps across the Web.

> Furthermore, the document that is served up by a Web service should be
> usable by both types of clients.
The representations of resources can certainly be used by both clients - but
I believe that the set of resources that the two types of clients interact
with will be different. However, there will be many cases where the user
interface needs 'blended' information that is not available in one
representation of one resource - which gives rise to a different resource,
which is why I believe the 'visual web' results in interaction with a
different set of resources than an 'automatable web'.


> Okay, back to the Purchase Order.  What resource does a client access
> prior to submitting a PO?  My tutorial says "Step 1. Identify the
> resources you wish to make available".
When I talk about resources, I often get confused between 'resource
instance' and 'resource type' - with REST, there are no resource types, so
we have to be careful to say what we mean.

The automation-oriented client does not need to access any resource prior to
submitting a PO.
The only fore-knowledge it needs to have is
 - does it use POST or PUT?
 - if it uses PUT, who decided what the URI was?
 - if it uses POST, how does it acquire the URI to POST to?
 - what content-type values are acceptable by the server?

I like the idea of using PUT, and the client asking the server for the URI
of an empty business document. This allows the client to commit that URI to
persistent data for its own tracking. If the PUT fails, its okay to keep
trying against the same URI. If a POST failed, retrying might cause the
server to think there were /two/ documents submitted.


>
> 3. I want to serve up an XML representation of the resource, so that I
> can be consistent to all clients.  What XML should I serve up?
Try xCBL. It's pretty full-featured and covers most business document types
(po, po-ack, invoice, etc.).
[BobH hopefully will correct me if I'm wrong here...]








-----------------------------------------------------------------------------------
Post ID:1990
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-26 21:16:36
Subject:Re: Implementing a Purchase Order the REST way
Message:

"S. Mike Dierken" wrote:
> > 3. I want to serve up an XML representation of the resource, so 
that I
> > can be consistent to all clients.  What XML should I serve up?
> Try xCBL. It's pretty full-featured and covers most business 
document types
> (po, po-ack, invoice, etc.).
> [BobH hopefully will correct me if I'm wrong here...]

There is no wrong at this stage of the game. It depends on who you 
want to do business with, and what they already have implemented, if 
anything.  If you're trading in a particular vertical industry, you 
should look around for industry standards.  Just Google "industryName 
XML".

xCBL is a reasonable default choice today.  The global standards 
situation is murky.  

You might watch UBL, which is sort-of the next generation xCBL, but I 
don't think they have any documents ready yet:
http://www.oasis-open.org/committees/ubl/
Or UN/CEFACT's eBTWG Core Components project, the successor the the 
ebXML Core Components group, but they don't have any documents ready 
yet either:
http://www.ebtwg.org/projects/core.html

There have been signs of convergence between UBL and UN/CEFACT Core 
Components and ANSI X12, but as far as I know, it hasn't happened yet 
and there are plenty of counter-indications, too.

One thing I learned from working with standards orgs is that they are 
almost (?) as competitive as software vendors.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1991
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-26 21:23:44
Subject:Re: Purchase Order - OOPS forgot RNet
Message:

> xCBL is a reasonable default choice today.  

Where was my head at?  If you're doing anything remotely technical, 
and maybe not even, use RosettaNet:
http://www.rosettanet.org

Another one to consider is OBI:
http://www.openbuy.org/

I forget the exact quote, but this is the place to say, the great 
thing about standards is that there are so many of them!

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:1992
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-27 03:06:07
Subject:Thoughts on submitting a PO
Message:

I have actually wondered about a different approach (at least I think it's
different) to this "submitting a PO" example that have been mentioned in a
couple of different threads.  Suppose the following:

CompanyA wants to submit an Purchase Order to CompanyB.  CompanyB must first
be able to review (according to it's internal business rules) the PO request
before is creates a matching order in it's own system.  Upon reviewing the
PO request, CompanyB must indicate to CompanyA what it's decision was.

Now, here is the process I have been mulling over...

CompanyA creates a PO in their system.  The system assigns the following URI
(please ignore the whole http thing, in case you are also reading the
xml-dev list lately) to it:

    http://CompanyA.com/PurchaseOrders/12345

The system then connects to a pre-arranged URL
(http://CompanyB.com/Orders/Requests) at CompanyB.  It POSTs the above URI
to CompanyB.  CompanyB returns the following URI as an ack response:

    http://CompanyB.com/Orders/Requests/12123

CompanyB now turns around and submits a GET request to CompanyA at
"http://CompanyA.com/PurchaseOrders/12345".  CompanyB goes off to think
about it.  At any time, CompanyA can submit a GET request at
"http://CompanyB.com/Orders/Requests/12123" to determine the current status
of the request.

A bit later, CompanyB agrees to the PO.  It creates a matching sales order
in their system and assign the following URI to it:

    http://CompanyB.com/Orders/55824

CompanyB then submits a POST request to
"http://CompanyA.com/PurchaseOrders/12345", where the content is the URI of
the new sales order in their system.  CompanyA now updates their internal
records to indicate that the PO has been accepted.  From this point on,
CompanyA can submit GET requests to "http://CompanyB.com/Orders/55824" to
determine the status of the order.


Now, here is why I have been thinking about this pattern...  We talk about
the PO that CompanyA submits to CompanyB.  In other discussions, we have
thought of POSTing the PO to a URL at CompanyB, where the URL represented...
well.. no one can really agree what it represents.  However, in the flow I
illustrated above, the resources are very clear:

    http://CompanyA.com/PurchaseOrders/12345  : This is the URI of the PO
resource.  Period.  The PO is owned by CompanyA and so is the URI.
    http://CompanyB.com/Orders/Requests  : This is the URI of the resource
that PO requests are submitted to.  This is owned by CompanyB, as is the
URI.
    http://CompanyB.com/Orders/Requests/12123  : This is the URI of the
specific request made be CompanyA.  It is owned by CompanyB, as is the URI.

At this point, both parties have the URIs necessary to query each other as
needed.  Once CompanyB makes the decision and creates new resource (the
sales order), it then give the associated URI to CompanyA.  Again, at this
point, both parties have the URIs necessary to query each other.

Another thing I should point out here is that at no time was any data POSTed
other than URIs.  CompanyA never POSTed their PO to CompanyB.  This is
because they are sending a representation of their resource to another
resource owned by CompanyB.  Likewise, CompanyB did not return a status.  It
returned a URI.  Later, CompanyB POSTs a URI, not the order itself.  At all
times, CompanyA and CompanyB exclusively use GET to get the representation
of the resource they want.


As I think about this model, it seems extremely clean to me.  There is no
ambiquity about what is the resource, what is the representation of a
resource, etc.  I would think this approach to be quite flexible, scalable,
easy to implement, etc.  So, what am I missing?  ;~)

---
Seairth Jacobs
seairth@...








-----------------------------------------------------------------------------------
Post ID:1993
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-07-27 09:16:28
Subject:Re: [rest-discuss] Thoughts on submitting a PO
Message:

Seairth Jacobs wrote:
> I have actually wondered about a different approach (at least I
> think it's different) to this "submitting a PO" example that have
> been mentioned in a couple of different threads.  Suppose the
> following:

i really like this model.  i think the crux of the matter is that there
are really two resources involved in the purchase order scenario.
companyA looks at its order as a purchase order, and companyB looks at
the same order as a /sales/ order.

after all companyB could in turn be purchasing from companyC, in which
case its resource would be a purchase order rather than a sales order.
the point here is that in general, companys purchase stuff and they sell
stuff.  they have different ordering systems for the two scenarios
because different rules and semantics apply in the business protocol.

i really like this model because i think it reflects the reality of
company buying and selling better.  there is clear delineation of which
resources exist, and who owns them.

as an aside, this is pretty the much the first time i have seen POST
used just to send a resource a URI rather than a full representation of
the resource.  how does this fit into the semantics of HTTP?  should the
URI be in a header, with /no/ representation in the POST body?  this
also raises another issue; now the issuer needs to 'own' a HTTP server
where they didn't before.

one more point: because there are more resources involved i think it may
take a while longer to 'grok' this resource model if you were trying to
explain it to somebody.  from a pedagogical perspective, i think maybe
it would be better to show a simpler version first, point out the
ambiguity, and then show this as a 'refinement' of the simpler one.

either way, thanks for sharing the model; it's certainly food for thought.

thanks,
-vincent







-----------------------------------------------------------------------------------
Post ID:1994
Sender:"borkazoid" <beau@...>
Post Date/Time:2002-07-27 09:44:48
Subject:Re: xoomle
Message:

Actually, I had never heard of REST until Dave Winer posted that to 
scripting.com. I am currently working with Paul Prescod to make 
XooMLe "REST-compliant" and the first revision should be up today, 
with a few more additions (XSLT etc) being included over the next 
week or so.

Thanks for your feedback tho guys.

Beau (DentedReality)


--- In rest-discuss@y..., lucas@g... wrote:
> 
> So close and yet so far:
> http://www.dentedreality.com.au/xoomle/docs/
> 
> http://xoomle.dentedreality.com.au/?
key=YourGoogleDeveloperKey&method=doGoogleSearch&q=dented+reality
> ==> method=doGoogleSearch.







-----------------------------------------------------------------------------------
Post ID:1995
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-27 13:59:13
Subject:Re: Thoughts on submitting a PO
Message:

Vincent D Murphy wrote:
> Seairth Jacobs wrote:
> > I have actually wondered about a different approach (at least I
> > think it's different) to this "submitting a PO" example that have
> > been mentioned in a couple of different threads.  Suppose the
> > following:
> 
> i really like this model.  i think the crux of the matter is that 
there
> are really two resources involved in the purchase order scenario.
> companyA looks at its order as a purchase order, and companyB looks 
at
> the same order as a /sales/ order.

I like it too, but a single-Web-resource model will also work.  
Regardless of what it was called, the single-resource would actually 
be an "Order", and the Purchase Order would be internal to the buyer 
and the Sales Order internal to the seller.

One consequence of having two resources is that their states are 
logically connected, that is, you need state-alignment transactions 
for subsequent interactions.  (This is not a killer requirement, you 
need a protocol for agreement on changes in a single-resource model, 
too.)

Another aspect of Seairth's approach that I like is that it starts to 
follow the Offer-Acceptance business protocol that we've discussed 
previously on this list.

Orders are contracts and there are rules and customs for contract 
formation that need to be re-interpreted slightly for electronic 
business, but still apply.  One of them is that a contract must be 
explicitly agreed to by both parties.  (Same for changes.)

The submission of a PO in any form is an Offer to buy.  It is not the 
end of the conversation.  The seller may or may not accept it, for 
any of many reasons.

See also PurchasingBusinessRequirements on RestWiki:
http://internet.conveyor.com/RESTwiki/moin.cgi/PurchasingBusinessRequi
rements

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:1996
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-27 15:44:44
Subject:Re: [rest-discuss] Thoughts on submitting a PO
Message:

From: "Vincent D Murphy" <vdm@...>
>
> as an aside, this is pretty the much the first time i have seen POST
> used just to send a resource a URI rather than a full representation of
> the resource.  how does this fit into the semantics of HTTP?  should the
> URI be in a header, with /no/ representation in the POST body?

I'm not sure, really.  I guess this is an application-level decision.  You
may choose to do put the URI in a header, or you could put the URI in the
content, or you may even wrap the URI inside of XML in the content.
Personally, I would go with the second option (mostly since that is how I
think of the format/layout of a POST).

> this also raises another issue; now the issuer needs to 'own' a HTTP
> server where they didn't before.

I would rather say "now each party needs to 'own' a HTTP server".  I see
this as no different than each party needing to own a phone.  Fortunately,
with the proliferation of inexpensive and dependable ASPs, this is not as
much an issue as it used to be.

> one more point: because there are more resources involved i think it may
> take a while longer to 'grok' this resource model if you were trying to
> explain it to somebody.  from a pedagogical perspective, i think maybe
> it would be better to show a simpler version first, point out the
> ambiguity, and then show this as a 'refinement' of the simpler one.

Certainly.  I think part of the reason that this may be more difficult to
grasp is that this requires thinking about URIs in a more REST-like manner,
which it seems that most people using the web do not.

>
> either way, thanks for sharing the model; it's certainly food for thought.

Of course, I don't see this model applying to all RESTful applications (not
yet, anyhow).  The main reason for this is that, as you point out above,
this requires server-to-server interaction.  And while that may be
increasingly possible for the business sector, the consumer sector is still
a bit of a ways off from having always-on, broadband, static IP connections
with HTTP servers sitting at the end of them.  :)

However, it may be possible to work around this problem with a hybrid
system, where individuals follow a client-server model with an HTTP server
they have access to, then the server itself uses the peer-to-peer model
(passing around URIs as discussed in the original post) with remote servers.
For instance, I may have access to the following server/URI space:

    http://www.seairth.com/users/seairth/

I have near unrestricted access to use PUT, POST, GET, etc to any URI within
that space.  I may install and map a messaging system to:

    http://www.seairth.com/users/seairth/message/

 I would then be able to PUT messages there (since I have 'absolute' control
of that space).  For instance:

    PUT http://www.seairth.com/users/seairth/message/out/12345

The internal messaging system would then turn around and POST the URI for
that message to the remote HTTP server of the user I am 'sending' the
message to (as discussed in the original post):

    POST http://www.seairth.com/users/sjacobs/messages/in

In turn, the remote user would query their own server using GET:

    GET http://www.seairth.com/users/sjacobs/messages/in

which would return to them a list of new messages including my original URI.
They would then be able to directly access the message on my server using
the above URI.  All of the resources would stay 'local'.  Then, when Bob
Haugen had realized that he forgot RosettaNet in [1], he would have been
able to do the PUT to correct it instead of posting [2].

[1] http://groups.yahoo.com/group/rest-discuss/message/1990
[2] http://groups.yahoo.com/group/rest-discuss/message/1991

---
Seairth Jacobs
seairth@...









-----------------------------------------------------------------------------------
Post ID:1997
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-27 17:15:49
Subject:Re: [rest-discuss] Re: Thoughts on submitting a PO
Message:

From: "bhaugen32" <bhaugen32@...>
>
> I like it too, but a single-Web-resource model will also work.
> Regardless of what it was called, the single-resource would actually
> be an "Order", and the Purchase Order would be internal to the buyer
> and the Sales Order internal to the seller.

Yes, but if CompanyA submits the PO to CompanyB such that both companies
use:

    http://CompanyB.com/Orders/55824

then who owns the resource?  How do each control what can be done to the
resource?  What keeps CompanyB from altering the Purchase Order?  And if
they do, how can CompanyA prove this if they don't even control the resource
pointed to by the above URI?

I am not saying that the single-resource approach is wrong.  I just don't
think I understand it as well as you do...

> One consequence of having two resources is that their states are
> logically connected, that is, you need state-alignment transactions
> for subsequent interactions.  (This is not a killer requirement, you
> need a protocol for agreement on changes in a single-resource model,
> too.)

I'm not sure I follow you here.  What would be considered a "state-alignment
transaction" here?


While I wait for an answer to that, here might be a scenario for a revision
(a subsequent interaction):

Suppose that CompanyA wanted to move the "Ship By" date forward a week.  In
their system, they may create the updated PO and assign it the following
URI:

    http://CompanyA.com/PurchaseOrders/12345/A

(though it could just has easily have been
http://CompanyA.com/PurchaseOrders/12346)

This would then be submitted to CompanyB just as the original URI was
submitted.  CompanyB would then GET the new PO (it's important to note that
the original URI is still valid and still returns a representation of the
original PO).  This new PO would contain the original URI, which would allow
CompanyB to see that this is a revised PO and not a new one.  CompanyB will
issue an ack response:

    http://CompanyB.com/Orders/Requests/12136

At this point, CompanyB will determine what to do.  Supposing it can meet
the new deadline, it creates a new Sales Order (internally, it may be the
original order with a revision attached to it).  This new order will be
submitted back to CompanyA as:

    http://CompanyB.com/Orders/55824/A

(though it could just as easily have been http://CompanyB.com/Orders/55833)

And we are now back to where we started from.  You will note that the
revision process was nearly identical to the initial process.  Also, the
URIs are still as 'opaque' as they were to start with.  Other than the need
of each company to keep track of the relationship of their own URI to the
other companie's URI, no additional state information is necessary.
Further, the creator of a given URI always pushes it to the other company
and it is always being pushed to the related URI (either as a POST or as a
response to a POST).  This make for easy management of related URIs between
two parties.

As a side note, would this approach address some of Mike's concerns in [1].

---
Seairth Jacobs
seairth@...

[1] http://groups.yahoo.com/group/rest-explore/message/86









-----------------------------------------------------------------------------------
Post ID:1998
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-07-27 22:06:03
Subject:Re: [rest-discuss] Re: xoomle
Message:

Thanks for putting up this excellent service.

First let me explain what I've been doing, and then at the end I have a
question about how it might work if you were to employ the HTTP
authentication mechanism that Paul Prescod had suggested in an earlier
message.

I've been putting together a few XSLT templates
that encapsulate calling your service in order to demonstrate some of the
benefits of a REST-style approach to some colleagues at work.

Even though the examples are trivial, people get pretty excited by what can
be done.

With a REST interface one can create a stylesheet that can be
imported and called without a lot of unnecessary code, allowing multiple
services to be combined in interesting ways.  For example, I did a similar
thing with the Amazon interface in order to obtain an "$author" from a book
title, then pass that into a template called "search-for-url" in the Google
templates which returns the first URL found for that author name. Granted,
it's probabilistic, but it's just a simple demo.


  <xsl:import href="amazon.xsl"/>
  <xsl:import href="google.xsl"/>

  <!-- ... get "author" from amazon ... -->

  <a>
    <xsl:attribute name="href">
      <xsl:call-template name="search-for-url">
        <xsl:with-param name="search-term" select="$author"/>
      </xsl:call-template>
    </xsl:attribute>
    <xsl:value-of select="$author"/>
  </a>


With Google's SOAP interfaces, I'm basically cut off from doing this.


Both the Amazon and Google template use the XSLT document() function in
order to call the service and obtain results.  I'm not sure how that
function
would react to an HTTP Authentication request, so I would ask that you allow
keys to be used in the query for the time being.

I'd be happy to share this work with anyone that is interested; just send me
an
email. Thanks again.


- Jeff











----- Original Message -----
From: "borkazoid" <beau@...>
To: <rest-discuss@yahoogroups.com>
Sent: Saturday, July 27, 2002 5:44 AM
Subject: [rest-discuss] Re: xoomle


> Actually, I had never heard of REST until Dave Winer posted that to
> scripting.com. I am currently working with Paul Prescod to make
> XooMLe "REST-compliant" and the first revision should be up today,
> with a few more additions (XSLT etc) being included over the next
> week or so.
>
> Thanks for your feedback tho guys.
>
> Beau (DentedReality)
>
>
> --- In rest-discuss@y..., lucas@g... wrote:
> >
> > So close and yet so far:
> > http://www.dentedreality.com.au/xoomle/docs/
> >
> > http://xoomle.dentedreality.com.au/?
> key=YourGoogleDeveloperKey&method=doGoogleSearch&q=dented+reality
> > ==> method=doGoogleSearch.
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>










-----------------------------------------------------------------------------------
Post ID:1999
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-28 00:59:44
Subject:Re: Thoughts on submitting a PO
Message:

"Seairth Jacobs" wrote:
> From: "bhaugen32" <bhaugen32@y...>
> >
> > I like it too, but a single-Web-resource model will also work.
> > Regardless of what it was called, the single-resource would 
actually
> > be an "Order", and the Purchase Order would be internal to the 
buyer
> > and the Sales Order internal to the seller.
> 
> Yes, but if CompanyA submits the PO to CompanyB such that both 
companies
> use:
> 
>     http://CompanyB.com/Orders/55824
> 
> then who owns the resource?  

Before we get too deep into this subject, let me clarify: I am not 
recommending a single-resource configuration.  Or a two-resource 
config. I've seen both.  Both can work.  Logically, you are correct, 
there are two sides of a contract.  For orders, they're often called 
purchase order and sales order. Each trading partner will keep their 
own private copy.  We're just talking about what's published in the 
external shared space as Web resources, which could be two or one 
order resources.

Who owns it?  I've seen a marketplace (Commerce One, Ariba, etc.) and 
also the dominant trading partner.

> How do each control what can be done to the
> resource?  What keeps CompanyB from altering the Purchase Order?  
And if
> they do, how can CompanyA prove this if they don't even control the 
resource
> pointed to by the above URI?

Company A digitally signs the offer, Company B adds their acceptance 
and digitally signs the combination of offer and acceptance.  
Needless to say, Company A archives a copy of the combined signed 
resource.

> I am not saying that the single-resource approach is wrong.  I just 
don't
> think I understand it as well as you do...

I'm still working out some of the details in REST, and so am very 
interested in different people's approaches.  The most practice I've 
seen with this stuff is with:
(a) two-resource configurations using the EDI mailbox approach, and
(b) Web form interfaces for small companies selling to large 
customers, where the customer posts the PO on an extranet and the 
supplier accepts or maybe is allowed to negotiate timing, quantity, 
number of deliveries, etc.

> > One consequence of having two resources is that their states are
> > logically connected, that is, you need state-alignment 
transactions
> > for subsequent interactions.  (This is not a killer requirement, 
you
> > need a protocol for agreement on changes in a single-resource 
model,
> > too.)
> 
> I'm not sure I follow you here.  What would be considered a "state-
alignment
> transaction" here?

If you have two order resources (PO and Sales Order), they are 
actually two sides of the same contract.  So if you change the state 
of one in some way that changes the contract, the other needs to be 
changed too, and both parties should agree to and digitally sign the 
changes.

Offer-Acceptance as practiced by RosettaNet and ebXML is a business 
protocol for coming to agreement on contract formation and changes in 
a two-resource configuration.

In a state-alignment transaction, the resources begin in state X, the 
initiator of the transaction requests a change to state Y. If the 
other party agrees, the resource state is changed to Y. If not, or if 
there is a technical failure, the state remains at X.  No rollback, 
no locking.  Pretty simple.  This is an instance of the HOPP pattern, 
for Half-Object Plus Protocol, because in this case the two resources 
are actually halves of the same contract.

For a verbose description of business state alignment transactions, 
see:
http://www.gefeg.com/tmwg/files/Chapter%209%20PatternsR10.pdf

We've been working out a RESTful Offer-Acceptance protocol on this 
list.  It's still missing a couple of features, e.g. time 
constraints, security and non-repudiation features.  But it's pretty 
close.

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:2000
Sender:"Beau" <borkazoid@...>
Post Date/Time:2002-07-28 10:29:22
Subject:RE: [rest-discuss] Re: xoomle
Message:

// Thanks for putting up this excellent service.

not a problem, I'm glad that it is useful to someone, even if only as a
"case study" or something like that. I hope the recent changes haven't
messed up your work too much (change to unique URIs for each method).

// I've been putting together a few XSLT templates
// that encapsulate calling your service in order to demonstrate some of the
// benefits of a REST-style approach to some colleagues at work.

sounds interesting - i'd like to see what you've done if i could :)

in the near future, i am planning on allowing the XML output to include a
ref to an XSL, probably by just including t=http://your.xsl in the request
(URL-encoded of course). this shouldn't affect any existing use of XooMLe as
it will just not include any reference to it if not requested.

// Both the Amazon and Google template use the XSLT document() function in
// order to call the service and obtain results.  I'm not sure how that
// function
// would react to an HTTP Authentication request, so I would ask
// that you allow
// keys to be used in the query for the time being.

as far as the keys go, my plan is this;

1. XooMLe will look for &key=GoogleAPIKey in the request,
2. if that's not found, it will also check for the key value using a 401
Header (HTTP Auth Required) which could potentially be sent in the form
http://key:GoogleAPIKey@.../search/ (username will
be "key", password will be your key). Apart from that, you can use whatever
HTTP Authentication manager you have access to depending on the language
being used.

Hope that works out for you ;)

// I'd be happy to share this work with anyone that is interested;
// just send me
// an
// email. Thanks again.

I'd like to see what you've done!







-----------------------------------------------------------------------------------
Post ID:2001
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-07-28 18:04:25
Subject:Complex HTTP params
Message:

REST folks,

I'm trying to spec out something and I thought I'd take a survey of the REST
folks for opinions and ideas. I've tried to find postings or articles on
standard practices but haven't found anything.

Here's the problem: Let's say you have a mechanism that allows you to invoke
SOAP requests via HTTP. Let's say the SOAP request takes parameters str,
num, and bool. So to invoke it from HTTP (I'll use GET as an example, but it
would be similar for POST, you would issue:

  http://host.com/soapfunction?str=hello&num=12&bool=true

But SOAP lets you build complex nested structures with named fields (think
of a C struct or a Java class with only public data members). If you want to
invoke one of these guys via HTTP, one way would be to use a 'dot' notation
like C or Java:

  http://host.com/soapfunction?struct.str=hello&struct.num=55

The place where it hits a bit of a snag is when you have the notion of
arrays to tackle:

  http://host.com/soapfunction?str[1]=hello&str[2]=world

The first problem is how the bracket '[]' characters are handled. Some
browsers just urlencode the whole thing  and ship it down to the server to
let it deal with it. Some older browsers barf on it. Some server-side
toolkits are cool with it. Others aren't. It's pretty inconsistent out
there. I also came across one case where the stuff before the '=' could
*only* be alpha/numeric/dash/underline if it was a form-POST (I'll try to
remember where I saw it).

I've thought of trying '{}' (braces), '()' (parens), or '<>' (lt/gt)
characters but I'm guessing it'll have similar problems with brackets. Ugly,
but workable is to use something like "str_1" as a stand-in for "str[1]" but
it kinda gives me the willies.

Anyway, if anyone has already done some work on this, or if there's a
standard spec I've missed, please point me at it. I'd rather not reinvent
the wheel. Barring that, are there any opinions on what's the friendliest
way to encode structs and arrays in URL parameters?

The easy way out would be to say "if you need to use structs and arrays go
SOAP -- for simple params, use HTTP" but I think it's good to keep REST-like
interfaces applicable for more complex interfaces.

Thanks,
Ramin
---
Ramin Firoozye
Wizen Software
---







-----------------------------------------------------------------------------------
Post ID:2002
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-07-28 21:10:16
Subject:Re: [rest-discuss] Re: Thoughts on submitting a PO
Message:

Thanks for all the excellent comments!  I have been carefully analyzing
each response.  I have limited time to write, but I wanted to send out
some comments and my latest thinking (influenced heavily by your
comments)

1. Mike suggested that a Web service should treat visual clients (i.e.,
a client sitting at a browser) different from automation clients (i.e.,
a client that is a program - no eyes involved).  Mike may be right, but
I hope not.  My vision is an HTML-less Web.  I envision a Web in which
the only documents flying across the Web are semantic-rich XML
documents.  If the consumer of one of those XML documents happens to be
a visual client then automatically the client's browser fetches the XSLT
stylesheet and produces a nice visual rendition of the XML data.  If the
consumer is a machine, then the raw XML is just fine.

2. Seairth made a very nice exchange protocol.  However, there are
several things that bother me about that:

a. Seairth wrote in his initial message:

> [The first thing that happens is] CompanyA creates a PO in their system.

But wait, if I am the client and I am sitting at a browser I don't want
to create a PO from scratch.  I want CompanyB to provide me a nice order
form to fill out.

b. The second objection I have is that CompanyA needs a Web server (or
access to some Web server).  The typical client isn't going to know what
a web server is, let alone how to stand one up, and put the PO into the
correct location on the server.  

c. I don't agree with calling it a purchase order on the CompanyA side
and a sales order on the CompanyB side.  In my business, when a client
sends me a purchase order I still call it a purchase order.  How I treat
the PO may be different than how the client treats the PO.  But I still
call it a PO.

Seairth's approach may be the correct REST one but I would like
something more applicable to the masses.  Here's the idea that is
currently brewing in my head:

A client (the client could be a visual or automation client) is
interested in purchasing something from CompanyB.  So, the client
requests an <<order form>> by issuing this GET:

    http://www.CompanyB.com/orderForm ------>

Prior to giving the client an orderForm CompanyB requests
identification, so it responds with a login form, loginForm.xml

   <----------------  loginForm.xml

(Note, for visual clients the browser will automatically grab the XSLT
stylesheet that the XML document references and provide a nice visual
rendition of the login form, i.e., a login screen)

The loginForm.xml specifies what data the client must provide to create
an idCard.xml.  The client thus returns idCard.xml to CompanyB:

   ------------------> idCard.xml

(Note, for visual clients idCard.xml is automatically generated using,
say, JavaScript, from the info that the user enters at the browser)

Now CompanyB gives the client the order form.  However, the order form
has a customized return address (based upon data in idCard.xml)

   <------------------- orderForm.xml (with customized return address)

The orderForm.xml describes what data the client must provide in his
PO.  For example, it tells the client that he must provide the ID of
each part desired and the quantity desired, and he must provide credit
card info - type of card, card number, expiry date.  [This is quite
interesting - the data in orderForm.xml is data about the data (i.e.,
metadata) that must be provided in the PO.  Likewise for loginForm.xml
above.]  The client constructs a PO using the info in orderForm.xml. 
The client submits (PUTs) the completed PO to the URL provided in
orderForm.xml:

   PO.xml ----> http://www.CompanyB.com/PurchaseOrders/costello -->

{Note, for visual clients the XSLT stylesheet provides a nice form that
the client simply fills in.  When the client hits Submit some Javascript
code harvests all the data that the user entered and constructs PO.xml)

I hope this makes sense.  I apologize for not writing more explicitly. 
Hopefully, you can get the gist of what I am saying.  /Roger







-----------------------------------------------------------------------------------
Post ID:2003
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-07-28 22:02:29
Subject:Re: [rest-discuss] Re: xoomle
Message:

A suggestion:

Google supports site specific searching, i.e., if you include the term
"site:www.microsoft.com" in the Search field, the results are filtered so
that only those in the www.microsoft.com domain are returned.  You don't
even have to fully qualify the criteria, so if you just say "site:au" you
get only "au" domain results, or "site:com.au" you get only "com.au"
domains.

You could take advantage of this to create an interface such as this:

[search the world for "xml" (what you have now)]
http://xoomle.dentedreality.com.au/search?q=xml

[search only .com sites]
http://xoomle.dentedreality.com.au/search/com?q=xml

[search only .au sites]
http://xoomle.dentedreality.com.au/search/au?q=xml

[search all of microsoft.com]
http://xoomle.dentedreality.com.au/search/com/microsoft?q=xml

[search only the www.microsoft.com subdomain]
http://xoomle.dentedreality.com.au/search/com/microsoft/www?q=xml

[search only the msdn.microsoft.com subdomain]
http://xoomle.dentedreality.com.au/search/com/microsoft/msdn?q=xml

The "site:" syntax is such that you should be able to write an http filter
that walks down the hierarchy appending the terms after "search" until you
hit the ? character and use them to build up a "site:" qualifier.  This
would work no matter how many subdomains there are.

This seems like a cool REST-ian approach.  What do others think?

- Jeff









-----------------------------------------------------------------------------------
Post ID:2004
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-28 22:07:25
Subject:Re: Thoughts on submitting a PO
Message:

Roger,

I resequenced some clips from your message in order to comment.

"Roger L. Costello" wrote:
> Seairth's approach may be the correct REST one but I would like
> something more applicable to the masses.  Here's the idea that is
> currently brewing in my head:

I don't think there is any consensus on a correct REST approach yet.
Several people are exploring ideas.
Maybe there will never be one single correct approach.
It will depend (as usual) on context and conditions.
For example:

> if I am the client and I am sitting at a browser I don't want
> to create a PO from scratch.  I want CompanyB to provide me 
> a nice order form to fill out.

But if you are CompanyA's computer system and you and CompanyB have a 
regular business relationship, you already know the format to use and 
what to do with it.
So just shoot them a PO.

-Bob Haugen









-----------------------------------------------------------------------------------
Post ID:2005
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-29 01:59:23
Subject:Re: [rest-discuss] Re: Thoughts on submitting a PO
Message:

I should point out that my post was not targeted at any current thread.  The
transaction idea came to me a couple days back.  The frequent PO example
seemed like a good way to convey it.  Having said that....

From: "Roger L. Costello" <costello@...>
>
> > [The first thing that happens is] CompanyA creates a PO in their system.
>
> But wait, if I am the client and I am sitting at a browser I don't want
> to create a PO from scratch.  I want CompanyB to provide me a nice order
> form to fill out.

I agree.  This approach will not necessarily work for the basic browser
environment you were talking about.

> b. The second objection I have is that CompanyA needs a Web server (or
> access to some Web server).  The typical client isn't going to know what
> a web server is, let alone how to stand one up, and put the PO into the
> correct location on the server.

Well, I would not expect someone expecting to use nothing more than a
browser to deal with a web server.  However, suppose instead that you worked
for a company (CompanyA) that did have a web server (or access to one).
Instead of pointing your browser to CompanyB's server, you could point it to
your own, where a PO form(s) would take you through the process to create a
PO for CompanyB.  The resultant PO would be stored on ServerA and you would
then be able to use the scenario I mentioned.

Okay, this may still be more complicated than you are looking for, but I
think there are a number of extensions to / variations on the theme that
would allow the technique to be used at some level...

> c. I don't agree with calling it a purchase order on the CompanyA side
> and a sales order on the CompanyB side.  In my business, when a client
> sends me a purchase order I still call it a purchase order.  How I treat
> the PO may be different than how the client treats the PO.  But I still
> call it a PO.

But my model does not disagree with your view.  There is no reason you can't
call it a purchase order on your side.  Regardless, your PO is a different
resource than your client's related PO.  I chose to use PO and SO to make
the separation of resources more clear (within my example).

More important than PO's, though, is the fact that they model itself is
quite generic.  The use of two servers like this is quite clean (IMO),
whether implementing ordering systems, mail systems, collaboration systems,
etc.  The only real issue I have not been able to resolve is how to
effectively handle access and security issues.

> Seairth's approach may be the correct REST one but I would like
> something more applicable to the masses.

Heh.  I doubt my model is the "correct" one.  As you point out above, there
are scenarios (e.g., browser only) that do not fit this model.  And it is
not realistic (yet) to have everyone use the model I gave.  Maybe years from
now, when everyone is "always on", have their own web servers, etc., then
this model might be more universally applicable... but that's still a big
maybe.  :)

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2006
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-29 10:35:56
Subject:useful web service spotted shock
Message:

From the department for useful web services.

http://www.kokogiak.com/amazon/

is a usability wrapper around Amazon, using the web services api. 

regards,
Bill de hra

..
Propylon
www.propylon.com 

 








-----------------------------------------------------------------------------------
Post ID:2007
Sender:Seth Johnson <seth.johnson@...>
Post Date/Time:2002-07-29 11:19:36
Subject:Re: [rest-discuss] Re: Thoughts on submitting a PO
Message:

Well, we could build in dynamic DNS domain name support (!)

:-)

(And now, back to REST . . .)

Seth Johnson

Seairth Jacobs wrote:
> 
> Heh.  I doubt my model is the "correct" one.  As you
> point out above, there are scenarios (e.g., browser
> only) that do not fit this model.  And it is not
> realistic (yet) to have everyone use the model I
> gave.  Maybe years from now, when everyone is "always
> on", have their own web servers, etc., then this
> model might be more universally applicable... but
> that's still a big maybe.  :)
> 
> ---
> Seairth Jacobs
> seairth@...

-- 

[CC] Counter-copyright:
http://cyber.law.harvard.edu/cc/cc.html

I reserve no rights restricting copying, modification or
distribution of this incidentally recorded communication. 
Original authorship should be attributed reasonably, but
only so far as such an expectation might hold for usual
practice in ordinary social discourse to which one holds no
claim of exclusive rights.







-----------------------------------------------------------------------------------
Post ID:2008
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-07-29 12:36:31
Subject:Re: PO-SO naming question
Message:

Roger and other PO-interest-group participants,

This is just a curiosity question about the very limited issue of 
what to name the resources in a 2-resource REST order configuration.

I'm not trying to promote a 2-resource model, just got to thinking 
about Roger's assertion below:

"Roger L. Costello" wrote:
> c. I don't agree with calling it a purchase order on the CompanyA 
side
> and a sales order on the CompanyB side.  In my business, when a 
client
> sends me a purchase order I still call it a purchase order.  How I 
treat
> the PO may be different than how the client treats the PO.  But I 
still
> call it a PO.

Questions for Roger and others:
1. When you place POs with your suppliers, do you call them POs too? 
How do you differentiate in normal conversation or computer systems 
between your POs to your suppliers and POs from your customers?
2. If you take the POs from your customers into your internal 
business apps, are they still called POs?  

The larger context for these questions is that I think in all cases 
of business exchanges between trading partners, there is a set of 
matched resources on each side that have different names but are 
logically related to the same business commitment or event.

In other words, each of them could be managed either by a 2-resource 
HOPP configuration or a one-resource config.

Other examples, with 2 resources and (1 resource):
* Product shipment and receipt (product transfer).
* Cash disbursement and cash receipt (cash transfer).
* Accounts Payable and Receivable (claims).

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2009
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-29 13:57:38
Subject:Re: [rest-discuss] useful web service spotted shock
Message:

On Mon, Jul 29, 2002 at 11:35:56AM +0100, Bill de h�ra wrote:
> >From the department for useful web services.
> 
> http://www.kokogiak.com/amazon/
> 
> is a usability wrapper around Amazon, using the web services api. 

Using the XML/HTTP "API", even.

REST 1, RPC 0. 8-)

Note to Amazon; next stop, RDF.  That would totally rock.  Integration
possibilities up the wazoo.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2010
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-07-29 17:53:15
Subject:Re: [rest-discuss] Re: Thoughts on submitting a PO
Message:

bhaugen32 wrote:
>>if I am the client and I am sitting at a browser I don't want
>>to create a PO from scratch.  I want CompanyB to provide me
>>a nice order form to fill out.
>
>
> But if you are CompanyA's computer system and you and CompanyB have a
> regular business relationship, you already know the format to use and
> what to do with it.
> So just shoot them a PO.

the other important point is that this use case is on the 80 side of the
80-20 rule (IMHO).







-----------------------------------------------------------------------------------
Post ID:2011
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-07-29 18:08:00
Subject:Re: [rest-discuss] Re: Thoughts on submitting a PO
Message:

From: "Vincent D Murphy" <vdm@...>
>
> bhaugen32 wrote:
> >>if I am the client and I am sitting at a browser I don't want
> >>to create a PO from scratch.  I want CompanyB to provide me
> >>a nice order form to fill out.
> >
> >
> > But if you are CompanyA's computer system and you and CompanyB have a
> > regular business relationship, you already know the format to use and
> > what to do with it.
> > So just shoot them a PO.
> 
> the other important point is that this use case is on the 80 side of the
> 80-20 rule (IMHO).

Which case?  Bob's or Roger's?  And what do you mean by "on the 80 side"?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2012
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-07-29 18:33:55
Subject:Re: [rest-discuss] Re: Thoughts on submitting a PO
Message:

Seairth Jacobs wrote:

>>>But if you are CompanyA's computer system and you and CompanyB have a
>>>regular business relationship, you already know the format to use and
>>>what to do with it.
>>>So just shoot them a PO.
>>
>>the other important point is that this use case is on the 80 side of the
>>80-20 rule (IMHO).
>
>
> Which case?  Bob's or Roger's?  And what do you mean by "on the 80
> side"?

sorry; i think i fired that brain dump off a bit too quickly without
enough elaboration.

i was saying that bob's case is the more common one.  at least with my
experience of ordering (in manufacturing/engineering companies), you
have established relationships with a 'core' of suppliers.  you are far
more likely to be purchasing from a supplier who you have already
purchased than from a complete 'stranger', so to speak.  you do
occasionally order from a supplier you haven't ordered from before, but
this is less common than the other case.

i think a "pretty order form" is geared towards strangers, when a
relationship is established you just "shoot them a PO" and the
two-resource model is a better match for this.

i had the concern roger voiced about the purchaser needing a web server,
but i think in the long-term this wouldn't be a problem.  might affect
how easy it is to adopt a two-resource approach though.

hope this cleared that up.  i am conscious that "doing is better than
talking about doing".  :)








-----------------------------------------------------------------------------------
Post ID:2013
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-30 12:47:08
Subject:Coincidence or correspondance?
Message:

Warning: abstract theory ahead!

Properties in semantic web languages differ from properties in
programming languages in that they are global. The
http://foo/bar/baz#prop property is the same whether it appears on a
resource of type "X" or a resource of type "Y". but different resources
can support different subsets of the global set of properties.

Methods in REST differ from methods in programming languages in that
they are global. The POST or PROPFIND method are the same whether they
appear on a resource of type "X" or a resource of type "Y".

Is this just a coincidence or a revelation of something deep in the
nature of the web architecture?
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:2014
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-30 12:47:34
Subject:OSCON 2002
Message:

It was great to meet so manyu REST followers at OSCON 2002. For those
who couldn't be there, I had a couple of fairly well attended talks on
REST topics, Matt Seargent did a talk which concluded that REST is a
better model than SOAP RPC if you can get your boss to agree to let you
use it and generally it seems like the REST meme is spreading well. A
year ago REST was a FORK phenomenon. Six months ago it was an FORK,
rest-discuss and xml.com phenomenon. Now it's worldwide baby!

Furthermore, the addition of WebMethods to SOAP allows a change in
tactics. Rather than attacking SOAP we can offer REST as an
architectural style to make your SOAP services scalable, interoperable,
discoverable and all that other good stuff.
-- 
Come discuss XML and REST web services at:
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:2015
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-30 13:28:08
Subject:Re: [rest-discuss] Coincidence or correspondance?
Message:

On Tue, Jul 30, 2002 at 05:47:08AM -0700, Paul Prescod wrote:
> Is this just a coincidence or a revelation of something deep in the
> nature of the web architecture?

It's just a side effect of "all important resources should have a URI".
A property has identity, and in many cases is important, ergo it gets a
URI (mumble URIref mumble).

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2016
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-07-30 15:54:16
Subject:The SOAP Juggernaut rolls on...
Message:

While it's encouraging to see the WebMethods feature being adopted by SOAP
1.2, I question how often a REST architecture will actually be adopted.

Even the GET examples that are shown in the SOAP spec don't really encourage
a REST approach.

For example:


http://www.w3.org/2000/xp/Group/2/06/07/edcopy-soap12-part0-with-GET-additio
ns.html#L26854

Shows an example HTTP GET,

    GET /travelcompany.example.org/reservations?code=FT35ZBQ  HTTP/1.1
    Host: travelcompany.example.org
    Accept: text/html, application/soap+xml

The returned envelop contains a UUID reference for the named reservation
code.

Which is all well and good, but a subsequent POST is done to a generic
"Reservations"
resource, and the 'real' resource is referenced using the UUID buried in the
posted envelope,

    POST /Reservations HTTP/1.1
    Host: travelcompany.example.org
    Content-Type: application/soap+xml; charset="utf-8"
    Content-Length: nnnn

    <!--- soap envelope elided -->

I get the sense that most SOAP-base services will continue to simply follow
the path of least resistance and disappear behind generic URLs.







-----------------------------------------------------------------------------------
Post ID:2017
Sender:Dan Brickley <danbri@...>
Post Date/Time:2002-07-30 17:03:32
Subject:Re: [rest-discuss] The SOAP Juggernaut rolls on...
Message:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Jeffrey Winter wrote:
> While it's encouraging to see the WebMethods feature being adopted by SOAP
> 1.2, I question how often a REST architecture will actually be adopted.
> 
> Even the GET examples that are shown in the SOAP spec don't really encourage
> a REST approach.
> 
> For example:
> 
> 
> http://www.w3.org/2000/xp/Group/2/06/07/edcopy-soap12-part0-with-GET-additio
> ns.html#L26854
> 
> Shows an example HTTP GET,
> 
>     GET /travelcompany.example.org/reservations?code=FT35ZBQ  HTTP/1.1
>     Host: travelcompany.example.org
>     Accept: text/html, application/soap+xml
> 
> The returned envelop contains a UUID reference for the named reservation
> code.
> 
> Which is all well and good, but a subsequent POST is done to a generic
> "Reservations"
> resource, and the 'real' resource is referenced using the UUID buried in the
> posted envelope,
> 
>     POST /Reservations HTTP/1.1
>     Host: travelcompany.example.org
>     Content-Type: application/soap+xml; charset="utf-8"
>     Content-Length: nnnn
> 
>     <!--- soap envelope elided -->
> 
> I get the sense that most SOAP-base services will continue to simply follow
> the path of least resistance and disappear behind generic URLs.

Here's an analogy I've been toying with when thinking about the likely 
shape of SOAP 1.2 deployment. POST-only SOAP services may be the HTML 
Frames of the next generation Web.

Just as framed Web sites became popular for a few years after 
frames-capable browsers were deployed, we'll probably see a lot of 
POST-only SOAP services in the near future. But if the REST critique of 
POST-only services is right, we can expect to see these replaced by more 
addressable, GET-accessable SOAP services, just as we saw Frames pretty 
much vanish from mainstream use. Most Web sites don't use HTML Frames, 
because using them turns out to be a pain. The critiques we're hearing 
about POST-only SOAP have a lot in common with the various critiques of 
frames (URIs, addressability etc). Maybe we'll see a similar 
adoption/migration curve...?

Dan

ps. my sense that frames were quite widely adopted and then slowly 
abandoned is based on memory, anecdote etc. Does anyone know of a survey 
that puts hard figures to this claim?







-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9RsblPhXvL3Mij+QRAhh6AJ9TmYrau7XASsOF7e11vb4pgCVDsACdFik/
lACzD6ycTr6MkFrkUniks9c=
=mxqH
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:2018
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-07-30 17:19:23
Subject:Re: [rest-discuss] Coincidence or correspondance?
Message:

Semantic web languages must be global because their underlying data model is
simply the elements and attributes of markup that can be mapped to objects,
whereas
programming languages typically employ markup to hold object mappings.

What it says is that forcing object-property metaphors on web
resources breaks down when pushed too far.

Consider this "property" reference:

    http://foo/bar/baz#xpointer(bookstore//title)

Is this even a "property" at all?  This is a legitamate URI,
but it is essentially a "discovered" property (i.e., resource)
that the base resource implementer could not ever have
anticipated.

It's up to the user of the resource to say what that resource "is".




Simon St. Laurent had this to say recently:
"For years, writing programs has meant identifying a set of structures and
writing code around those structures. Information comes later, and is made
to conform to those structures. (Non-conformant data is often simply
rejected.) Working with markup offers developers a different option, though
one that takes some getting used to: applying labels and structure to data,
perhaps 'painting' on the structure, rather than breaking the data into
strictly pre-defined pieces.

This is a large leap to make, and a path rather different from many of the
data-binding and data-modeling tools offered for developers wanting to use
XML. This approach sees the information and the markup as primary, and not
as a mere serialization of an object, table, or other predefined container.
This approach is more open to non-deterministic styles of markup, and
requires a different style of working with information. Mapping information
between one set of fixed structures and another is a start, but only a small
step." [1]

[1] http://monasticxml.org/humility.html

----- Original Message -----
From: "Paul Prescod" <paul@...>
To: <rest-discuss@yahoogroups.com>
Sent: Tuesday, July 30, 2002 8:47 AM
Subject: [rest-discuss] Coincidence or correspondance?


Warning: abstract theory ahead!

Properties in semantic web languages differ from properties in
programming languages in that they are global. The
http://foo/bar/baz#prop property is the same whether it appears on a
resource of type "X" or a resource of type "Y". but different resources
can support different subsets of the global set of properties.

Methods in REST differ from methods in programming languages in that
they are global. The POST or PROPFIND method are the same whether they
appear on a resource of type "X" or a resource of type "Y".

Is this just a coincidence or a revelation of something deep in the
nature of the web architecture?
--
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/









-----------------------------------------------------------------------------------
Post ID:2019
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-07-30 18:07:16
Subject:Re: [rest-discuss] The SOAP Juggernaut rolls on...
Message:

On Tue, Jul 30, 2002 at 05:03:32PM +0000, Dan Brickley wrote:
> Just as framed Web sites became popular for a few years after 
> frames-capable browsers were deployed, we'll probably see a lot of 
> POST-only SOAP services in the near future. But if the REST critique of 
> POST-only services is right, we can expect to see these replaced by more 
> addressable, GET-accessable SOAP services, just as we saw Frames pretty 
> much vanish from mainstream use. Most Web sites don't use HTML Frames, 
> because using them turns out to be a pain. The critiques we're hearing 
> about POST-only SOAP have a lot in common with the various critiques of 
> frames (URIs, addressability etc). Maybe we'll see a similar 
> adoption/migration curve...?

I'd like to believe that it was this easy, but at least frames were
retrievable without prior coordination.  They broke a handful or
architectural principles, but they didn't try to reinvent the entire
architecture like the vast majority of POST based Web services do.

> ps. my sense that frames were quite widely adopted and then slowly 
> abandoned is based on memory, anecdote etc. Does anyone know of a survey 
> that puts hard figures to this claim?

That's my recollection too, but I don't know of any studies.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2020
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-07-30 18:13:14
Subject:Re: [rest-discuss] The SOAP Juggernaut rolls on...
Message:

>> ps. my sense that frames were quite widely adopted and then slowly
>> abandoned is based on memory, anecdote etc. Does anyone know of a survey
>> that puts hard figures to this claim?

> That's my recollection too, but I don't know of any studies.

Architectural issues aside, the reason that I saw frames being dropped
was a purely pragmatic one: managing state between the different frames
turned out to be so cumbersome that using server-side includes was
actually easier.

The bottom line was, building dynamic websites was easier without frames.
Unfortunately, the exact opposite motivation seems to be at play with SOAP;
the toolkits make it easier to ignore the issues of URI design and simply
deal
with a generic URI.








-----------------------------------------------------------------------------------
Post ID:2021
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-07-30 18:21:49
Subject:RE: [rest-discuss] Coincidence or correspondance?
Message:


> From: Jeffrey Winter [mailto:j.winter@...] 
> 
> It's up to the user of the resource to say what that resource "is".

In a REST system, the naming authority says what resource is named. A
user can only make claims.

regards,
Bill de hra

..
Propylon
www.propylon.com 

 
 







-----------------------------------------------------------------------------------
Post ID:2022
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-07-30 19:21:00
Subject:Searching [was RE: The SOAP Juggernaut rolls on...]
Message:

The bottom line was, building dynamic websites was easier without frames.
Unfortunately, the exact opposite motivation seems to be at play with SOAP;
the toolkits make it easier to ignore the issues of URI design and simply
deal   with a generic URI.

There will come a point in time when there are many publicly accessible
services and finding the right one becomes an issue. The UDDI behemoth is
one way, but I bet Google (or something like it) will have a way of offering
the same functionality through their existing interface.

Having a generic URI means that many functions are going to get slammed into
a single bucket. The REST naming approach has an added advantage that you
can uniquely identify each function using existing URL index/search
technology.

-ramin





-----------------------------------------------------------------------------------
Post ID:2023
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-07-30 20:10:07
Subject:Re: [rest-discuss] Coincidence or correspondance?
Message:

>> It's up to the user of the resource to say what that resource "is".

> In a REST system, the naming authority says what resource is named. A
> user can only make claims.

Paul seemed to be noodling on an interesting observation about the
difference in the scope of properties and methods between web semantic
languages and programming languages.  Properties and methods in
web semantic languages are global; in programming languages (00 languages
anyway) they are typically scoped by the owning resource.

My main point was that this difference really highlights the major
difference between a web seen as a collection of markup that can be
mapped to objects (by the receiver), and a web seen as a collection
of objects that have been mapped to markup (by the sender).
[Here I'm speaking of xml-based services.]

If, when dereferencing a URI, a service chose to provide a deep level of
detail
about the resource, that included subordinate resource (property) details,
it would
be entirely up to me to ignore whatever implied object mapping the sender
had in mind and build up a view of those details that suited me, by say
using
an XPointer fragment in the reference.

I could then send that XPointer reference to somebody else in an email. That
person could dereference the URI that I constructed.  The resource returned
by
that URI may bear little resemblance to what the service provider originally
had in mind.

Granted, I'd be constrained to work with whatever data is provided by a GET
and could only POST/PUT/DELETE in a manner that the service dictates, but
it's up to me to interpret that data to suit my needs.










-----------------------------------------------------------------------------------
Post ID:2024
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-30 20:09:35
Subject:Re: [rest-discuss] The SOAP Juggernaut rolls on...
Message:

Jeffrey Winter wrote:
> 
> While it's encouraging to see the WebMethods feature being adopted by SOAP
> 1.2, I question how often a REST architecture will actually be adopted.

I think that that's up to us. The SOAP juggernaut is mindless. It will
roll happily towards or away from REST as long as everybody can certify
their products "SOAP Compliant." There are still many specs in the web
services world that are not very REST-y but SOAP is the spec with the
most cachet.

>...
> Which is all well and good, but a subsequent POST is done to a generic
> "Reservations"
> resource, and the 'real' resource is referenced using the UUID buried in the
> posted envelope,

I agree that's a problem but there is an example in the primer that is a
little better. Look at "Example 13":

POST /Reservations?name=John%20Q.%20Public HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 <env:Header>
 ...

It still uses a UUID inside which it should not. 

It is not too late to submit suggestions to the SOAP Primer. Here are my
comments that address the prose more than the examples:

 * http://lists.w3.org/Archives/Public/xmlp-comments/2002Jul/0050.html

You could submit some about the examples. UUIDs do not make much sense
even from a pure-SOAP anti-REST point of view because HTTP URIs can have
SOAP messages sent to them but UUIDs cannot. UUIDs only make sense when
you realize that SOAP is supposed to be "transport independent" which
means that you cannot depend upon a reliable addressing model. So you
have to build your own. You can imagine how great that is for
interoperability.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/






-----------------------------------------------------------------------------------
Post ID:2025
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-07-30 20:26:56
Subject:Re: [rest-discuss] The SOAP Juggernaut rolls on...
Message:

Paul Prescod wrote:
> 
>...
> 
> I think that that's up to us. The SOAP juggernaut is mindless. 

Which is not to say that individual SOAP advocates are mindless. The
point is that the spec is outside of the control of individuals. There
is no individual strongly associated with SOAP who can answer questions
about right ways and wrong ways to use it. That's a void that REST
advocates can step into.
-- 
XML, Web Services Architecture, REST Architectural Style
Consulting, training, programming: http://www.constantrevolution.com
Come discuss XML and REST web services at the Extreme Markup Conference






-----------------------------------------------------------------------------------
Post ID:2026
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-07-31 03:10:49
Subject:Re: [rest-discuss] The SOAP Juggernaut rolls on...
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> That's a void that REST advocates can step into.

"..step into.." is definitely the right analogy... just ask "what does a URI
identify?"








-----------------------------------------------------------------------------------
Post ID:2027
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-01 16:06:48
Subject:[fielding@apache.org: Re: httpRange-14 , what's the problem]
Message:

Long, but *well* worth the read.  Every time I talk to Roy, I learn
something new and useful.

MB

----- Forwarded message from "Roy T. Fielding" <fielding@...> -----

Date: Wed, 31 Jul 2002 23:48:05 -0700
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: "www-tag" <www-tag@...>
To: "Tim Berners-Lee" <timbl@...>
From: "Roy T. Fielding" <fielding@...>
In-Reply-To: <031301c23721$5661e5a0$84001d12@...>
Message-Id: <A2224494-A51A-11D6-8895-000393753936@...>
Content-Transfer-Encoding: 7bit
Subject: Re: httpRange-14 , what's the problem
X-Mailing-List: <www-tag@...> archive/latest/1886
Sender: www-tag-request@...
List-Id: <www-tag.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:www-tag-request@...?subject=unsubscribe>
X-Spam-Status: No, hits=-1.8 required=5.0
	tests=IN_REP_TO,DOUBLE_CAPSWORD,PORN_3
	version=2.30
X-Spam-Level: 
Status: O
Content-Length: 34095
Lines: 681


On Monday, July 29, 2002, at 09:59  AM, Tim Berners-Lee wrote:
> http://www.w3.org/DesignIssues/HTTP-URI.html

> Tim Berners-Lee
> Date: 2002-07-27, last change: $Date: 2002/07/31 20:15:46 $
> [...]

>  This question has been addressed only vaguely in the specifications.
>  However, the lack of very concise logical definition of such things had
>  not been a problem, until the formal systems started to use them. There
>  were no formal systems addressing this sort of issue (as far as I know,
>  except for Dan Connolly's Larch work [@@]), until the Semantic Web
>  introduced languages such as RDF which have well-defined logical
>  properties and are used to describe (among other things) web operations.

There has been quite a lot of work outside the W3C regarding the Web
architecture, both in formalisms and mere descriptions.  Google is a
good way to find them, though most are intended more as a way of showing
off the properties of some variation on a formalism than they are of
actually modeling the Web.

>  The efforts of the Technical Architecture Group to create an architecture
>  document with common terms highlighted this problem. (It demonstrates the
>  ambiguity of natural language that no significant problem had been 
> noticed
>  over the past decade, even though the original author or HTTP , and later
>  co-author of HTTP 1.1 who also did his PhD thesis on an analysis of the
>  web, and both of whom have worked with Web protocols ever since, had had
>  conflicting ideas of what the various terms actually mean.)

Tim, when you invented HTTP it only allowed one method (GET), did not
have header fields, and interpreted every response as HTML.  HTTP has
changed considerably over time.

I don't think we have conflicting ideas about the terms.  I think that
the changes introduced in 1995 for the sake of HTTP caching and content
negotiation are absent from your model of how the Web works because we
needed to change the model in order for it to work at all. Furthermore,
the community made a very conscious decision to stop referring to
resources as documents because they simply do not always fit the mental
model of the English word "document".

>  This document explains why the author find it difficult to work in the
>  alternative proposed philosophies. If it misrepresents those others'
>  arguments, then it fails, for which I apologize in advance and will
>  endeavor to correct.
>
> 1. Web Concepts as proposed
>
>  The WWW is a space of information objects. The URI was originally called 
> a
>  UDI, and originally all URIs identified information objects. Now, URI
>  schemes exist which identify more or less anything (eg uuids) or
>  emailboxes (mailto:) but is we look purely at HTTP URIs, they define a 
> web
>  of information objects. Information objects -- perhaps in Cyc terms
>  ConceptualWorks -- are normally things which
>
>  * Carry some sort of message, and

What does that mean?  Information objects are things that carry 
information?
All objects carry information by virtue of having state.

>  * Can be represented, to a greater or lesser authenticity, in bits

Any object's state can be represented in bits.  The state doesn't have
to be stored in bits -- it can merely be observed at the time that a
method is applied.

>  I want to make it clear that such things are generic (See Generic
>  Resources) -- while they are documents, they generally are abstractions
>  which may have many different bit representations, as a function of, for
>  example:
>
>  * Time -- the contents can vary with revision --
>  * Content-type in which the bits are encoded
>  * Natural language in which a human-readable document is written
>  * Machine language in which a machine-processable document is written
>  * and a few more
>
>  but the philosophy is that an HTTP URI may identify something with a
>  vagueness as to the dimensions above, but it still must be used to refer
>  to a unique conceptual object whose various representations have a very
>  large a mount in common. Formally, it is the publisher which defines the
>  what an HTTP URI identifies, and so one should look to the publisher for 
> a
>  commitment as to the exact nature of the identity along these axes.

Yes, no argument there.

>  I'm going to refer to this as a document, because it needs a term and 
> that
>  is the best I have to date, but the reader should be sure to realize that
>  this does not mean a conventional office document, it can be for example
>
>  * A poem
>  * An order for ball bearings
>  * A painting
>  * A Movie
>  * A reveiw of a movie
>  * A sound clip
>  * A record of the temperature of the furnace
>  * An array a million integers, all zero
>
>  and so on, as limited only by our imagination.

None of which are similar to the examples I gave, wherein an http URI
is being used to identify the I/O control-system for a physical robot
or a gateway to SMS-enabled phone devices.  Nor does it lend appropriate
significance to the properties of a Web-enabled refrigerator or a
car radio, both of which I have personally interacted with via HTTP.
It is therefore far more reasonable to refer to the thing identified
by an http URI as a resource that is accessible via HTTP.

>  The Web works because, given an HTTP URI, one can in a large number of
>  cases, get a representation of the document. For a human readable
>  document, the person is presented with the information by virtue of some
>  gadget which is given the bits of a representation. In the case of a
>  hypertext document, a reference to another document is encoded such that,
>  upon user request, the referenced document can in turn be automatically
>  presented. In the case of a machine-readable document, identifiers of
>  concepts, being HTTP URIs, will often allow definitive reference
>  information about those concepts to be pulled in to guide further 
> actions.
>
>  The web, then, is made of documents as the internet is made of cables and
>  routers. The documents can be about anything, so when we move to talk
>  about the contents of documents we break away from talking about
>  information space and the whole universe of human -- and machine --
>  discourse is open to us. Web pages can compare a renaissance choral works
>  with jazz pop hits, and discuss whether pigs have wings.
>  Machine-processable documents can encode information about shoes, and
>  ships, and sealing-wax. Until recently, the Internet protocol standards
>  out of which the Web is built had little to say about such things. They
>  were concerned only with the human-readable side, so it was people,
>  reading natural language (not internet specs) who formed and communicated
>  the concepts at this level. Nowadays, however, semantic web languages
>  allow information to be expressed not only about URIs, TCP ports and
>  documents, but also about arbitrary concepts - the shoes, and ships and
>  sealing wax, and whether pigs have wings. Simple semantic web application
>  allow one to order shoes and travel on ships, and determine that, given
>  the data, pigs do not have wings.
>
>  For these purposes it is of course quite essential to distinguish between
>  something described by a document and the document itself. Now that we -
> -
>  for the first time -- have not only internet protocols which can talk
>  about document but also those which talk about real world things, we must
>  either distinguish or be hopelessly fuzzy.

No argument there either, except that I don't think that this is
anything new.  The solution is to use a formalism that understands
the difference between an identifier and *use* of that identifier.

In order for HTTP caching to work, there needs to be a distinction
between the attributes of a resource (whatever is identified by *any*
scheme accessed via HTTP) and the attributes of one particular
representation of that resource obtained via GET.  Assertions in
the form of HTTP metadata (header fields) are made about each,
independently, and without ambiguity because they are defined by
a shared standard, albeit without syntactic clarity and independent
extensibility due to the limitation of mixing them all together
in a MIME-like header.  Apparently, RDF is capable of the same
distinctions, so there is no technical issue here.

>  And is this bad, is it an inhibition to have to work our way though
>  documents before we can talk about whatever we desire? I would argue not,
>  because it is very important not to lose track of the reasons for our
>  taking and processing any piece of information. The process of publishing
>  and reading is a real social process between social entities, not
>  mechanical agents. To be socially responsible, to be able to handle 
> trust,
>  and so on, we must be aware of these operations. The difference between 
> a
>  car and what some web page says about it is crucial - not only when you
>  are buying a car.

Correct, but in those circumstances we would not be using the "http"
URI to define the identity of the car.  Instead, we use the http URI
to provide access via HTTP to a representation of a car that is ALSO
identified by a VIN (without any URI form being necessary).  A legal
document that would later be drawn up, or even a transaction via
contract passed through a cashier (also identified via a http URI),
would use the VIN for physical identification of the car, not
because it is an inherently better string than one beginning "http:",
but because the VIN has been permanently affixed to the dashboard and
engine block for precisely this purpose.

If car producers wished such a thing, they could all agree to stamp
each car with a unique http URI instead and achieve the same
purpose: unique identification within the class of objects under use.
The fact that we could also use that URI to access information about
that specific car via the Web, which is a different resource from the
car itself, doesn't change the fact that it uniquely identifies the
car within the realm of cars.

However, it is a bit of a waste of time to talk about this in terms
of cars when the real objective, or at least that of the vocal
minority, is to distinguish between the abstract concept of a
namespace and a document describing that namespace.  It is the same
problem, but is easier to think about.  When used within an xmlns
attribute of an XML document, an http URI identifies the namespace.
When used within an xlink:href attribute of an XML document or a
browser's URI entry field or similar construct, an http URI
identifies the namespace by providing a consistent view of that
namespace in the form of representations.

The URI still identifies an unambiguous resource precisely because
we do not say that the result of a GET is the thing that is
identified, and we do not say that the thing identified is a
document just because access is allowed via HTTP by way of documents.
People who use the Web don't care about that difference, but the
technology of distributed caching absolutely depends on it.
In other words, just because a URI only identifies one resource
does not mean that every use of that URI is equivalent, just as
using an http URI as a cache key is not equivalent to using it
as the target of an anchor href.

I say an http resource is a conceptual object that has state and
identity and behavior, just as you define it in your own design notes
prior to getting involved in this debate, but I do not generally refer
to it as an object because all of the OOP developers get hot and
bothered when I do so -- it is a term that is inextricably linked
with a common implementation, just like document is a term that is
inextricably linked to words/images on renderable media.  HTTP is
designed to hide all details of the implementation, so saying http
URI identify resources is the most accurate statement.

>  Some have opined that the abstraction of the document is nonsense, and 
> all
>  that exists, when a web page describes a car, is the car and various
>  representations of it, the HTML, PNG and GIF bit streams. This is however
>  very weak in my opinion. The various representations have much more in
>  common than simply the car. And the relationship to the car can be many
>  and varied: home page, picture, catalog entry, invoice, remote control
>  panel, weblog, and so on. The document itself is an important part of
>  society - to dismiss its existence is to prevent us being aware of human
>  and aspects of information without which we are impoverished. By 
> contrast,
>  the difference between different representations of the document (GIF or
>  PNG image for example) is very small, and the relationship between
>  versions of a document which changes through time a very strong one.

That argument is weird.  No one has opined that the abstraction of
a document is nonsense -- it is merely insufficient to describe all http
resources.  Furthermore, if the same URI is used to identify a resource
whose representations are a home page, picture, catalog entry, invoice,
remote control panel, weblog, and so on, then that URI obviously does
not identify the car.  It might be said to identify a bunch of random
things related to a car of that type, but certainly not the car.

URI in general identify a resource -- one concept, one identity, one
sameness that might be observable via its representations.  The vast
majority of URI do identify documents.  HOWEVER, the architecture is
not defined by what is true of the vast majority -- it is defined by
what is true of ALL resources that fit the given criteria.  And if the
criteria is "all http URI", your definition of "document" simply does
not fit.  That does not in any way prevent people from using unambiguous
identifiers in http or the semantic web, nor does it somehow reduce
the value of a document as an abstraction.

> 2. Trying out the Alternatives
>
>  The folks who disagree with the model do so for a number of different
>  arguments. This article, therefore will have to take them one by one but
>  the ones which come to mind are as follows:

Why didn't you simply refer to the arguments that others made, rather
than your interpretation of what they meant to say?  My messages have
been a lot more carefully worded than this document.

>     1. Every web page (or many of therm) are in fact themselves
>  representations of some abstract thing, and the URI really identifies
>  that thing, not a document at all.

Not *necessarily* a document.

>     2. There are many levels of identification (representation as a set of
>  bits, document, car which the web page is about) and the URI
>  publisher, as owner of the URI, has the right to define it to mean
>  whatever he or she likes;

They can define it to mean anything, but it only has meaning if it is
used according to that definition.  Likewise, it may take on meaning
that wasn't intended by the publisher if it can be consistently used
as such, and may take on a temporary meaning if the temporal period is
sufficient to be usable.  That's because the meaning of a URI is
insignificant when compared to the reason why the reference is
being made (the meaning of the resource in context of its use), and
not all references are made by the publisher of the URI.

It is possible, though not at all desirable, that the meaning of a
resource will at some point differ from the intended meaning that
a person had in mind when they used the URI as a reference.  That
is a well-known problem that will affect the Semantic Web just as
much as it does the current Web.  It is a social problem of any
system that allows identifiers to exist independent of the entity
being identified.  Yes, it has drawbacks, but try identifying a concept
that has no current realization within a system that depends on
the realization for identity.

>     3. Actually the URI has to, like in English, identify these different
>  things ambiguously. Machines have to disambiguate using common sense
>  and logic
>     4. Actually the URI has to, like in English, identify these different
>  things ambiguously. Machines have to disambiguate using the fact that
>  different properties will refer to different levels.
>     5. Actually the URI has to, like in English, identify these different
>  things ambiguously. Machines have to disambiguate using extra
>  information which will be provided in other ways along with the URI
>     6. Actually the URI has to, like in English, identify these different
>  things ambiguously. Machines have to disambiguate them by context: A
>  catalog card will talk about a document. A car catalog will talk about
>  a car.

None of the above.  I have consistently stated that the URI identifies
the same resource as far as the architecture is concerned, even if the
people using that URI are only partially aware of its real sameness
over time, and even if its meaning changes over time.  The only thing
that differs by context is the RESULT of using that URI.  That is the
separation of concerns between methods and identifiers which has been
central to the architecture since HTTP/1.0 was introduced.

>     7. They may have been used to identify documents up till now, but for 
> RDF
>  and the Semantic Web, we should change that and start to use them as
>  the Dublin Core and RDF Core groups have for abstract concepts.

IMO, there is only one Web.

> 2.1 Identify abstract things not documents
>
>  Let's take the alternatives in order. These alternatives all make sense.
>  Each one, however, has problems I can't see any way around when we
>  consider them as a basis as
>
>  The first was,
>
>  Every web page (or many of them) are in fact themselves representations
>  of some abstract thing, and the URI really identifies that thing, not a
>  docuemnt at all.
>
>  Well, that wasn't the model I had when URIs were invented and HTTP was
>  written. However, let's see how it flies. If we stick with the principle
>  that a URI (or URIref) must unambiguously identify the same thing in any
>  context, then we come to the conclusion that URIs can not identify the 
> web
>  page. If a web page is about a car, then the URI can't be used to refer 
> to
>  the web page.

It doesn't identify both.  It identifies the car.  The web page is
what you GET.  The same URI can then be used, in another context, to
indirectly identify a representation that was formerly the result of
a GET (which is what caches do when they lookup a response), but the
cache isn't even remotely confused between the two because we have
defined them as different things.

>  2.1.1 Same URI can identify a web page and a car
>
>  What, a web page can't be a car? At this point a pedantic line reasoning
>  suggests that we should allow web pages and cars to conceptually overlap,
>  so that something can be both. This is counterintuitive, as a web page is
>  in common sense, not a concrete object whereas a car is. But sure, we
>  could construct a mathematics in which we use the terms rather specially
>  and something can be at the same time a web page and a car.
>
>  Frankly, this doesn't serve the social purpose of the semantic web, to be
>  able to deal with common sense concpets and objects. A web page about a
>  car and a car are in most people's minds quite distinct (as I argue
>  further below). A philosophy in which they are identical does not allow 
> me
>  to distinguish between them. not only conflicts with reality as I see it,
>  but also leaves us no way to make statements individually about the two
>  things.

A web page is something that you GET from a resource, not the resource
itself.

The only aspect of this that limits the Semantic Web is that it
cannot pretend the result of a GET and the resource identified by the
URI that was used to perform the GET are necessarily the same thing,
which is a perfectly reasonable thing to require considering that they
aren't even the same thing for time-varying documents, let alone cars.
A URI is an identifier of a resource, not the resource itself.

What is necessary for the Semantic Web is that it be able to distinguish
between resources and representations, and further that it can deal with
the very common situation where the representation has no known URI
by which it can be directly referred, because Web sites deliberately
hide the URI of those resources that they do not wish to be directly
accessible.  [BTW, Content-Location is not a sufficient fix for this
problem simply because the resource provider has no desire to use it.]

>  2.1.2 The URI identifies the car, not the web page
>
>  So lets fall back on the idea that the URI identifies the subject of the
>  web page, but not the web page itself. This makes sense. We can build the
>  semantic web on top of that easily.
>
>  The problem with this is that there are a large number of systems which
>  already do use URIs to identify the document. This is the whole metadata
>  world. Think of a few:
>
>  * The Dublin Core

uses URI to identify abstract concepts (metadata relationships),
indirectly obtain sections of a resource that describes, and identify
other resources that are the target of that relationship.

>  * RSS

uses URI to identify namespaces, indirectly obtain a document
that defines a namespace, and other resources that supply
representations in a given format.

>  * The HTTP headers

refer to the resource, the representation, or the message, depending
on the definition of the header field.

>  * The Adobe XML system

no idea

>  * Access control systems

always refer to the resource.

I don't see any problem.

>  (I'm sticking with the machine-processable languages as examples because
>  human-processable ones like HTML have a level of ambiguity traditional in
>  human natural language but quite out of place in the WWW infrastructure 
> --
>  or the Semantic Web. You can argue that people say "I work for w3.org" or
>  "http://www.amazon.com/shrdlu?asin=314159265359" is a great book, just as
>  they happily say "Moby Dick weighs over three thousand tonnes", "Moby 
> Dick
>  was finished over a century ago" and "I left Moby Dick on the beach"
>  without expecting to be misunderstood. So we won't use human language as 
> a
>  guide when defining unambiguously the question of what a URI identifies.
> )

So you intend to define meaning without reference to humans?  I thought
that the purpose of the Semantic Web was to help humans understand
and operate within the realm of interrelated resources.  What good does
it do if the human is first required to translate their "real world"
reference to one that applies to the less-messy-than-the-real-world
Semantic Web?   I think that is an interface error.

>  Roy Fielding argues the the URI which I associate with his web page
>  actually identifies him.

No, I do not.  I never have.  I even explicitly corrected you on
this very point while we were in your office talking this over.
My home page URI identifies my home page, where I go for a hypertext
representation of the topics that I am working on so that I can
easily jump from there to other resources of interest.  It is a
public resource so that others can do the same.  Some people use
that URI as an indirect way of identifying me, but only in the
sense that the resource contains more information about me.
However, someone could build a system that accepts the URI of a
home page as an indirect identifier of a person and performs some
action based on that relationship that affects me as a person, such
as calling my phone number, just as any identifier can be indirectly
used in ways that are not expected by the identifying authority.

Mark Baker has argued in the past that an http URI does identify
him, but I think that is reasonable since he owns the naming authority.
If you have complete control of the namespace, the identifiers
within it can identify anything provided that you only use them
consistently to identify that thing.  I doubt that is the case for
his home page URI, but it could be for some other URI.

>  He argues that conventionally people use the
>  identifier to identify the person. However, consider another Roy Fielding
>  page put together by freinds who found a photograph of him with no 
> clothes
>  on. A lot of content filtering systems would collect that URI and put put
>  into their list. Even though the photo had many represnetations which
>  different devices could download using content negotiation and/or CC/PP
>  (color orblack and white and variosu different resolutions) the URI 
> istelf
>  would be listed as containing nudity. The public are very aware of
>  different works on the web, even though they have the same topic.

Yikes, what an unpleasant mental picture.  Does that identifier provide
representations of my state, or the state of a nude picture taken at
some particular point in time?  The public is capable of distinguishing
the two over time, and thus those two resources do not have the same
topic/meaning/identity, even though there does exist a relation between
the two.  Fortunately, I don't have "friends" like that.

>  2.2.3 Indirect identification
>
>  You can argue that a web page indirectly identifies something, of course,
>  and I am quite happy with that. If you identify an organization as that
>  which has home page http://www.w3.org, then you are not saying that
>  http://www.w3.org/ itself is that organization. This scenario is very 
> very
>  common, just as we identify people and things by their "unambiguous
>  properties": books by ISBN, people by email address, and so forth. So 
> long
>  as we don't think that the person is an email address, we are fine. Some
>  people have thought that in saying "An HTTP URI can't identify an
>  organization" I was ruling out this indirect identification, but not so:
>  I
>  am very much in favor of it. The whole SQL world, after all, only
>  identified things indirectly by a key property. This causes no
>  contradiction. Perhaps I should say "An HTTP URI can't directly identify
>  an organization". But by "identify" I mean "directly identify", and
>  "identity" is a fairly direct word and concept, so I will stick with it.

Identity is not a fairly direct word and concept -- that is why I posted
a very long description of what it means to www-tag, including its
definition according to webster.com.  If this is the source of our
disagreement, then I give up.  All identifiers are by their very nature
an indirect means to establishing identity.

An http URI, when it is dereferenced, activates a mechanism whereby
the string of characters in the URI is used to select a bag of bits
that is supposed to represent the state of the abstract thing
identified as a resource via the http naming authority.  Does that
imply that the resource is an HTTP mechanism?  No.  The URI is not
the resource, the mechanism is not the resource, and the bag of bits
is not the resource.  Therefore, an http resource is always
restricted to indirect identification.  It is simply impossible to
"directly" identify a resource for which the representation is
allowed to change over time.

Consumers don't give a rat's ass about the mechanism beyond a desire
that it consistently provide representations that match the semantics
they intended by referencing it in the first place.  The semantics
are the resource.  Usually the semantics correspond to a "living
document about a particular subject", but not always.

>  Conclusion so far: the idea that a URI identifies the thing the document
>  is about doesn't work because we can only use a URI to identify one thing
>  and we have and already do use it to identify documents on the web.

No, we use it to obtain documents via the Web by identifying a
resource and asking for a representation of its current state.
We indirectly identify information within the representations,
the web page, by referring to it as the state obtained by doing
a GET on a resource's URI.  All http-based Web pages are only
indirectly identified by http URI, since a Web page is a
representation obtained at an instance in time and not the
resource itself.

> 2.2 Author definition
>
>  So how can we break free of that line of reasoning? We can try throwing
>  away the rule that a URI identifies only one thing.

I don't.

> 2.3 Logic disambiguates
>
>  Otherwise,we have to try another way of letting the URI mean sometimes 
> one
>  thing and sometimes another. Here is another.

Nope, not here either.

> 2.4 Different Properties
>
>  Actually the URI has to, like in English, identify these different
>  things ambiguously. Machines have to disambiguate using the fact that
>  different properties will refer to different levels.

Machines do have to know the realm of identification.  If an identifier
is used for identifying multiple things in the same realm, then it
is clearly ambiguous.  However, if the machine knows that it is using
the URI in a context that is clearly direct, such as xmlns attributes,
then there is no ambiguity just because it is used differently in
other realms.  It is still better though to remain unambiguous, which
is the case for the examples I described.  An xmlns attribute doesn't
access the resource -- it only uses the name of the resource as an
identifier.  Whether or not the same identifier can be used in a GET
is irrelevant to the mechanism of xmlns.

> 2.5 Extra info with URI
>
>  Actually the URI has to, like in English, identify these different
>  things ambiguously. Machines have to disambiguate using extra
>  information which will be provided in other ways along with the URI

No, that twists the argument. The argument is that people use identifiers
in an ambiguous way because there is no such thing as universal agreement
about the semantics of a resource if the publisher does not make those
semantics explicit.  The true nature of a resource cannot be observed at
any instant in time because its definition depends on how much it varies
over time, which is outside the perceptive capacity of humans and
machines.  The publisher can improve understanding of the semantics
of a resource by adding external assertions, but the identity of the
resource itself does not change by those assertions.

> 2.6 Different meaning in different context
>
>  Actually the URI has to, like in English, identify these different
>  things ambiguously. Machines have to disambiguate them by context: A
>  catalog card will talk about a document. A car catalog will talk about a
>  car.

The URI doesn't identify different things in different contexts.  It is,
however, used for different purposes in different contexts.  An xmlns
uses the URI of a resource on the Web (or not) to directly identify a
namespace whose state may (or may not) be indirectly described by a
representation found by performing a GET on the resource identified by
that URI.  There is no ambiguity here.

> 2.7 Change it for the Semantics Web
>
>  They may have been used to identify documents up till now, but for RDF
>  and the Semantic Web, we should change that and start to use them as the
>  Dublin Core and RDF Core groups have for abstract concepts.

There is no need.  In any case, the world doesn't need another AI system
for describing semantic networks in isolation -- they are only useful
when they are allowed to be enmeshed in the real world.

> 2.8 Abandon any identification of abstract things

I can't imagine anything more abstract than an identifier that identifies
"Roy's favorite quote from TimBL", which is bound to change over time.
I refuse to let anyone stick an HTTP server in my head just because that
is the only way to directly identify that resource.  They will have to
make do with a URI that I control, wherein I manage an appropriate
mapping and occasionally drop a bag of bits that represents the
last recorded value of the resource.

> 3. Conclusion
>
>  I didn't have this thought out a few years ago. It has only been in
>  actually building a relatively formal system on top of the web
>  infrastructure that I have had to clarify these concepts my own mind. I 
> am
>  forced to conclude that modeling the HTTP part of the web as a web of
>  abstract documents if the only way to go which is practical and, by the
>  philosophical underpinnings of the WWW, tenable.

I still disagree, particularly since you still haven't described how
you can hold that position for resources that are clearly not documents,
namely the resources that are service gateways to other systems.  POST
does not always mean "append to this document".  Oh, wait ...

>  Q: Some HTTP URIs can be POSTed to. Can you still say they identify
>  documents?
>
>  A: Wel, some HTTP URIs can't be accessed at all, and some access is not
>  allowed, and yes, some URIs are not only documents but also can be posted
>  to. So they object is more complex than simply a document. But that it 
> has
>  this extra functionality doesn't make it any less a HTTP document
>  formally. Something can have extra features and still remain in the same
>  class of things.

That makes no sense to me at all.  There is no stretch of the imagination
that would allow an HTTP POST to a URI that consistently identifies an
HTTP-to-GSM SMS message gateway to be formally equivalent to a document.
REST defines the message to be a representation of a document and the
service to be a resource that consumes representations, resulting in
a state change in the service that is reflected in the response message.
One could claim that the state of all SMS messages flying though the
GSM network is identified by this URI, and that therefore we are only
appending to that state, but that clearly is not the intention of the
publisher of the URI and is not consistent with the result of a GET
on that same URI, and is certainly not useful for reasoning about the
interaction.  It is an invalid model of the system.

Cheers,

Roy T. Fielding, Chief Scientist, Day Software
                  (roy.fielding@...) <http://www.day.com/>

                  Chairman, The Apache Software Foundation
                  (fielding@...)  <http://www.apache.org/>

----- End forwarded message -----






-----------------------------------------------------------------------------------
Post ID:2028
Sender:"Matthew McGehrin" <matthew@...>
Post Date/Time:2002-08-01 18:26:22
Subject:Matthew McGehrin, Sr. SOLARIS/Unix ADMIN, VERITAS, iPLANET, NFS, NT
Message:

Matthew McGehrin, Sr. SOLARIS/Unix ADMIN, VERITAS, iPLANET, NFS, NT
3 Ayer Place � Rutherford, NJ 07070 � (201) 842-0435 � matthew@...

Available immediately for full time, part time, freelance, contract,
on-site, or offsite work in the tri-state area.

Word Version also available:
http://shell.reverse.net/resume/mcgehrin_resume_2002.rtf

PROFESSIONAL SUMMARY

  a.. Six years of administration experience in the areas of networking,
hardware, and software within a dot.com environment.
  b.. Ability to provide technical solutions to business problems..
  c.. Fast learner willing to take on any project.
  d.. Excellent problem solving, troubleshooting, communication, and
organizational skills.
  e.. Supervisory experience.

COMPUTER SKILLS

Software: Sun IPlanet, Apache, IIS, Legato Backup, Perl
Applications: Java Dynamo, Java Resin
Operating Systems: Solaris, xBSD, Linux, Windows, Mac
Databases: Oracle 8, Microsoft SQL
Hardware: Sun Solaris 4500, 420R, 220R, Netra T1; Compaq NT 6400R, 1850R,
DL360; Cisco Pix, Nokia, Checkpoint Firewalls; Arrowpoint, F5 Content; EMC
Clarion, NFS, Samba Storage


EMPLOYMENT

FeedRoom.com, New York, NY � 09/00 � 05/01
Sr. Solaris Administrator

  a.. Worked with Sun Solaris 2.7, 420R, 450; Compaq DL360: EMC Clarion.
  b.. Installed and maintained Sun Solaris Java application servers, as well
as Sun IPlanet Web servers and Apache Web Servers.
  c.. Installed and maintained Sun Solaris Samba/AFD fileservers supporting
Unix, Mac, and NT workstations.
  d.. Acted as NT/2000 administrator, including user creation, e-mail, file
sharing, and backups; administered Cisco Arrow-point load balancers.
  e.. Utilizing Veritas Net backup, performed nightly backups for NT and Sun
platforms.
  f.. Acted as Senior Technical Lead, helping to identify projects, plan
their execution, and play senior role on project management team.
  g.. Designed, executed, and supported infrastructure projects.
  h.. Given responsibility for system monitoring, tuning, troubleshooting,
design, and implementation of disaster recovery procedures.
  i.. Performed software/hardware upgrades as necessary.

LetsPlay.com, New York, NY � 08/99 � 09/00
Sr. Solaris Administrator/Manager

  a.. Worked with Sun Solaris 220R, 420R, 4500, Netra T1; Nokia IP 300;
Arrowpoint CS-100; acted as Administrator for Nokia IP 330 and Cisco
Arrow-point CS-100.
  b.. Installed and maintained Sun Java Dynamo application servers, as well
as Sun IPlanet web servers and Postfix Mail servers receiving daily load of
3 million hits and 25,000 e-mails.
Netamorphosis.com, New York, NY � 12/98 � 07/99
Internet System Administrator
  a.. Worked with Compaq 1850 hardware.
  b.. Maintained multiple Linux Apache web servers for fathersday.com,
mothersday.com, and joc.com, receiving over 30 million hits per month.
  c.. Acted as Firewall Administrator.

Reverse.net, New York, NY � 12/99 - Present
Owner/Unix Administrator

  a.. Act as Owner/Operator/Administrator of an Internet service Provider
specializing in IRC FreeBSD shell accounts for over 100 shell users.
  b.. Hosted in Chicago with 100+ Domains.

IllusionFusion.com, New York, NY � 01/98 � 11/98
Internet System Administrator Manager

  a.. Maintained multiple Solaris Apache web servers for John Deere and
Coca-Cola.
  b.. Maintained several SPARC based systems, optimizing them for DNS and
mail.
  c.. Provide Sales and Marketing support to several major clients,
including John Deere, Coca-Cola, and Wachovia Bank.

Dti.net � 04/97 � 11/97
System Administrator Manager/Network Operations Engineer

  a.. Supervised 2 interns; assisted and trained them while working on Unix
Administration projects.
  b.. Maintained multiple Solaris Apache web servers in an ISP hosting
environment.
  c.. Performed daily maintenance of SMTP, DNS, and http servers.

EDUCATION
Certificate, Computer Programming, Chubb Institute, 1996


References Available Upon Request











-----------------------------------------------------------------------------------
Post ID:2029
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-08-02 01:39:16
Subject:Representations, State and Identity
Message:

Mark, thanks for posting the email between Berners-Lee and Fielding.  
It was very interesting.

    http://groups.yahoo.com/group/rest-discuss/message/2027

One point though that I would like clarification on:  When discussing
caching, he seems to talk about different representations of resources
in terms of versioning.   I infer that he means on a GET, if the underlying 
resource changed, the metadata (entity-tag) should be updated to provide 
hints to caching proxies.

However, different representations of the same resource might be given
based only on the user-agent, and not on a state change.

For example, given a particular URI for a purchase order say:

   http://mysite/po/234

I might send this to a device like a cellphone dereferencing that URI:

    <Purchase xml:base="/po/234">
      <LineItem xlink:href="item1"/>
      <LineItem xlink:href="item2"/>
      <LineItem xlink:href="item3"/>
    </PurchaseOrder>

But I'd want to send all the details to a web browser dereferencing
the same URI:

    <PurchaseOrder xml:base="/po/234">
      <LineItem xlink:href="item1"/>
        <Name>Book One</Name>
        <!-- all the other details -->
      </LineItem>
      <LineItem xlink:href="item2"/>
        <Name>Book Two</Name>
        <!-- all the other details -->
      </LineItem>
      <LineItem xlink:href="item3"/>
        <Name>Book Three</Name>
        <!-- all the other details -->
      </LineItem>
    </PurchaseOrder>

The underlying state of Purchase Order 234 is exactly the
same, but I'm chosing to represent it differently depending
on the circumstances.  

Are these in fact the same resource?  Or do the details of
the HTTP header (in this case the user-agent) become
an implicit part of the resource identifier?

Suppose I wanted to employ caching hints (Etags) along 
with the response, would it even be possible in this 
circumstance given that the cache would need to be 
aware of what kind of response I was returning?










-----------------------------------------------------------------------------------
Post ID:2030
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-08-02 09:08:51
Subject:Re: [rest-discuss] Representations, State and Identity
Message:

Jeffrey Winter wrote:
> Mark, thanks for posting the email between Berners-Lee and Fielding.
> It was very interesting.
>
>     http://groups.yahoo.com/group/rest-discuss/message/2027

ditto.

> [..]
>
> However, different representations of the same resource might be given
> based only on the user-agent, and not on a state change.

i have two suggestions:

first of all, given that one representation is basically a subset of the
other, you could give the web browser representation to the cellphone as
well, and have it omit the line item data it doesn't want to display.
there may be issues with the verbosity of the data, but that's going to
be an issue when you use XML anyway.

failing that, perhaps it is appropriate to try and ensure that you only
have one representation per state change, insofar as you can.

given your example, one way to do this might be to use an include
mechanism (e.g. xinclude) which is (optionally) processed by the client.
therefore the cellphone version could display no child data, but the web
browser could.  i'm not sure how the client 'knows' whether to process
the includes or not though.

-vincent







-----------------------------------------------------------------------------------
Post ID:2031
Sender:"xemplify" <xemplify@...>
Post Date/Time:2002-08-02 15:50:13
Subject:REST nomination
Message:

I nominated REST for the 
"Most Overlooked XML-Related Tool or Technology" category 
in the "2002 XML-Journal Readers' Choice Awards". :)

Voting started today:
http://www.sys-con.com/xml/

- Rob







-----------------------------------------------------------------------------------
Post ID:2032
Sender:Gary Lawrence Murphy <garym@...>
Post Date/Time:2002-08-02 18:31:36
Subject:Re: [rest-discuss] A few thoughts on REST+SOAP
Message:

>>>>> "P" == Paul Prescod <paulp@...> writes:

    P> 2. "PUT and DELETE operations are rarely used, if ever."

    P> I see no reason for that rule. If what you want to accomplish
    P> is semantically equivalent to a PUT or DELETE then why not use
    P> the standardized method for doing it? 

Can I ask a really naiive question?  I've thought about this, but I've
never found any method to actually implement this; is there something
I should know about browsers?

For example, on an academic website project, we needed to allow
professors access to update their personal bio by adding, deleting and
amending descriptions of their papers.  Logically, we'd want to use
POST, DELETE and GET/DELETE/PUT (?) to accomplish these operations,
but so far as I know browsers are only capabile of generating POST or
GET requests.  We instead used the abomination of GET?action=delete

How do I code the HTML A:href to evoke a PUT or DELETE out of Mozilla
and MSIE?  Even if the method is possible and simple, I think there is
your answer: I've used web browsers and built websites for almost a
decade, and _I_ don't know, so I'd hardly expect the average
2yr-experienced webservices designer to know the distinction even
exists.

-- 
Gary Lawrence Murphy <garym@...> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless.  They can only give you answers."(Pablo Picasso)







-----------------------------------------------------------------------------------
Post ID:2033
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-02 18:54:20
Subject:Re: [rest-discuss] A few thoughts on REST+SOAP
Message:

Gary Lawrence Murphy wrote:
> 
>...
> 
> Can I ask a really naiive question?  I've thought about this, but I've
> never found any method to actually implement this; is there something
> I should know about browsers?

No, you're right. I was talking about more of a machine-to-machine
scenario. PUT and DELETE are holes in current Web specifications. HTML
was defined before recent versions of HTTP and has not caught up. XForms
supports PUT which means that XHTML 2.0 will support PUT. I thought we'd
get pushback on DELETE so I didn't push the issue for the current
version of XForms. They think of their job as generating XML documents
so getting GET support was a fight already. DELETE might be beyond the
pale.

Also, you could say that PUT and DELETE are supported in some "browsers"
insofar as they support WebDAV. It's just hard (impossible?) to get at
that functionality from HTML. I agree that's a problem and it would be
great if you decided to make it your personal cause to fix it. ;)

>...
> How do I code the HTML A:href to evoke a PUT or DELETE out of Mozilla
> and MSIE?  Even if the method is possible and simple, I think there is
> your answer: I've used web browsers and built websites for almost a
> decade, and _I_ don't know, so I'd hardly expect the average
> 2yr-experienced webservices designer to know the distinction even
> exists.

Sure, that's a problem. My point to Sam is that people who do know the
distinction should not avoid them for the reasons he describes. Avoiding
them because of browser (or server!) limitations is one thing. Avoiding
them because of ignorance is another thing. But Sam seemed to think we
should avoid them for global consistency reasons as you might in a
relational database. But the methods are inherently mediated on the Web
so you can implement whatever consistency fixups you need in the
handling for the methods.
-- 
XML, Web Services Architecture, REST Architectural Style
Consulting, training, programming: http://www.constantrevolution.com
Come discuss XML and REST web services at the Extreme Markup Conference






-----------------------------------------------------------------------------------
Post ID:2034
Sender:Gary Lawrence Murphy <garym@...>
Post Date/Time:2002-08-03 00:43:59
Subject:Re: [rest-discuss] A few thoughts on REST+SOAP
Message:

Damn.  I was hoping you'd say something cool like

http://www.mysite.org::DELETE/paper/N10243

given this, then, it's safe to say that whether you want to use REST or
XMLRPC, you /still/ need new and custom client software?   Ouch, that
makes REST an even harder sell because the SOAP tools exist.

-- 
Gary Lawrence Murphy <garym@...> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless.  They can only give you answers."(Pablo Picasso)







-----------------------------------------------------------------------------------
Post ID:2035
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-03 03:26:59
Subject:Re: [rest-discuss] A few thoughts on REST+SOAP
Message:

FWIW, I think that both PUT and DELETE support would be visible
principally through the browser itself, not through the content.

What I mean is that you should be able to edit any document that you
GET, and that your browser should expose File->Save and File->Delete.

Amaya's probably the best example of this;

http://www.w3.org/Amaya/User/saving_and_publishing_documents/the_save_command.html#page_body

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2036
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-08-03 17:27:00
Subject:Demo HTTP web-services
Message:

Rest folks,

I just put up a 'demo' server that runs an experimental version of our
NetGlue software. It's currently limited to 5-simultaneous users. I'll up
the count next week. Among other things, you can browse the catalog of
'part' components or directly invoke them via HTTP URLs (with results
returned in XML. Here are some things you can do (some long URLs might
wrap). If you don't use the MSIE browser, you might have to do 'View Source'
to see the XML results.

- INVOKE Google via HTTP URL (provide your own Google key and query):
http://netglue.wizen.com/netglue/factory$Google.GoogleSearch.glu?key={key}&q
={query}
All Google search options are available from the URL.

- HTML DOCUMENTATION for the Google search component (note that there's an
'underline' character before the 'd' parameter i.e. it's '_d=html':
http://netglue.wizen.com/netglue/factory$Google.GoogleSearch.glu?_d=html

- BROWSER INVOKE. Fill in the blanks and hit 'Run' ('_d=html' and
'_mode=run'):
http://netglue.wizen.com/netglue/factory$Google.GoogleSearch.glu?_d=html&_mo
de=run

- XML COMPONENT INTERFACE. Replace the '_d=html' with '_d=xml':
http://netglue.wizen.com/netglue/factory$Google.GoogleSearch.glu?_d=xml

A few other things you can do:

-BROWSE CATALOG IN HTML: http://netglue.wizen.com/netglue/ (then click on
'Catalog' in the toolbar).
-GET CATALOG IN XML: http://netglue.wizen.com/netglue/_g.pxm?_d=xml (that's
'_g.pxm' and '_d=xml').
-GET factory package INTERFACE IN XML:
http://netglue.wizen.com/netglue/factory.glu?_d=xml
-GET Google package IN XML:
http://netglue.wizen.com/netglue/factory$Google.glu?_d=xml
-GET Google search method INTERFACE IN XML:
http://netglue.wizen.com/netglue/factory$Google.GoogleSearch.glu?_d=xml

Replace the 'xml' with 'html' in the above examples to see it in HTML. Also,
feel free to check out the Amazon component under 'E-Commerce'. The above
syntax works for all packages you see there. Format is:

http://.../netglue/PACKAGE$COMPONENT.FUNCTION.glu?[params=values...] (don't
forget the '.glu' before the '?')

If it's not obvious, the catalog is a 'service' registry -- i.e. 'meta-data'
is built-in and can be accessed via the URL. No need for a separate UDDI
server (:-)

Any comments/feedback/suggestions are happily encouraged.

Cheers,
Ramin

P.S. This is just a *demo* box. Please be gentle with it (:-)







-----------------------------------------------------------------------------------
Post ID:2037
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-03 20:43:58
Subject:Re: [rest-discuss] A few thoughts on REST+SOAP
Message:

----- Original Message -----
From: "Gary Lawrence Murphy" <garym@...>

> >>>>> "P" == Paul Prescod <paulp@...> writes:
>
>     P> 2. "PUT and DELETE operations are rarely used, if ever."
>
>     P> I see no reason for that rule. If what you want to accomplish
>     P> is semantically equivalent to a PUT or DELETE then why not use
>     P> the standardized method for doing it?
>
> Can I ask a really naiive question?  I've thought about this, but I've
> never found any method to actually implement this; is there something
> I should know about browsers?

Most browsers aren't going to make it easy. Most of the discussion - at
least for me - is about non-browser systems. An 'automatable Web' as it
were.

In any case, the ideal would be to use HTML FORM element. But that is
disallowed (so I suppose HTML is non-RESTful):
http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.1
===
The method attribute of the FORM element specifies the HTTP method used to
send the form to the processing agent. This attribute may take two values:
  a.. get: With the HTTP "get" method, the form data set is appended to the
URI specified by the action attribute (with a question-mark ("?") as
separator) and this new URI is sent to the processing agent.
  b.. post: With the HTTP "post" method, the form data set is included in
the body of the form and sent to the processing agent.
===

Here is what it /could/ have looked like.
<FORM method='DELETE' action='reports.asp?report=99&annotation=27'>
<input type='submit' value=' Delete this comment '>
</FORM>


The legal workaround would be to use client-side programming via JavaScript
& some component. On IE you could use the XMLHTTPRequest object.

<script>
function doDeleteComment(form,reportId,annotationId)
{
    // this ProgID request MSXML4.dll installed - use a different one to
work with older XML DLLs.
    var http = new ActiveXObject("Msxml2.XMLHTTP.4.0");
    var url;

    url = "reports.asp?report="+reportId+"&annotation="+annotationId;
    http.open("DELETE",url,false,username,password);
    http.send();

    // debugging code...
    alert(http.status + " " + http.statusText + "\n" + http.responseText);

    return false;    // prevents page from refreshing
}
</script>

<FORM method='DELETE' action='reports.asp?report=99&annotation=27'
onSubmit='return doDeleteComment(this,99,27);'>
<input type='submit' value=' Delete this comment '>
</FORM>









-----------------------------------------------------------------------------------
Post ID:2038
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-03 20:50:20
Subject:Re: [rest-discuss] A few thoughts on REST+SOAP
Message:

----- Original Message -----
From: "Gary Lawrence Murphy" <garym@...>

>
> Damn.  I was hoping you'd say something cool like
>
> http://www.mysite.org::DELETE/paper/N10243
>
> given this, then, it's safe to say that whether you want to use REST or
> XMLRPC, you /still/ need new and custom client software?   Ouch, that
> makes REST an even harder sell because the SOAP tools exist.
You've got all the client code you need, on many platforms and in many
languages.
To make it 'programmer friendly' you need a 'toolkit' - something that talks
about objects and not protocols.
So rather than opening a connection and setting a header, etc. etc. you want
something like:

 server = new HttpServer("host.domain.com",username,password);
 server.delete(uri);
 server.put(uri,data);
 data = server.get(uri);
 childId = server.post(parentId,data);

Say the word & I'll write you a handy dandy all-seeing, all-knowing client
in JavaScript using MS's XMLHTTPRequest object. Does Mozilla have an
interface-compatible component like that?








-----------------------------------------------------------------------------------
Post ID:2039
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-03 20:51:17
Subject:Re: [rest-discuss] A few thoughts on REST+SOAP
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>


> FWIW, I think that both PUT and DELETE support would be visible
> principally through the browser itself, not through the content.
>
> What I mean is that you should be able to edit any document that you
> GET, and that your browser should expose File->Save and File->Delete.
>
> Amaya's probably the best example of this;
>
>
http://www.w3.org/Amaya/User/saving_and_publishing_documents/the_save_comman
d.html#page_body
>

Yeah... call it 'Save to the Web' & I'll pay you a dollar...







-----------------------------------------------------------------------------------
Post ID:2040
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-03 21:02:53
Subject:Re: [rest-discuss] Demo HTTP web-services
Message:

----- Original Message -----
From: "Ramin Firoozye" <ramin@...>
To: <rest-discuss@yahoogroups.com>
Sent: Saturday, August 03, 2002 10:27 AM
Subject: [rest-discuss] Demo HTTP web-services


> Rest folks,
>
> I just put up a 'demo' server that runs an experimental version of our
> NetGlue software. It's currently limited to 5-simultaneous users. I'll up
> the count next week. Among other things, you can browse the catalog of
> 'part' components or directly invoke them via HTTP URLs (with results
> returned in XML. Here are some things you can do (some long URLs might
> wrap). If you don't use the MSIE browser, you might have to do 'View
Source'
> to see the XML results.


Cool.

I've got a demo server that does some other HTTP/XML stuff.

http://www.xmldatasource.com

There are two servlets, one to expose NNTP as XML over HTTP, and one for
LDAP. Ancient code...
They both run within a servlet-based framework that helps expose data as
HTTP addressable objects with standard methods and support for Accept header
content negotation. It supports browser-tricks like query args for do:method
and do:accept.
The framework source is at http://xml.apache.org/xang/ if you are
interested.












-----------------------------------------------------------------------------------
Post ID:2041
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-03 23:42:28
Subject:Re: [rest-discuss] A few thoughts on REST+SOAP
Message:

Gary Lawrence Murphy wrote:
> 
> Damn.  I was hoping you'd say something cool like
> 
> http://www.mysite.org::DELETE/paper/N10243
> 
> given this, then, it's safe to say that whether you want to use REST or
> XMLRPC, you /still/ need new and custom client software?   Ouch, that
> makes REST an even harder sell because the SOAP tools exist.

You don't need PUT and DELETE to do REST. They are just handy and more
interoperable than home-grown ways of doing the same thing. If you can
use them (i.e. have no software constraints), you should. If not, you
can survive without them.

My personal opinion is that if they are really important to your app
then you should probably consider all of WebDAV and have support for
WebDAV clients.
-- 
XML, Web Services Architecture, REST Architectural Style
Consulting, training, programming: http://www.constantrevolution.com
Come discuss XML and REST web services at the Extreme Markup Conference






-----------------------------------------------------------------------------------
Post ID:2042
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-08-04 04:25:28
Subject:Re: [rest-discuss] Representations, State and Identity
Message:

> ... do the details of the HTTP header (in this 
> case the user-agent) become an implicit part 
> of the resource identifier?

The answer to this question is perhaps, yes in one 
sense: the server uses the metadata accompanying  
the request to select a particular representation 
to suit the context in which the URI was dereferenced.


As for the specific issue of responding with different
representations depending on the User-Agent and its
effect on caching:

[Vincent D Murphy...]
> i have two suggestions: [ .. details .. ]

Those are reasonable possibilities, but there are 
a couple of other choices:

1. Redirect to User-Agent appropriate hierarchies:

  GET /po/234
  User-Agent: x
    
    for one device might return,

  HTTP/1.1 301 Moved Permanently
  Location: /cellphone/po/234

    and for another,

  HTTP/1.1 301 Moved Permanently
  Location: /browser/po/234

2. Allow all devices to use the same URI but
alert caches that the User-Agent must be
interrogated using the Vary header:

  HTTP/1.1 200 OK
  Vary: User-Agent

  <PurchaseOrder>
    <!-- User-Agent appropriate details -->
  </PurchaseOrder>


The first alternative isn't as aesthetically appealing
as it makes the resource context explicit, but it's
essentially bulletproof; the second, while more pure, 
relies on any caches to understand and apply the Vary
response header appropriately.







-----------------------------------------------------------------------------------
Post ID:2043
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-08-04 06:40:00
Subject:RE: [rest-discuss] Demo HTTP web-services
Message:

Thanks. I'll take a look at Xang. 
I especially like the NNTP one. Good stuff.

Ramin
 
> Cool.
> 
> I've got a demo server that does some other HTTP/XML stuff.
> 
> http://www.xmldatasource.com
> 
> There are two servlets, one to expose NNTP as XML over HTTP, and one for
> LDAP. Ancient code...
> They both run within a servlet-based framework that helps expose data as
> HTTP addressable objects with standard methods and support for 
> Accept header
> content negotation. It supports browser-tricks like query args 
> for do:method
> and do:accept.
> The framework source is at http://xml.apache.org/xang/ if you are
> interested.
> 
> 
> 
> 
> 






-----------------------------------------------------------------------------------
Post ID:2044
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-08-04 13:05:48
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

Just to dig up this old thread:

> > .... In fact, it is *essential* to the Web architecture that URI
> > support at least two other kinds of semantics, namely:
> >
> > * It must be possible to compare URI for equivalence (proxies, etc.)
> >
> > * It must be possible to construct a URI from another complete URI and
> >     a relative URI.
>
> IMO, a web toolkit that properly supports the web/REST model would
> provide a URI object with the following three methods:
>
> uri.dereference(method, headers, representation)
> uri.compare()
> uri.create(base, relative, query_params)

I think it can also be said:

    * It must be possible to associate metadata with a URI

so,

    uri.setMetadata(headers)

This is one other way that web languages differ from programming languages:
Given the same initial state, dereferencing a pointer
in a programming language is going to return the same data;
dereferencing a URI in a web language may return different data
depending on the metadata values associated with it.



- Jeff







-----------------------------------------------------------------------------------
Post ID:2045
Sender:"sjoerd_visscher" <sjoerd@...>
Post Date/Time:2002-08-04 20:28:21
Subject:Re: A few thoughts on REST+SOAP
Message:

> Say the word & I'll write you a handy dandy all-seeing, all-knowing
client
> in JavaScript using MS's XMLHTTPRequest object. Does Mozilla have an
> interface-compatible component like that?

yes.

var xmlhttp = new XMLHttpRequest();

this will give you an object that is compatible with MS's
XMLHTTPRequest object. see http://www.mozilla.org/xmlextras/

Sjoerd Visscher
w3future.com







-----------------------------------------------------------------------------------
Post ID:2046
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-05 03:00:35
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

----- Original Message -----
From: "Jeffrey Winter" <j.winter@...>

>
> I think it can also be said:
>
>     * It must be possible to associate metadata with a URI
>
> so,
>
>     uri.setMetadata(headers)
>
> This is one other way that web languages differ from programming
languages:
> Given the same initial state, dereferencing a pointer
> in a programming language is going to return the same data;
> dereferencing a URI in a web language may return different data
> depending on the metadata values associated with it.
>
I don't look at this as metadata about the URI, but rather metadata about
the request - essentially negotiating the type of information being
exchanged.
Also, I'm not clear what dereferencing means - is it strictly a 'get'?
What about these two pseudo-code examples:
  server.resource(uri) = data;    // does a 'put'
  data = server.resource(uri);    // does a 'get'

Does the 'put' example 'dereference' the uri?







-----------------------------------------------------------------------------------
Post ID:2047
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-05 03:01:42
Subject:Re: [rest-discuss] Re: A few thoughts on REST+SOAP
Message:

----- Original Message ----- 
From: "sjoerd_visscher" <sjoerd@...>

> 
> var xmlhttp = new XMLHttpRequest();
> 
> this will give you an object that is compatible with MS's
> XMLHTTPRequest object. see http://www.mozilla.org/xmlextras/
> 

Very cool - thanks for the info!






-----------------------------------------------------------------------------------
Post ID:2048
Sender:Gary Lawrence Murphy <garym@...>
Post Date/Time:2002-08-05 03:49:11
Subject:Re: [rest-discuss] A few thoughts on REST+SOAP
Message:

Ok, javascript is cool.  I can dig javascript as a way to do this.  So
long as it works portably everywhere (opera, konqueror, lynx ...)  and
it looks like maybe it might, then I'm cool with that.

thanks for the tip.

-- 
Gary Lawrence Murphy <garym@...> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless.  They can only give you answers."(Pablo Picasso)







-----------------------------------------------------------------------------------
Post ID:2049
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-05 05:27:42
Subject:Re: [rest-discuss] Demo HTTP web-services
Message:

----- Original Message -----
From: "Ramin Firoozye" <ramin@...>


> Thanks. I'll take a look at Xang.
Just keep in mind that it was written several years ago. The code is split
into two parts : a framework and an application. The NTTP and LDAP examples
on www.xmldatasource.com are apps within the framework. The Xang project is
another application meant to let people write apps in xml and javascript (or
any scripting language). The XML file mapped URLs to code snippets to handle
the HTTP methods. I've included an example below. The URI path was used to
locate an xml element that had attributes for the http methods. This
wouldn't be realistic for deeply nested paths, but I was working with some
'virtual DOM' technology at the time which would 'hook' the XML DOM and
expose arbitrary data sources as DOM nodes, so the addressing would just
drift into whatever data source you had a plug-in for. Each node inherited
behavior from parent nodes, so you could easily code behavior for large
numbers of data elements. Anyway... the virtual DOM technology never really
materialized (that's an RDBMS joke by the way...) but the framework part of
the code was independent and the XML application page part is still useful
without it.
There was no support for rendering or data sources. That idea was that with
a virtual DOM, you just pick a stylesheet based on the output format the
client requested, and the data sources were linked via code plug-ins.
Without a virtual DOM, you have to acquire the data and transform it
yourself.

Anyway... maybe you can salvage some code or some ideas...



--sample.xap--
<root>

 <!-- include some common code -->
<script xml:link='include' src='system.script.xml' >  </script>

<script>
function listOrders(context,returnTypes,parameters)
{
    var doc = context.response.writer;
    context.response.contentType = "text/xml";
    doc.println("<list>");
    doc.println("</list>");
}
function listPendingOrders(context,returnTypes,parameters)
{
    var list;
    list = DB.getPendingOrders(parameters.get("accountId"));
    // stuff...
}

</script>

<!-- the path-based URI handlers -->
<tag name='orders' onGet='listOrders();' onPost='addOrder()'>
    <tag name='pending' onGet='listPendingOrders();' />
</tag>

</root>








-----------------------------------------------------------------------------------
Post ID:2050
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-08-05 12:41:50
Subject:Doing an HTTP PUT from HTML?
Message:

Hi Folks,

The following question actually has a lot to do with REST, although it
may not seem so.  Once I get my tutorial completed I will show how it
all fits in with REST.  But for now, here's the question:

I would like to create a REST resource which serves up XML and receives
XML.  For those clients at a browser the XML will be styled into HTML
via an XSLT stylesheet.  Suppose that this styling results in an HTML
form that the user fills in to create a Purchase Order.  After the user
fills in the form he presses "Submit".  I would like for the Submit
action to result in kicking off some script which harvests the data in
the HTML form, create an XML string from the form data, and then HTTP
PUTs the XML string back to the resource.  That's where I am stuck.  I
know how to write some Javascript to harvest the form data and create an
XML string, but I don't know how to then HTTP PUT the XML string to the
resource (i.e., server).  Any ideas?  /Roger







-----------------------------------------------------------------------------------
Post ID:2051
Sender:Dan Brickley <danbri@...>
Post Date/Time:2002-08-05 13:37:44
Subject:Re: [rest-discuss] Doing an HTTP PUT from HTML?
Message:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Roger L. Costello wrote:
> Hi Folks,
> 
> The following question actually has a lot to do with REST, although it
> may not seem so.  Once I get my tutorial completed I will show how it
> all fits in with REST.  But for now, here's the question:
> 
> I would like to create a REST resource which serves up XML and receives
> XML.  For those clients at a browser the XML will be styled into HTML
> via an XSLT stylesheet.  Suppose that this styling results in an HTML
> form that the user fills in to create a Purchase Order.  After the user
> fills in the form he presses "Submit".  I would like for the Submit
> action to result in kicking off some script which harvests the data in
> the HTML form, create an XML string from the form data, and then HTTP
> PUTs the XML string back to the resource.  That's where I am stuck.  I
> know how to write some Javascript to harvest the form data and create an
> XML string, but I don't know how to then HTTP PUT the XML string to the
> resource (i.e., server).  Any ideas?  /Roger

I thought XForms might have something to say on this -- but after a 
rather quick look at the spec I can't see anything.

http://www.w3.org/TR/xforms/

	[[
	XForms is an XML application that represents the next generation
	of Forms for the Web. By splitting traditional XHTML forms into
	three parts - data model, instance data, and user interface -
	it separates presentation from content, allows reuse, gives
	strong typing - reducing the number of round-trips to the
	server, as well as offering device independence and
	a reduced need for scripting.
	
	XForms is not a free-standing document type, but is intended to
	be integrated into other markup languages, such as XHTML.
	]]

Guess this doesn't answer your question Roger, but I'd be interested to 
hear if anyone here has looked into using XForms, and how it fits with 
the REST perspective.

cheers,

Dan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9Tn+uPhXvL3Mij+QRAs9wAJ0bY/0AaOER2bj+USwfDRnGWtrYrwCgqzi5
vEzGGuLWf+FltyIYwqPxh5k=
=y3d3
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:2052
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-08-05 13:19:01
Subject:Re: [rest-discuss] Doing an HTTP PUT from HTML?
Message:

> but I don't know how to then HTTP PUT the XML 
> string to the resource (i.e., server).

As S. Mike Dierken pointed out

  http://groups.yahoo.com/group/rest-discuss/message/2037

straight HTML doesn't even support it, but you can 
use the same XMLHTTPRequest (Microsoft) or XMLHttpRequest (Mozilla) 
object that he has been discussing to do a PUT.

I don't think there is any truly cross-platform way
of doing it at the present.

----- Original Message ----- 
From: "Roger L. Costello" <costello@...>
To: <rest-discuss@yahoogroups.com>
Cc: "Costello,Roger L." <costello@...>
Sent: Monday, August 05, 2002 8:41 AM
Subject: [rest-discuss] Doing an HTTP PUT from HTML?


Hi Folks,

The following question actually has a lot to do with REST, although it
may not seem so.  Once I get my tutorial completed I will show how it
all fits in with REST.  But for now, here's the question:

I would like to create a REST resource which serves up XML and receives
XML.  For those clients at a browser the XML will be styled into HTML
via an XSLT stylesheet.  Suppose that this styling results in an HTML
form that the user fills in to create a Purchase Order.  After the user
fills in the form he presses "Submit".  I would like for the Submit
action to result in kicking off some script which harvests the data in
the HTML form, create an XML string from the form data, and then HTTP
PUTs the XML string back to the resource.  That's where I am stuck.  I
know how to write some Javascript to harvest the form data and create an
XML string, but I don't know how to then HTTP PUT the XML string to the
resource (i.e., server).  Any ideas?  /Roger


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 









-----------------------------------------------------------------------------------
Post ID:2053
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-08-05 13:33:50
Subject:Re: URI Opacity was Re: [rest-discuss] Amazon & Google & REST
Message:

> I don't look at this as metadata about the URI, 
> but rather metadata about the request 

I have to agree.  That's a much better way of looking at it.

> Also, I'm not clear what dereferencing means - is 
> it strictly a 'get'?
> What about these two pseudo-code examples:
>  server.resource(uri) = data;    // does a 'put'
>  data = server.resource(uri);    // does a 'get'
>
> Does the 'put' example 'dereference' the uri?

IMO a PUT like a GET does dereference, basically because 
either way the resource's state is being exposed

And while you could have something along the lines of
>  server.resource(uri) = data;    // does a 'put'
>  data = server.resource(uri);    // does a 'get'
as defaults, for completeness you'd need to be able to 
override any default headers too
>  server.resource(uri, headers) = data;    // does a 'put'
>  data = server.resource(uri, headers);    // does a 'get'








-----------------------------------------------------------------------------------
Post ID:2054
Sender:Philip Eskelin <philip@...>
Post Date/Time:2002-08-05 14:17:22
Subject:Re: [rest-discuss] Doing an HTTP PUT from HTML?
Message:

My approach (with the toolkit I'm just about finished
implementing) is to create a server-side filter that
takes the key-value pairs in the incoming POST entity
body, translates it to XML, and forwards the request
to the next filter in the chain.  The same occurs for
the response.

This approach insures that the client and server will
operate in a RESTful yet more decoupled manner.

Roger Costello <costello@...> wrote:
> I would like to create a REST resource which serves
> up XML and receives XML. For those clients at a 
> browser the XML will be styled into HTML
> via an XSLT stylesheet.  Suppose that this
> styling results in an HTML form that the user fills
> in to create a Purchase Order.
[snip]

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com






-----------------------------------------------------------------------------------
Post ID:2055
Sender:"Uther, James" <james.uther@...>
Post Date/Time:2002-08-05 14:24:15
Subject:RE: [rest-discuss] Doing an HTTP PUT from HTML?
Message:

> I would like to create a REST resource which serves up XML and 
> receives XML.  For those clients at a browser the XML will be styled 
> into HTML via an XSLT stylesheet.  Suppose that this styling results 
> in an HTML form that the user fills in to create a Purchase Order.  
> After the user fills in the form he presses "Submit".  I would like 
> for the Submit action to result in kicking off some script which 
> harvests the data in the HTML form, create an XML string from the form 
> data, and then HTTP PUTs the XML string back to the resource.
> That's where I am stuck.  I know how to write some Javascript 
> to harvest the form data and create an XML string, but I 
> don't know how to then HTTP PUT the XML string to the 
> resource (i.e., server).  Any ideas?  /Roger

Hi Roger,

  People are free to correct me here (it's been a while), but: no browsers
support HTTP PUT. I've done it before by writing an applet using a recent
version of java and calling that from javascript. Essentially you're using
the java.net.HttpURLConnection as an alternate HTTP implementation, because
it *does* support PUT.

Of course, I ended up moving over to POST because hacking the server to
support PUT was not allowed... This was a few years ago when we didn't have a
nicely documented framework from which to argue for such things :)

cheers,

james






-----------------------------------------------------------------------------------
Post ID:2056
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-05 15:24:27
Subject:Re: [rest-discuss] Doing an HTTP PUT from HTML?
Message:

rom: "Uther, James" <james.uther@...>
>
>   People are free to correct me here (it's been a while), but: no browsers
> support HTTP PUT.

I don't know about the other ones, but I know that in IE6, PUT is internally
substituted with GET instead.  How do you like them apples!  Frankly, I
would have preferred it giving me an error than changing the meaning of my
request...

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2057
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-08-05 17:00:01
Subject:RE: [rest-discuss] Doing an HTTP PUT from HTML?
Message:

Hi Roger,

How about this?

The HTTPURLConnection java class can submit a PUT request method. If you
compile it into an applet, then you can invoke the applet in the browser and
pass the form data down to it. The applet doesn't need any visual
representation. It can sit behind the scenes ready for invocation via
Javascript. The only thing is that the URL you are PUTting to should be on
the same machine the Applet is coming from (for applet sercurity reasons).
If you need the Java code for the PUT class, holler and I'll be happy to
post it.

The other way is to use a server 'redirector' that does it for you. That
might be more flexible.

Cheers,
Ramin

 -----Original Message-----
From: Roger L. Costello [mailto:costello@...]
Sent: Monday, August 05, 2002 5:42 AM
To: rest-discuss@yahoogroups.com
Cc: Costello,Roger L.
Subject: [rest-discuss] Doing an HTTP PUT from HTML?


  Hi Folks,

  The following question actually has a lot to do with REST, although it
  may not seem so.  Once I get my tutorial completed I will show how it
  all fits in with REST.  But for now, here's the question:

  I would like to create a REST resource which serves up XML and receives
  XML.  For those clients at a browser the XML will be styled into HTML
  via an XSLT stylesheet.  Suppose that this styling results in an HTML
  form that the user fills in to create a Purchase Order.  After the user
  fills in the form he presses "Submit".  I would like for the Submit
  action to result in kicking off some script which harvests the data in
  the HTML form, create an XML string from the form data, and then HTTP
  PUTs the XML string back to the resource.  That's where I am stuck.  I
  know how to write some Javascript to harvest the form data and create an
  XML string, but I don't know how to then HTTP PUT the XML string to the
  resource (i.e., server).  Any ideas?  /Roger


        Yahoo! Groups Sponsor
              ADVERTISEMENT



  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.






-----------------------------------------------------------------------------------
Post ID:2058
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-08-05 17:08:19
Subject:RE: [rest-discuss] Doing an HTTP PUT from HTML?
Message:

Wow! That's the silliest thing I've ever heard a browser do.
How did you test that?
  -----Original Message-----
  From: Seairth Jacobs [mailto:seairth@...]
  Sent: Monday, August 05, 2002 8:24 AM
  To: rest-discuss
  Subject: Re: [rest-discuss] Doing an HTTP PUT from HTML?


  rom: "Uther, James" <james.uther@...>
  >
  >   People are free to correct me here (it's been a while), but: no
browsers
  > support HTTP PUT.

  I don't know about the other ones, but I know that in IE6, PUT is
internally
  substituted with GET instead.  How do you like them apples!  Frankly, I
  would have preferred it giving me an error than changing the meaning of my
  request...

  ---
  Seairth Jacobs
  seairth@...


        Yahoo! Groups Sponsor
              ADVERTISEMENT



  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.






-----------------------------------------------------------------------------------
Post ID:2059
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-05 17:33:16
Subject:Re: [rest-discuss] Doing an HTTP PUT from HTML?
Message:

Simple HTML Form, where METHOD="PUT".  :)  Okay, it may not be a really good/reliable test, but I was surprised at the outcome.  If anything, I would have expected it to treat the PUT as a POST (which still would have been wrong, IMHO).  I think the reason that GET is used is because it's the "default" value of the METHOD attribute [1].  I guess they figure that if an invalid value is given, then use the default value instead.

And as for how I knew it was converted to a GET, I have a server-side ISAPI extension that dumps the entire request to a file for debugging purposes.

[1] http://www.w3.org/TR/html4/interact/forms.html#edef-FORM

---
Seairth Jacobs
seairth@seairth.com

  ----- Original Message ----- 
  From: Ramin Firoozye 
  To: Seairth Jacobs ; rest-discuss 
  Sent: Monday, August 05, 2002 1:08 PM
  Subject: RE: [rest-discuss] Doing an HTTP PUT from HTML?


  Wow! That's the silliest thing I've ever heard a browser do. 
  How did you test that?
    -----Original Message-----
    From: Seairth Jacobs [mailto:seairth@seairth.com]
    Sent: Monday, August 05, 2002 8:24 AM
    To: rest-discuss
    Subject: Re: [rest-discuss] Doing an HTTP PUT from HTML?


    rom: "Uther, James" <james.uther@...>
    >
    >   People are free to correct me here (it's been a while), but: no browsers
    > support HTTP PUT.

    I don't know about the other ones, but I know that in IE6, PUT is internally
    substituted with GET instead.  How do you like them apples!  Frankly, I
    would have preferred it giving me an error than changing the meaning of my
    request...

    ---
    Seairth Jacobs
    seairth@...



    To unsubscribe from this group, send an email to:
    rest-discuss-unsubscribe@yahoogroups.com



    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


        Yahoo! Groups Sponsor 
              ADVERTISEMENT
             
       

  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 






-----------------------------------------------------------------------------------
Post ID:2060
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-08-05 17:34:59
Subject:Re: [rest-discuss] Doing an HTTP PUT from HTML?
Message:

Hi Dan,

I raised [1] an issue [2] about this a while back. Were you looking at the
latest editors' drafts?

Cheers,

1. http://lists.w3.org/Archives/Public/www-forms-editor/2002Jan/0007.html
2.
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#resoluti
on7 [member-only]



----- Original Message -----
From: "Dan Brickley" <danbri@...>
To: "Roger L. Costello" <costello@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Monday, August 05, 2002 6:37 AM
Subject: Re: [rest-discuss] Doing an HTTP PUT from HTML?


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Roger L. Costello wrote:
> > Hi Folks,
> >
> > The following question actually has a lot to do with REST, although it
> > may not seem so.  Once I get my tutorial completed I will show how it
> > all fits in with REST.  But for now, here's the question:
> >
> > I would like to create a REST resource which serves up XML and
receives
> > XML.  For those clients at a browser the XML will be styled into HTML
> > via an XSLT stylesheet.  Suppose that this styling results in an HTML
> > form that the user fills in to create a Purchase Order.  After the
user
> > fills in the form he presses "Submit".  I would like for the Submit
> > action to result in kicking off some script which harvests the data in
> > the HTML form, create an XML string from the form data, and then HTTP
> > PUTs the XML string back to the resource.  That's where I am stuck.  I
> > know how to write some Javascript to harvest the form data and create
an
> > XML string, but I don't know how to then HTTP PUT the XML string to
the
> > resource (i.e., server).  Any ideas?  /Roger
>
> I thought XForms might have something to say on this -- but after a
> rather quick look at the spec I can't see anything.
>
> http://www.w3.org/TR/xforms/
>
> [[
> XForms is an XML application that represents the next generation
> of Forms for the Web. By splitting traditional XHTML forms into
> three parts - data model, instance data, and user interface -
> it separates presentation from content, allows reuse, gives
> strong typing - reducing the number of round-trips to the
> server, as well as offering device independence and
> a reduced need for scripting.
>
> XForms is not a free-standing document type, but is intended to
> be integrated into other markup languages, such as XHTML.
> ]]
>
> Guess this doesn't answer your question Roger, but I'd be interested to
> hear if anyone here has looked into using XForms, and how it fits with
> the REST perspective.
>
> cheers,
>
> Dan
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE9Tn+uPhXvL3Mij+QRAs9wAJ0bY/0AaOER2bj+USwfDRnGWtrYrwCgqzi5
> vEzGGuLWf+FltyIYwqPxh5k=
> =y3d3
> -----END PGP SIGNATURE-----
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:2061
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-08-05 17:45:12
Subject:Re: [rest-discuss] Doing an HTTP PUT from HTML?
Message:

> Wow! That's the silliest thing I've ever heard a browser do. 
> How did you test that?

Both IE and Mozilla convert anything that's not a POST into a GET.  
I had tested this against both IIS and Tomcat. And just to make sure 
it wasn't the server logic itself converting for your convenience,
I checked it outbound from the client using the apache TcpTunnelGui
utility and it's definitely the client doing the conversion.








-----------------------------------------------------------------------------------
Post ID:2062
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-08-05 17:48:00
Subject:Re: [rest-discuss] Doing an HTTP PUT from HTML?
Message:

There should also be a "delete". :_)

- winter

----- Original Message ----- 
From: "Mark Nottingham" <mnot@...>
To: "Roger L. Costello" <costello@...>; "Dan Brickley" <danbri@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Monday, August 05, 2002 1:34 PM
Subject: Re: [rest-discuss] Doing an HTTP PUT from HTML?


Hi Dan,

I raised [1] an issue [2] about this a while back. Were you looking at the
latest editors' drafts?

Cheers,

1. http://lists.w3.org/Archives/Public/www-forms-editor/2002Jan/0007.html
2.
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#resoluti
on7 [member-only]



----- Original Message -----
From: "Dan Brickley" <danbri@...>
To: "Roger L. Costello" <costello@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Monday, August 05, 2002 6:37 AM
Subject: Re: [rest-discuss] Doing an HTTP PUT from HTML?


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Roger L. Costello wrote:
> > Hi Folks,
> >
> > The following question actually has a lot to do with REST, although it
> > may not seem so.  Once I get my tutorial completed I will show how it
> > all fits in with REST.  But for now, here's the question:
> >
> > I would like to create a REST resource which serves up XML and
receives
> > XML.  For those clients at a browser the XML will be styled into HTML
> > via an XSLT stylesheet.  Suppose that this styling results in an HTML
> > form that the user fills in to create a Purchase Order.  After the
user
> > fills in the form he presses "Submit".  I would like for the Submit
> > action to result in kicking off some script which harvests the data in
> > the HTML form, create an XML string from the form data, and then HTTP
> > PUTs the XML string back to the resource.  That's where I am stuck.  I
> > know how to write some Javascript to harvest the form data and create
an
> > XML string, but I don't know how to then HTTP PUT the XML string to
the
> > resource (i.e., server).  Any ideas?  /Roger
>
> I thought XForms might have something to say on this -- but after a
> rather quick look at the spec I can't see anything.
>
> http://www.w3.org/TR/xforms/
>
> [[
> XForms is an XML application that represents the next generation
> of Forms for the Web. By splitting traditional XHTML forms into
> three parts - data model, instance data, and user interface -
> it separates presentation from content, allows reuse, gives
> strong typing - reducing the number of round-trips to the
> server, as well as offering device independence and
> a reduced need for scripting.
>
> XForms is not a free-standing document type, but is intended to
> be integrated into other markup languages, such as XHTML.
> ]]
>
> Guess this doesn't answer your question Roger, but I'd be interested to
> hear if anyone here has looked into using XForms, and how it fits with
> the REST perspective.
>
> cheers,
>
> Dan
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE9Tn+uPhXvL3Mij+QRAs9wAJ0bY/0AaOER2bj+USwfDRnGWtrYrwCgqzi5
> vEzGGuLWf+FltyIYwqPxh5k=
> =y3d3
> -----END PGP SIGNATURE-----
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 









-----------------------------------------------------------------------------------
Post ID:2063
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-08-05 17:51:01
Subject:RE: [rest-discuss] Doing an HTTP PUT from HTML?
Message:

> Both IE and Mozilla convert anything that's not a POST into a GET.  
> I had tested this against both IIS and Tomcat. And just to make sure 
> it wasn't the server logic itself converting for your convenience,
> I checked it outbound from the client using the apache TcpTunnelGui
> utility and it's definitely the client doing the conversion.
> 

Hmm. I'm guessing one started it and the other decided to be 
'compatible' (even if it made no sense).

Someone ought to go over and fix up Mozilla (and add a 'delete' 
too, while they're at it...)







-----------------------------------------------------------------------------------
Post ID:2064
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-05 17:54:29
Subject:Data vs. Resource
Message:

I have been thinking some more about variations on the PO example(s)
discussed recently.  One of the questions I am grappling with is:

    At what point does mere data become an actual resource?


For instance, I gave a model in which only URIs were posted and all
resources were acquired through GETs.  In this model, there is no such thing
as "sending data" via POST.  In terms of the PO example, only the URI to a
PO resource was sent to the vendor.

However, Roger Costello was working on a tutorial where he wanted to have a
vendor present an HTML form that a user would fill in.  This form would POST
the PO to the server.  In this case, that same PO is considered to be
nothing more than "data".

So, here we have potentially two identical blocks of data.  In the first
instance, it is a resource (really, representation of a resource)
identifiable by a URI and in the second instance, it is merely data.  Why is
it that the second instance is not considered a resource, or even a
representation of a resource?  Must a resource have an associated URI?  Is
it okay to push a representation of a resource (POST) instead of pull a
representation of a resource (GET)?  And if so, then what does it mean to
send a representation of a resource to another resource?


---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2065
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-08-05 18:48:44
Subject:RE: [rest-discuss] Demo HTTP web-services
Message:

Mike,

I already have an LDAP service in the works, but I hadn't thought of doing
NNTP.
I can just see enabling posting to NNTP via a web-service.
Spam multiplication factor x 100 (:-)

Thanks for the link.
  -----Original Message-----
  From: S. Mike Dierken [mailto:mdierken@...]
  Sent: Sunday, August 04, 2002 10:28 PM
  To: rest-discuss@yahoogroups.com; Ramin Firoozye
  Subject: Re: [rest-discuss] Demo HTTP web-services



  ----- Original Message -----
  From: "Ramin Firoozye" <ramin@...>


  > Thanks. I'll take a look at Xang.
  Just keep in mind that it was written several years ago. The code is split
  into two parts : a framework and an application. The NTTP and LDAP
examples
  on www.xmldatasource.com are apps within the framework. The Xang project
is
  another application meant to let people write apps in xml and javascript
(or
  any scripting language). The XML file mapped URLs to code snippets to
handle
  the HTTP methods. I've included an example below. The URI path was used to
  locate an xml element that had attributes for the http methods. This
  wouldn't be realistic for deeply nested paths, but I was working with some
  'virtual DOM' technology at the time which would 'hook' the XML DOM and
  expose arbitrary data sources as DOM nodes, so the addressing would just
  drift into whatever data source you had a plug-in for. Each node inherited
  behavior from parent nodes, so you could easily code behavior for large
  numbers of data elements. Anyway... the virtual DOM technology never
really
  materialized (that's an RDBMS joke by the way...) but the framework part
of
  the code was independent and the XML application page part is still useful
  without it.
  There was no support for rendering or data sources. That idea was that
with
  a virtual DOM, you just pick a stylesheet based on the output format the
  client requested, and the data sources were linked via code plug-ins.
  Without a virtual DOM, you have to acquire the data and transform it
  yourself.

  Anyway... maybe you can salvage some code or some ideas...



  --sample.xap--
  <root>

  <!-- include some common code -->
  <script xml:link='include' src='system.script.xml' >  </script>

  <script>
  function listOrders(context,returnTypes,parameters)
  {
      var doc = context.response.writer;
      context.response.contentType = "text/xml";
      doc.println("<list>");
      doc.println("</list>");
  }
  function listPendingOrders(context,returnTypes,parameters)
  {
      var list;
      list = DB.getPendingOrders(parameters.get("accountId"));
      // stuff...
  }

  </script>

  <!-- the path-based URI handlers -->
  <tag name='orders' onGet='listOrders();' onPost='addOrder()'>
      <tag name='pending' onGet='listPendingOrders();' />
  </tag>

  </root>



        Yahoo! Groups Sponsor
              ADVERTISEMENT



  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.






-----------------------------------------------------------------------------------
Post ID:2066
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-08-05 18:49:22
Subject:Web service usage scenarios
Message:

W3C has come up with some 40 usage scenarios for web-services.
<http://www.w3.org/TR/ws-arch-scenarios/>

Any thought on how many the REST approach can cover? 
(and shouldn't they be hearing about it? (:-)

Ramin







-----------------------------------------------------------------------------------
Post ID:2067
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-08-06 12:32:07
Subject:A Sane Approach to Migrating to Web Services
Message:

Hi Folks,

I have written a paper[1] on migrating applications to Web
services.  In a nutshell, here's what the paper says:

Don't use SOAP, WSDL, or UDDI!  Instead, use these:

      - Stand up Web services that receive and reply with standardized
        XML vocabularies (create standard XML vocabularies for 
        your domain).  
      - Describe your Web services using HTML. 
      - Use standard search engines - Google, Yahoo, etc - to search for
        services. 

If you do this then you have taken a big and important step.

SOAP, WSDL, and UDDI are very immature, in a state of flux, and have
many crippling weaknesses. I believe that they will be short-lived and
will be replaced by superior technologies.  

For today, it is "good enough" to just exchange (standards-based) XML
messages, to use HTML to describe services, and to use standard search
engines to find services.  

Comments welcome. /Roger

[1] http://www.xfront.com/MigratingToWebServices.html







-----------------------------------------------------------------------------------
Post ID:2068
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-06 14:37:12
Subject:Re: [rest-discuss] A Sane Approach to Migrating to Web Services
Message:

>       - Describe your Web services using HTML. 

actually, you'll want to use RDF to describe the web service.  We want 
machines to be able to interact with these services autonomously.  HTML 
can't actually say anything about the objects that you are talking 
about.  Humans read HTML, machines read RDF.

>       - Use standard search engines - Google, Yahoo, etc - to search for
>         services. 

That's a cool point.  That plus RDF to describe the service can really work.

Seth





-----------------------------------------------------------------------------------
Post ID:2069
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-06 14:43:59
Subject:Re: [rest-discuss] Data vs. Resource
Message:

> However, Roger Costello was working on a tutorial where he wanted to have a
> vendor present an HTML form that a user would fill in.  This form would POST
> the PO to the server.  In this case, that same PO is considered to be
> nothing more than "data".

It might be easier to use JavaScript to take the Form data, make an XML 
document out of it, and use XMLHttpConnection (or whatever that 
JavaScript object is called) to PUT that XML document.

You're right in that every resource should have a URI.  There has been 
discussion here on this list regarding how that URI is created.  Since 
this information is coming from a browser, which cannot host resources, 
this issue is hard.  One solution is to use UUIDs to provide a unique 
identifier for the resource.  A UUID is unique over time and space.  And 
because URIs should be opaque to the end user, a URI can easily be built 
from a UUID.  That way, the client has decided on the resource name, and 
can assume it has not clashed with a current resource name.

Another benefit of the client creating the resource name is that it 
always knows this resource name.  So it can continue to check that URI 
via GET for its latest status.

Seth





-----------------------------------------------------------------------------------
Post ID:2070
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-06 14:43:24
Subject:Re: Representations, State and Identity
Message:

On Thu, Aug 01, 2002 at 09:39:16PM -0400, Jeffrey Winter wrote:
> The underlying state of Purchase Order 234 is exactly the
> same, but I'm chosing to represent it differently depending
> on the circumstances.  
> 
> Are these in fact the same resource?

No, they're two representations of the same resource.  Neither is the
resource.  The resource is just the purchase order, which is abstract
and can't be "gotten".

>  Or do the details of
> the HTTP header (in this case the user-agent) become
> an implicit part of the resource identifier?

Noooo.... 8-)

> Suppose I wanted to employ caching hints (Etags) along 
> with the response, would it even be possible in this 
> circumstance given that the cache would need to be 
> aware of what kind of response I was returning?

Sure it would, but to be a good HTTP agent, you should signal the
variability to caches by saying;

Vary: User-Agent

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2071
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-08-06 14:48:48
Subject:Re: [rest-discuss] A Sane Approach to Migrating to Web Services
Message:

Seth Ladd wrote:
> 
> >       - Describe your Web services using HTML.
> 
> actually, you'll want to use RDF to describe the web service.  We want
> machines to be able to interact with these services autonomously.  HTML
> can't actually say anything about the objects that you are talking
> about.  Humans read HTML, machines read RDF.

You make a good point Seth.  However, I believe that at this point in
the evolution of Web services realistically the best we can do is have a
human read a textual description of how to use a Web service and then
build his client application in accordance with that description.  I
agree that tomorrow client applications will be able to dynamically make
sense of an RDF (or, better yet, DAML-S) description, and dynamically
configure itself to use the Web service.  I believe that today a textual
description of how to use a Web service is "good enough".  /Roger







-----------------------------------------------------------------------------------
Post ID:2072
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-06 14:57:43
Subject:Re: [rest-discuss] A Sane Approach to Migrating to Web Services
Message:


> agree that tomorrow client applications will be able to dynamically make
> sense of an RDF (or, better yet, DAML-S) description, and dynamically
> configure itself to use the Web service.  I believe that today a textual
> description of how to use a Web service is "good enough".  /Roger

Hmm... true, those fabled inference engines are nowhere to be found. :)

But, if we're advocating the best way to discover and use True Web 
Services, let's also start advocating DAML-S (or some other service 
description language).  I agree that we'll also need some textual 
descriptions.  Luckily, we can markup RDF inside other XML.  So we can 
always write a XHTML document that puts a pretty public face on the 
service.  Inside that document, I can include my RDF markup describing 
the service in more rigid detail for machines that are searching Google 
for services like that.

I think we can come up with a good mix of XHTML and RDF to describe 
services.  The idea of placing that description document (mixed human 
and machine markup) inside Google is wonderful.

Now, on to read about DAML-S. :)

Seth





-----------------------------------------------------------------------------------
Post ID:2073
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-08-06 15:15:53
Subject:Re: [rest-discuss] A Sane Approach to Migrating to Web Services
Message:

Seth Ladd wrote:
> 
> 
> But, if we're advocating the best way to discover and use True Web
> Services, let's also start advocating DAML-S (or some other service
> description language).  I agree that we'll also need some textual
> descriptions.  Luckily, we can markup RDF inside other XML.  So we can
> always write a XHTML document that puts a pretty public face on the
> service.  Inside that document, I can include my RDF markup describing
> the service in more rigid detail for machines that are searching Google
> for services like that.
> 
> I think we can come up with a good mix of XHTML and RDF to describe
> services.  The idea of placing that description document (mixed human
> and machine markup) inside Google is wonderful.

An absolutely brilliant idea Seth!  I like that a lot.  That is an
excellent way to bridge what we can do today with what we will be able
to do tomorrow.  Bravo!  If it's okay with you, I would like to
incorporate that into my article?  /Roger







-----------------------------------------------------------------------------------
Post ID:2074
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-06 15:17:42
Subject:Re: [rest-discuss] A Sane Approach to Migrating to Web Services
Message:

On Tue, Aug 06, 2002 at 10:48:48AM -0400, Roger L. Costello wrote:
> You make a good point Seth.  However, I believe that at this point in
> the evolution of Web services realistically the best we can do is have a
> human read a textual description of how to use a Web service and then
> build his client application in accordance with that description.

I'm with Seth on this.  If you propose this to Web services folks,
you'll immediately turn them off because it's instantly less capable
than what they currently have.

You have to give them something that can do what their existing
technologies can do, *and* new stuff.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2075
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-06 17:44:11
Subject:Help with Transfering State
Message:

Hello,

I've come to a mental block, and I am hoping the REST community can help 
me clear things up.

For this example, I'll use two resources: A Car and A Driver.  A central 
monitoring computer wants to know when a particular driver has entered 
the car AND through what door did that driver enter.  In this scenario I 
have two resources, and each one is changing state.  The Car's child 
resource Door has changed from Closed to Open (and back to Closed).  The 
Driver's location property has changed from OutsideCar to InsideCar.  I 
need to know both resources and their state changes to correctly know 
which Driver is in the car and what door was used.

I'm having problems connecting these two state changes together to 
provide the central monitoring computer the correct information.  I 
don't want to transmit them separately, since then I can't always know 
the two events are related.

I don't want to say in the Door Open state change that a particular 
Driver opened it because that information (the actor in this scenario) 
isn't really part of the state change of the door.  I want to keep the 
communication primarily state changes of resources, not Events that 
detail "How, What, Where, and Why".

I am missing something of the puzzle?  How can I communicate two pieces 
of information in one state change, or link two state changes?

Your help and insight is greatly appreciated!

Thanks very much,
Seth





-----------------------------------------------------------------------------------
Post ID:2076
Sender:"nixerman" <nixerman@...>
Post Date/Time:2002-08-06 21:03:20
Subject:Re: Help with Transfering State
Message:

Seth,

You said it yourself in the subject of your email: "Transfering 
State." In this case you need to make the 'State' of 'States' a GET-
able resource. I'd recommend something like:

GET http://localhost/app/statechanges/latest
-- returns the new state of every object whose state has changed 
within the last time unit eg <states><state 
target="Driver">...</state><state target="Door">...</state></states> 
as well as the exact time the state transition took place.

It sounds like you may be going for an event-based model. Beware that 
neither SOAP nor REST map well onto the event-based model. HTTP is 
fundamentally a 'pull'-focused protocol while event-based models 
are 'push'-focused. It can be done but it should not be done.

- jkk

--- In rest-discuss@y..., Seth Ladd <seth@b...> wrote:
> Hello,
> 
> I've come to a mental block, and I am hoping the REST community can 
help 
> me clear things up.
> 
> For this example, I'll use two resources: A Car and A Driver.  A 
central 
> monitoring computer wants to know when a particular driver has 
entered 
> the car AND through what door did that driver enter.  In this 
scenario I 
> have two resources, and each one is changing state.  The Car's 
child 
> resource Door has changed from Closed to Open (and back to 
Closed).  The 
> Driver's location property has changed from OutsideCar to 
InsideCar.  I 
> need to know both resources and their state changes to correctly 
know 
> which Driver is in the car and what door was used.
> 
> I'm having problems connecting these two state changes together to 
> provide the central monitoring computer the correct information.  I 
> don't want to transmit them separately, since then I can't always 
know 
> the two events are related.
> 
> I don't want to say in the Door Open state change that a particular 
> Driver opened it because that information (the actor in this 
scenario) 
> isn't really part of the state change of the door.  I want to keep 
the 
> communication primarily state changes of resources, not Events that 
> detail "How, What, Where, and Why".
> 
> I am missing something of the puzzle?  How can I communicate two 
pieces 
> of information in one state change, or link two state changes?
> 
> Your help and insight is greatly appreciated!
> 
> Thanks very much,
> Seth







-----------------------------------------------------------------------------------
Post ID:2077
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-06 23:40:10
Subject:Re: [rest-discuss] Re: Help with Transfering State
Message:

----- Original Message -----
From: "nixerman" <nixerman@...>

>
> It sounds like you may be going for an event-based model. Beware that
> neither SOAP nor REST map well onto the event-based model. HTTP is
> fundamentally a 'pull'-focused protocol while event-based models
> are 'push'-focused. It can be done but it should not be done.

HTTP PUT, POST, and DELETE are pushed. The Web Works Both Ways.
I think SOAP-as-messaging would work fine for event-based systems, but I
haven't put much thought into it.

There are other reasons to be cautious of an event-based model with REST.
Its very easy to slip into tunneling of methods if your resources become
generic 'queue' and 'topic' resources. I know now that this can be
problematic when doing application resource modelling.

However, if you are able to maintain a rich resource model and not drift
into generic messaging, events are fine way to build systems. One thing I
learned a while ago was to not worry about lots of small events - trying to
aggregate them into a single message isn't worth the effort.

You state that the problem with sending events separately is "since then I
can't always know the two events are related."
How do you know the events are related anyway? Model that as a resource and
you may make some progress.









-----------------------------------------------------------------------------------
Post ID:2078
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-07 00:34:39
Subject:Re: [rest-discuss] Re: Help with Transfering State
Message:

> There are other reasons to be cautious of an event-based model with REST.
> Its very easy to slip into tunneling of methods if your resources become
> generic 'queue' and 'topic' resources. I know now that this can be
> problematic when doing application resource modelling.

Agreed.  That's exactly the trap I was trying not to fall into.  Luckily 
we moved away from queues just recently.  The Client now pull exactly 
the data they need.


> You state that the problem with sending events separately is "since then I
> can't always know the two events are related."
> How do you know the events are related anyway? Model that as a resource and
> you may make some progress.

Yes, and I think we finally modeled it as a resource.  That was the 
hardest part: taking two resources that were well known, whose state 
changes we are interested in, and asking "What is the resource that 
results from this change?"  It's an odd looking resource because it ties 
together two other resources, but it can stand on its own.  Because of 
this we think it works well.

I'd love to post a synopsis once we finalize our spec.

Thanks for your help!
Seth







-----------------------------------------------------------------------------------
Post ID:2079
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-08-07 12:53:50
Subject:Web Services Evolution Timeline
Message:

Here's my prediction on how Web services will evolve over the upcoming
years:

|<----------->|<-------------------->|<---------------->|<----------->|
             2001                   2005               2008         2012
   HTML,           standardize           begin to          full-scale    
   screen          XML vocabularies;     replace           use of 
   scraping        textual description   vanilla XML       dynamic
                   of Web services       with dynamic      discovery
                   using HTML;           discovery         XML;
                   Web services          XML - RDF/DAML;   inference
                   exchange vanilla      describe          engine
                   XML;                  Web services      brokers
                   Search for Web        using dynamic     automatically
                   services using        XML - DAML-S;     find things
                   Google, Yahoo, etc    begin to see      for you;
                                         knowledge-based   knowledge-
                                         search engines    based service
                                                           descripions

Some things to note:

1. There will be a gradual transition towards increasingly more
semantic-rich vocabularies.  

2. At the present we are in the "vanilla XML phase".  The emphasis today
is on getting consensus within a community on what is the required data
and how it should be organized.  Web services move away from exchanging
HTML documents to exchanging XML documents.  

   - THIS IS A HUGE LEAP FORWARD!  Do not underestimate the impact 
     of this change! It positions the Web for the next stage - 
     introducing semantics into the Web.

2. Starting around 2005 you will start to see the introduction of
non-vanilla XML vocabularies.  These vocabularies will enable
inferencing (e.g., discover that SLR is a camera), thus enabling dynamic
discovery.  There will likewise be a shift in how Web services are
described - from a textual (HTML) description to a semantic-discoverable
description.  The leading contender today is DAML-S. (During this phase
I would expect to see implemented Seth's idea of blending human-readable
Web service descriptions with machine-readable descriptions)

3. The full semantic Web kicks in around 2007.

----

Positioning for the future

Want to get your company in a good position for the future?  Concentrate
on:
   - getting consensus within your community on an XML vocabulary
   - get your applications onto the Web
   - get your applications to stop exchanging HTML documents and
     start exchanging XML documents
   - describe your Web services textually using HTML
   - use standard search engines (Google, Yahoo, etc) to locate
     services.

If you do these things then you are:
   - working efficiently
   - not wasting money (on things like SOAP, WSDL, UDDI; note in the
     timeline no mention of these; when the dust settles on these
     technologies superior technologies - DAML, DAML-S - will have
     already superceded them)
   - you are positioning your company for the next step

These time estimates are based upon my observation of the speed of W3
technologies being developed and deployed on the Web.

Comments?  /Roger







-----------------------------------------------------------------------------------
Post ID:2080
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-08-07 13:05:08
Subject:Re: [rest-discuss] Web Services Evolution Timeline
Message:

Roger L. Costello wrote,
> Comments?  /Roger

It will all grind to a horrible halt at the "standardize XML 
vocabularies" stage, at least where there are any significantly 
non-trivial semantics attached to those vocabularies. There'll be lots 
of _activity_, for sure, but very little progress.

FWIW, I have a years salary bet on this ... so I'm pretty confident that 
I'm right (which, of course, doesn't mean that I actually am right) ;-)

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2081
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-08-07 13:37:51
Subject:RE: [rest-discuss] A Sane Approach to Migrating to Web Services
Message:

Hi Roger,

Interesting viewpoint. I'll take issue with one item in your paper:
"Describe your Web Services using HTML."

I think *any* XML* service description is better than HTML. Even if someone
makes up something remotely XML-like, at least they'll have a chance of
going back and remapping it into whatever IDL they want with through XSL or
turning it into formatted HTML.

But just having an HTML description without *any* service meta-data means
having to go back and re-do potentially lots of work. At the very least, I'd
tell people to put some formatted comments inside the HTML so some future
automated tool will have a chance beyond simple HTML-scraping.

Cheers,
Ramin

  -----Original Message-----
  From: Roger L. Costello [mailto:costello@...]
  Sent: Tuesday, August 06, 2002 5:32 AM
  To: rest-discuss@yahoogroups.com
  Subject: [rest-discuss] A Sane Approach to Migrating to Web Services


  Hi Folks,

  I have written a paper[1] on migrating applications to Web
  services.  In a nutshell, here's what the paper says:

  Don't use SOAP, WSDL, or UDDI!  Instead, use these:

        - Stand up Web services that receive and reply with standardized
          XML vocabularies (create standard XML vocabularies for
          your domain).
        - Describe your Web services using HTML.
        - Use standard search engines - Google, Yahoo, etc - to search for
          services.

  If you do this then you have taken a big and important step.

  SOAP, WSDL, and UDDI are very immature, in a state of flux, and have
  many crippling weaknesses. I believe that they will be short-lived and
  will be replaced by superior technologies.

  For today, it is "good enough" to just exchange (standards-based) XML
  messages, to use HTML to describe services, and to use standard search
  engines to find services.

  Comments welcome. /Roger

  [1] http://www.xfront.com/MigratingToWebServices.html


        Yahoo! Groups Sponsor
              ADVERTISEMENT



  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.






-----------------------------------------------------------------------------------
Post ID:2082
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-08-07 14:05:47
Subject:Re: [rest-discuss] A Sane Approach to Migrating to Web Services
Message:

Thanks for the comments Ramin.  Yes, I understand your concern - nearly
anything is better than that nasty HTML.  These are essentially the same
points that Seth and Mike raised yesterday.

Seth came up with a (brilliant) idea of blending an XML description of
the Web service in with a textual (HTML) description of the Web
service.  The former is for machines, the later for humans.  (Same
technique that RDDL employs.)  I like this strategy a lot!  Personally,
however, I feel that getting machines to make sense out of the XML
description won't really see any widespread use until the next phase of
the Web evolution (around 2005).  /Roger







-----------------------------------------------------------------------------------
Post ID:2083
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-08-07 15:40:22
Subject:RE: [rest-discuss] Web Services Evolution Timeline
Message:

Personally, I'm a little skeptical about the whole dynamic discovery
business.
Smacks a little too much of A.I. (with the same sort of 70's-80's hype
attached).

Searching for web-services using Google/Yahoo I agree with, but only if
there's
money in it for them. My prediction is that once the tire-kicking is over
with, you'll
see a rise of 'for-pay' web-services and then Google will start listing them
and
charging people for 'sponsored' listings.

As for the move from HTML to XML, I honestly don't think any mainstream
site-builder
is going to switch from their fancy HTML/Flash interface to an
XML-XSLT->HTML setting
without some serious tool support. Dreamweaver's latest rev had *nothing*
XSLT
related in it. Same with Frontpage. Besides, why would they want to switch
from their
HTML site to an XML/XSLT site when it slows things down, makes them have to
dive
elbow-deep into XSLT programming code, is harder to maintain, and offers
them no
obvious immediate financial benefit.

The more obvious driver will be people creating XML-based services *then*
putting
an HTML front-end on it instead of the other way round.

Good stuff, Roger. A little dose of skepticism is a healthy thing.

-Ramin
  -----Original Message-----
  From: Roger L. Costello [mailto:costello@...]
  Sent: Wednesday, August 07, 2002 5:54 AM
  To: rest-discuss@yahoogroups.com
  Subject: [rest-discuss] Web Services Evolution Timeline


  Here's my prediction on how Web services will evolve over the upcoming
  years:

  |<----------->|<-------------------->|<---------------->|<----------->|
               2001                   2005               2008         2012
     HTML,           standardize           begin to          full-scale
     screen          XML vocabularies;     replace           use of
     scraping        textual description   vanilla XML       dynamic
                     of Web services       with dynamic      discovery
                     using HTML;           discovery         XML;
                     Web services          XML - RDF/DAML;   inference
                     exchange vanilla      describe          engine
                     XML;                  Web services      brokers
                     Search for Web        using dynamic     automatically
                     services using        XML - DAML-S;     find things
                     Google, Yahoo, etc    begin to see      for you;
                                           knowledge-based   knowledge-
                                           search engines    based service
                                                             descripions

  Some things to note:

  1. There will be a gradual transition towards increasingly more
  semantic-rich vocabularies.

  2. At the present we are in the "vanilla XML phase".  The emphasis today
  is on getting consensus within a community on what is the required data
  and how it should be organized.  Web services move away from exchanging
  HTML documents to exchanging XML documents.

     - THIS IS A HUGE LEAP FORWARD!  Do not underestimate the impact
       of this change! It positions the Web for the next stage -
       introducing semantics into the Web.

  2. Starting around 2005 you will start to see the introduction of
  non-vanilla XML vocabularies.  These vocabularies will enable
  inferencing (e.g., discover that SLR is a camera), thus enabling dynamic
  discovery.  There will likewise be a shift in how Web services are
  described - from a textual (HTML) description to a semantic-discoverable
  description.  The leading contender today is DAML-S. (During this phase
  I would expect to see implemented Seth's idea of blending human-readable
  Web service descriptions with machine-readable descriptions)

  3. The full semantic Web kicks in around 2007.

  ----

  Positioning for the future

  Want to get your company in a good position for the future?  Concentrate
  on:
     - getting consensus within your community on an XML vocabulary
     - get your applications onto the Web
     - get your applications to stop exchanging HTML documents and
       start exchanging XML documents
     - describe your Web services textually using HTML
     - use standard search engines (Google, Yahoo, etc) to locate
       services.

  If you do these things then you are:
     - working efficiently
     - not wasting money (on things like SOAP, WSDL, UDDI; note in the
       timeline no mention of these; when the dust settles on these
       technologies superior technologies - DAML, DAML-S - will have
       already superceded them)
     - you are positioning your company for the next step

  These time estimates are based upon my observation of the speed of W3
  technologies being developed and deployed on the Web.

  Comments?  /Roger


        Yahoo! Groups Sponsor


  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.






-----------------------------------------------------------------------------------
Post ID:2084
Sender:"xemplify" <xemplify@...>
Post Date/Time:2002-08-07 15:53:02
Subject:Re: Web Services Evolution Timeline
Message:

Since we are taking about predictions, here is an interesting article 
(from the future;) that I came accross today:

August 2009: How Google beat Amazon and Ebay to the Semantic Web
http://ftrain.com/google_takes_all.html

- Robert







-----------------------------------------------------------------------------------
Post ID:2085
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-08 13:27:52
Subject:choreography
Message:

Perhaps a thread of interest to the members of this list:

 * http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg01848.html
-- 
XML, Web Services Architecture, REST Architectural Style
Consulting, training, programming: http://www.constantrevolution.com
Come discuss XML and REST web services at the Extreme Markup Conference






-----------------------------------------------------------------------------------
Post ID:2086
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-08 18:28:47
Subject:Re: choreography
Message:

Paul Prescod wrote:
> Perhaps a thread of interest to the members of this list:
> 
>  * http://www.ai.mit.edu/~gregs/ll1-discuss-archive-
html/msg01848.html

Yeah, really.  Another great article, Paul!

Your ideas on this extended topic have been very stimulating to me.
I've been fumbling in the same direction ever since ebXML, where I 
was pretty heavily involved in ebXML-BPSS, one of the bad examples in 
your article.  I take no offense, it was a learning experience for 
me, and I learned a lot.

I continue to like the RosettaNet-UNCEFACT-ebXML "state alignment" 
transaction model, which we've explored some on this list, and think 
it can both be RESTful and have the unit-of-work transaction property.

However, when it comes to the choreography or orchestration in ebXML 
BPSS - the stuff that orchestrates between the transactions - I get 
more skeptical every day.

In fact, there were several factions in the ebXML Business Process 
project, which produced ebXML-BPSS among other things.  One faction 
went over to UNCEFACT-eBTWG and is working out a better way to 
orchestrate conversations focused on states of business objects.

I think that if you take the gist of that "better way" and translate 
the business objects into REST resources, you will get something that 
is very close to where your train of thought is going.  (We'll see 
soon enough if I'm right.)

One aspect of the eBTWG work is a business ontology based on Bill 
McCarthy's REA (Resource-Event-Agent) model (with which Mark is 
familiar, since we used to kick it around in the dist-obj list).

I think the REA ontology is the semantic basis for the declarative 
language you are looking for.

For example, the REA model for a business exchange (or even barter) 
is Give and Take, where I Give you some economic resources and Take 
from you some other economic resources in exchange.  (E.g. usually 
products or services in exchange for money, but it wouldn't have to 
be money.)

In REA, Give and Take are economic events.

In business, economic events are usually preceded by Commitments, 
which are promises to perform economic events in the future.

(An Order is a collection of Commitments.)

So if the Commitment exists, you can post the Give and Take economic 
events to it.  If the Give event is supposed to appear first, then 
the Take event could be posted to it.

They're all speech acts that refer to previous speech acts.
If the referent doesn't exist, you can't refer to it.

Again, little or no choreography required.  

But the rules should also be REST resources.

Am I following your train of thought?

-Bob Haugen

References, almost all more verbose than you want:

REA Ontology source page:
http://www.msu.edu/user/mccarth4/rea-ontology/index.htm

UNCEFACT-eBTWG Business Entity Type project draft paper:
http://www.collaborativedomain.com/standards/documents/BET%20Draft%
20Technical%20Specification_v012.zip
(watch out for word wrap)

RDF version of all this stuff due in fall.








-----------------------------------------------------------------------------------
Post ID:2087
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-08-08 20:26:15
Subject:Re: [rest-discuss] Re: choreography
Message:

On Thursday, August 8, 2002, at 01:28  PM, bhaugen32 wrote:

> Paul Prescod wrote:
>> Perhaps a thread of interest to the members of this list:
>>
>>  * http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg01848.html
>
> Yeah, really.  Another great article, Paul!

Ditto!  Good job, Paul.  This exact line of thinking mirrors what's been 
keeping me up at night for about the last year:  trying to generalize 
and formalize this sort of notion into a generic theory of compositional 
complexity in software architecture.

Kudos,

jb







-----------------------------------------------------------------------------------
Post ID:2088
Sender:Gary Lawrence Murphy <garym@...>
Post Date/Time:2002-08-08 14:53:40
Subject:Re: [rest-discuss] Web Services Evolution Timeline
Message:

>>>>> "R" == Ramin Firoozye <ramin@...> writes:

    R> Personally, I'm a little skeptical about the whole dynamic
    R> discovery business.  Smacks a little too much of A.I. (with the
    R> same sort of 70's-80's hype attached).

Not so -- it's more likely to be implemented by massively distributed
human intelligence, for example, through inferences gleened by sifting
blog-like RDF metadata not unlike the way Google now reverts to it's
guess at spelling mistakes if the first search turns up empty.

    R> Searching for web-services using Google/Yahoo I agree with, but
    R> only if there's money in it for them. My prediction is that
    R> once the tire-kicking is over with, you'll see a rise of
    R> 'for-pay' web-services and then Google will start listing them
    R> and charging people for 'sponsored' listings.

I still see Internet as an advertising medium.  We advertise our goods,
our services, our ideas, our experiences, and webservice discovery is
really "find me all commercials for ..."

I also haven't seen any really compelling for-pay services except in
very narrow professional domains (where either someone else pays on
your behalf or you fold the costs into your own webservice-advertised
goods).  The old saw that "professional editing" produces somehow
better journalism falls apart when you simply take a look through the
eons of microfilm stockpiled at the NYT -- it's based on the
unsupportable myth that the journalism of our childhood was somehow
more reliable than your average blog.  It wasn't.

Ditto for stock quotes, IMHO.  Reacting to the reported prices is not
nearly as useful as inside information about impending price changes ;)

My prediction is that, once the "golly-gee whiz" of the Internet wears
off (as it has already done for the under 25 crowd) for-fee services
will find their otherwise-sponsored bretheren overtaking them at an
alarming rate.

    R> As for the move from HTML to XML, I honestly don't think any
    R> mainstream site-builder is going to switch from their fancy
    R> HTML/Flash interface to an XML-XSLT-> HTML setting

There's nothing incompatible here.  XML/SVG->XSLT-+->HTML
                                                  +->RDF
                                                  +->...

What is needed is the need for the other formats as seen by the
average website (who is presently still in golly-gee land).  When they
understand how their webservices are their public face, they will
anneal to being more effective at it (compare TV commercials from 1952
with 1972).  When they realize that information overload has lead the
desktop vendors to produce Meerkat-like semantic surfers, they will
demand the Dreamweavers give them tools to leverage that sales
channel.

    R> The more obvious driver will be people creating XML-based
    R> services *then* putting an HTML front-end on it instead of the
    R> other way round.

The driver I expect will be all under the hood.  People will still
create their stories online, only with the requirement that it "also
feeds those meerkat things" and they won't care a hoot about RFC's.
Vendors, on the other hand, already know that the most efficient
lowest common denominator formats for storage and exchange are XMLs.

-- 
Gary Lawrence Murphy <garym@...> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless.  They can only give you answers."(Pablo Picasso)







-----------------------------------------------------------------------------------
Post ID:2089
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-09 01:44:25
Subject:Re: [rest-discuss] Re: choreography
Message:

Yep, ditto, this is bang on.  Coincidentally, WSCI was just acknowledged
by the W3C as a submission;

http://www.w3.org/Submission/2002/04/

Stop the madness! 8-O

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2090
Sender:Seth Johnson <seth.johnson@...>
Post Date/Time:2002-08-09 02:59:56
Subject:Web Services vs Semantic Web
Message:

(Canarie News Newsletter)

-------- Original Message --------
Subject: [news] Web services versus the Semantic Web
Date: Thu, 8 Aug 2002 14:13:53 -0400 (EDT)
From: CAnet-3-NEWS@...

For more information on this item please visit the CANARIE
CA*net 3 Optical Internet program web site at
http://www.canet3.net/news/news.html
-------------------------------------------

[A lot of the hype about web services has been on the
eBuisness potential. However many experts feel that web
services and the semantic web has much greater applicability
beyond the limited horizons of eBusiness. Thanks to Wade
Hong for this pointer.  Some excerpts - BSA]

http://www.xml.com/pub/a/2002/07/17/daml-s.html

The True Meaning of Service

The Conventional Wisdom...

At some point over the past 18 months the future direction
of the Web began to be seen widely as a struggle between
"Web Services" and the "Semantic Web". The latter was
thought to be rooted in the W3C and academia, the former in
IBM-Microsoft-Sun and industry.

Part of the debate between services and semantics is a
replay of the debate about what makes the Web an interesting
place: commerce or content? In the conventional wisdom,
services represent the commerce part of the Web, while
semantics represent its content.

It's been clear for some time that the conventional wisdom
is wrong.  The idea is that high-level ontologies of web
resources can be very useful things and, here's the kicker,
web services are just a kind of web resource. Web services
are resources that allow one to effect some action or change
in the world, such as the sale of a product or the control
of a physical device.

The motivations for creating DAML-S include discovery,
invocation, interoperation, composition, verification, and
monitoring. A part of the practical cash value of any web
technology labeled "semantic" is that the Web ought to
provide something relatively useful in response to vague or
even cryptic input from the end-user.

------------------------------------
To subscribe or unsubscribe to the CANARIE-NEWS list please
send e-mail to:

majordomo@...

In the body of the e-mail:

subscribe news
end

-------------------------------------

These news items and comments are mine alone and do not
necessarily reflect those  of the CANARIE board or
management.

-----------------------------
Bill St. Arnaud
Senior Director Network Projects
CANARIE Inc
www.canarie.ca/~bstarn







-----------------------------------------------------------------------------------
Post ID:2091
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-08-09 06:38:50
Subject:Vote for me bugs...
Message:

This is a bug in PHP; when the script encounters a fatal error, it still
generates a 200 status code.
  http://bugs.php.net/bug.php?id=18824

This is for Apache's mod_dir to generate Content-Location:
  http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11580


--
Mark Nottingham







-----------------------------------------------------------------------------------
Post ID:2092
Sender:"ifglijkmc" <ifglijkmc@...>
Post Date/Time:2002-08-13 00:28:42
Subject:check this site out!…
Message:

http://llmensa.tripod.com







-----------------------------------------------------------------------------------
Post ID:2093
Sender:"Timothy Conhon"<freehghpro1@...>
Post Date/Time:2002-08-15 14:50:44
Subject:ressurec1,Have You Heard of Age Reversal with HGH?
Message:

Hello, ressurec1@...

As seen on NBC, CBS, and CNN, and even Oprah! The health
discovery that actually reverses aging while burning fat,
without dieting or exercise! This proven discovery has even
been reported on by the New England Journal of Medicine.
Forget aging and dieting forever! And it's Guaranteed!


* Reduce body fat and build lean muscle WITHOUT EXERCISE!
* Enhace sexual performance
* Remove wrinkles and cellulite
* Lower blood pressure and improve cholesterol profile
* Improve sleep, vision and memory
* Restore hair color and growth
* Strengthen the immune system
* Increase energy and cardiac output
* Turn back your body's biological time clock 10-20 years
in 6 months of usage !!!

FOR FREE INFORMATION AND GET FREE 1 MONTH SUPPLY OF HGH CLICK HERE















You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here




-----------------------------------------------------------------------------------
Post ID:2094
Sender:"nixerman" <nixerman@...>
Post Date/Time:2002-08-16 07:40:43
Subject:Http Digest Authentication
Message:

Hey guys,

I have a quick question about the expected behavior of Http Digest 
authentication. The answer is not clear to me from reading the spec. 
Currently I understand it as:

Server issues 401 Unauthorized challenge.
Client generates a Digest header to authenticate itself.

My question is: is the client expected to include the Digest HTTP 
header in all further requests to the server? Or is the server 
supposed to magically remember that this client has already 
authenticated itself?

I suspect that a client should be forced to reauthenticate itself 
with every request and this is how most browsers seem to work but I'm 
not completely sure. Thanks for the input.

- Buko







-----------------------------------------------------------------------------------
Post ID:2095
Sender:Chris Croome <chris@...>
Post Date/Time:2002-08-16 10:50:15
Subject:Re: [rest-discuss] Http Digest Authentication
Message:

Hi

On Fri 16-Aug-2002 at 07:40:43AM -0000, nixerman wrote:
> 
> My question is: is the client expected to include the Digest HTTP
> header in all further requests to the server? 

Yes. 

I was reading the HTTP book that was recommended on this list the other
day and I was pleasantly surprised to read about the detail of digest
authentication, it's a shame it's not fully supported by current
browsers.

Chris

-- 
Chris Croome                               <chris@...>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   
everything else                               http://chris.croome.net/  






-----------------------------------------------------------------------------------
Post ID:2096
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-08-16 13:24:01
Subject:No POST in an XML-based Web?
Message:

Hi Folks,

My vision of the next generation of the Web is that all HTML document
interchanges will be replaced by XML document interchanges.  Thus, the
Web evolves from an HTML-based Web to an XML-based Web.

In an XML-based Web I question the utility of the HTTP POST method.  The
HTTP GET method allows a client to cleanly retrieve an XML document. 
The HTTP PUT method allows the client to cleanly send an XML document to
the server.  The HTTP POST method, however, requires name/value pairs in
the payload.  A client could submit an XML document using a name/value
pair, where the value is an XML document.  However, that doesn't seem
very clean.  In an XML-based Web I just want to exchange XML documents. 
The payload is clean - just an XML document.  

I would like to (boldly) assert that the name/value pair style is a
remnant of HTML and is not suitable for an XML-based world!  Thus, I
propose that in The New Web that HTTP POST be dropped.  

I know what you are thinking: "Okay Roger, how do you do an update
operation if you dump POST?"  I am not sure.  Perhaps it is specified in
the XML document itself?  Perhaps we need a new HTTP method for doing an
update using an XML document?  Thoughts?  Comments?  /Roger







-----------------------------------------------------------------------------------
Post ID:2097
Sender:Phil Eskelin <philip.eskelin@...>
Post Date/Time:2002-08-16 13:50:36
Subject:RE: [rest-discuss] No POST in an XML-based Web?
Message:

Roger,

POST is not limited to name-value pairs.  If you look at RFC 2616 section
9.5 [1], you will see no mention of canonically-encoded name-value pairs as
the only type of entity supported.  The type is determined by Content-Type.
Most importantly, however, you will notice that the RFC defines POST as
being used to:

    "...request that the origin server accept the entity
     enclosed in the request as a new subordinate of the
     resource identified by the Request-URI in the
     Request-Line"

This is a key feature of the REST style.  POSTing to a subordinate of a
known resource is an important feature, because it allows you to POST a
representation without knowing what the resource at the origin server will
do with it.

If you didn't have POST, having only GET and PUT would overcomplicate the
protocol.  Everyone would need to create their own way of perhaps using
multiple GETs to discover the URI of a subordinate resource and use PUT to
send their representation to it.

-Philip

1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5

-----Original Message-----
From: Roger L. Costello [mailto:costello@...]
Sent: Friday, August 16, 2002 9:24 AM
To: rest-discuss@yahoogroups.com
Cc: Costello,Roger L.
Subject: [rest-discuss] No POST in an XML-based Web?


Hi Folks,

My vision of the next generation of the Web is that all HTML document
interchanges will be replaced by XML document interchanges.  Thus, the
Web evolves from an HTML-based Web to an XML-based Web.

In an XML-based Web I question the utility of the HTTP POST method.  The
HTTP GET method allows a client to cleanly retrieve an XML document. 
The HTTP PUT method allows the client to cleanly send an XML document to
the server.  The HTTP POST method, however, requires name/value pairs in
the payload.  A client could submit an XML document using a name/value
pair, where the value is an XML document.  However, that doesn't seem
very clean.  In an XML-based Web I just want to exchange XML documents. 
The payload is clean - just an XML document.  

I would like to (boldly) assert that the name/value pair style is a
remnant of HTML and is not suitable for an XML-based world!  Thus, I
propose that in The New Web that HTTP POST be dropped.  

I know what you are thinking: "Okay Roger, how do you do an update
operation if you dump POST?"  I am not sure.  Perhaps it is specified in
the XML document itself?  Perhaps we need a new HTTP method for doing an
update using an XML document?  Thoughts?  Comments?  /Roger


Yahoo! Groups Sponsor
ADVERTISEMENT



To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 

________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.






-----------------------------------------------------------------------------------
Post ID:2098
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-08-16 13:58:07
Subject:Re: [rest-discuss] No POST in an XML-based Web?
Message:

Thanks Philip.  Very well stated.  My ignorance.  /Roger

Phil Eskelin wrote:
> 
> Roger,
> 
> POST is not limited to name-value pairs.  If you look at RFC 2616 section
> 9.5 [1], you will see no mention of canonically-encoded name-value pairs as
> the only type of entity supported.  The type is determined by Content-Type.
> Most importantly, however, you will notice that the RFC defines POST as
> being used to:
> 
>     "...request that the origin server accept the entity
>      enclosed in the request as a new subordinate of the
>      resource identified by the Request-URI in the
>      Request-Line"
> 
> This is a key feature of the REST style.  POSTing to a subordinate of a
> known resource is an important feature, because it allows you to POST a
> representation without knowing what the resource at the origin server will
> do with it.
> 
> If you didn't have POST, having only GET and PUT would overcomplicate the
> protocol.  Everyone would need to create their own way of perhaps using
> multiple GETs to discover the URI of a subordinate resource and use PUT to
> send their representation to it.
> 
> -Philip
> 
> 1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
> 
> -----Original Message-----
> From: Roger L. Costello [mailto:costello@...]
> Sent: Friday, August 16, 2002 9:24 AM
> To: rest-discuss@yahoogroups.com
> Cc: Costello,Roger L.
> Subject: [rest-discuss] No POST in an XML-based Web?
> 
> Hi Folks,
> 
> My vision of the next generation of the Web is that all HTML document
> interchanges will be replaced by XML document interchanges.  Thus, the
> Web evolves from an HTML-based Web to an XML-based Web.
> 
> In an XML-based Web I question the utility of the HTTP POST method.  The
> HTTP GET method allows a client to cleanly retrieve an XML document.
> The HTTP PUT method allows the client to cleanly send an XML document to
> the server.  The HTTP POST method, however, requires name/value pairs in
> the payload.  A client could submit an XML document using a name/value
> pair, where the value is an XML document.  However, that doesn't seem
> very clean.  In an XML-based Web I just want to exchange XML documents.
> The payload is clean - just an XML document.
> 
> I would like to (boldly) assert that the name/value pair style is a
> remnant of HTML and is not suitable for an XML-based world!  Thus, I
> propose that in The New Web that HTTP POST be dropped.
> 
> I know what you are thinking: "Okay Roger, how do you do an update
> operation if you dump POST?"  I am not sure.  Perhaps it is specified in
> the XML document itself?  Perhaps we need a new HTTP method for doing an
> update using an XML document?  Thoughts?  Comments?  /Roger
> 
> Yahoo! Groups Sponsor
> ADVERTISEMENT
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
> 
> ________________________________________________________________________
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
> e-mail communications through its networks.







-----------------------------------------------------------------------------------
Post ID:2099
Sender:Phil Eskelin <philip.eskelin@...>
Post Date/Time:2002-08-16 14:14:21
Subject:RE: [rest-discuss] No POST in an XML-based Web?
Message:

Roger,

I would say 'ignorance' is too pessimistic to mention on a Friday ;-).

When I first embarked on developing my toolkit a few years ago, I had the
same approach you described.  I put an entire XML representation into a
"result" name-value pair of a POST message for remote method invocations.
The response would also have an "error" name an error occurred in processing
the POST request.  At the time, I couldn't explain why, but it seemed dirty.

Then, after closely reading RFC 2616, and after experiencing a few
epiphanies while reading Fielding's thesis, I realized this was a bogus
approach, and almost anti-REST in nature.  Now, I am more of an
"clean-kitchen" HTTP purist.  

HTTP is king, and representations as remote method invocations are evil evil
notions better left to the SOAP demagoguery.

-Philip

-----Original Message-----
From: Roger L. Costello [mailto:costello@...]
Sent: Friday, August 16, 2002 9:58 AM
To: rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] No POST in an XML-based Web?


Thanks Philip.  Very well stated.  My ignorance.  /Roger

Phil Eskelin wrote:
> 
> Roger,
> 
> POST is not limited to name-value pairs.  If you look at RFC 2616 section
> 9.5 [1], you will see no mention of canonically-encoded name-value pairs
as
> the only type of entity supported.  The type is determined by
Content-Type.
> Most importantly, however, you will notice that the RFC defines POST as
> being used to:
> 
>     "...request that the origin server accept the entity
>      enclosed in the request as a new subordinate of the
>      resource identified by the Request-URI in the
>      Request-Line"
> 
> This is a key feature of the REST style.  POSTing to a subordinate of a
> known resource is an important feature, because it allows you to POST a
> representation without knowing what the resource at the origin server will
> do with it.
> 
> If you didn't have POST, having only GET and PUT would overcomplicate the
> protocol.  Everyone would need to create their own way of perhaps using
> multiple GETs to discover the URI of a subordinate resource and use PUT to
> send their representation to it.
> 
> -Philip
> 
> 1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
> 
> -----Original Message-----
> From: Roger L. Costello [mailto:costello@...]
> Sent: Friday, August 16, 2002 9:24 AM
> To: rest-discuss@yahoogroups.com
> Cc: Costello,Roger L.
> Subject: [rest-discuss] No POST in an XML-based Web?
> 
> Hi Folks,
> 
> My vision of the next generation of the Web is that all HTML document
> interchanges will be replaced by XML document interchanges.  Thus, the
> Web evolves from an HTML-based Web to an XML-based Web.
> 
> In an XML-based Web I question the utility of the HTTP POST method.  The
> HTTP GET method allows a client to cleanly retrieve an XML document.
> The HTTP PUT method allows the client to cleanly send an XML document to
> the server.  The HTTP POST method, however, requires name/value pairs in
> the payload.  A client could submit an XML document using a name/value
> pair, where the value is an XML document.  However, that doesn't seem
> very clean.  In an XML-based Web I just want to exchange XML documents.
> The payload is clean - just an XML document.
> 
> I would like to (boldly) assert that the name/value pair style is a
> remnant of HTML and is not suitable for an XML-based world!  Thus, I
> propose that in The New Web that HTTP POST be dropped.
> 
> I know what you are thinking: "Okay Roger, how do you do an update
> operation if you dump POST?"  I am not sure.  Perhaps it is specified in
> the XML document itself?  Perhaps we need a new HTTP method for doing an
> update using an XML document?  Thoughts?  Comments?  /Roger

[snip]

________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.






-----------------------------------------------------------------------------------
Post ID:2100
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-08-16 15:01:33
Subject:RE: [rest-discuss] No POST in an XML-based Web?
Message:

Hi Roger,

Intriguing idea. But I think you're looking at it a bit too
document-oriented (:-)

In an XML-based web, GET would retrieve an XML document and/or structure
(given parameters), PUT would send an XML document and/or structure, and
POST would invoke a remote XML-based web-service.

A web-service would either require key-value parameters, or a 'structure'
that needs to be filled out and sent down. The form fields would be extended
to allow filling the structure data and then sending it to the remote
procedure.

For example, a weather service could either take a single parameter called
zip code (in which case, you could use PUT, or a simple form of POST) or a
more complex structure like:

<data name="params">
  <city type="string" />
  <state type="string" />
  <country type="string" />
</data>

The form field names would then be something like:

params.city
params.state
params.country

and the user-agent would map its internal data (say, from a calling
web-service or an HTML FORM) into this structure before posting it to the
far end.

Just a thought,
Ramin
  -----Original Message-----
  From: Roger L. Costello [mailto:costello@...]
  Sent: Friday, August 16, 2002 6:24 AM
  To: rest-discuss@yahoogroups.com
  Cc: Costello,Roger L.
  Subject: [rest-discuss] No POST in an XML-based Web?


  Hi Folks,

  My vision of the next generation of the Web is that all HTML document
  interchanges will be replaced by XML document interchanges.  Thus, the
  Web evolves from an HTML-based Web to an XML-based Web.

  In an XML-based Web I question the utility of the HTTP POST method.  The
  HTTP GET method allows a client to cleanly retrieve an XML document.
  The HTTP PUT method allows the client to cleanly send an XML document to
  the server.  The HTTP POST method, however, requires name/value pairs in
  the payload.  A client could submit an XML document using a name/value
  pair, where the value is an XML document.  However, that doesn't seem
  very clean.  In an XML-based Web I just want to exchange XML documents.
  The payload is clean - just an XML document.

  I would like to (boldly) assert that the name/value pair style is a
  remnant of HTML and is not suitable for an XML-based world!  Thus, I
  propose that in The New Web that HTTP POST be dropped.

  I know what you are thinking: "Okay Roger, how do you do an update
  operation if you dump POST?"  I am not sure.  Perhaps it is specified in
  the XML document itself?  Perhaps we need a new HTTP method for doing an
  update using an XML document?  Thoughts?  Comments?  /Roger


        Yahoo! Groups Sponsor
              ADVERTISEMENT



  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.






-----------------------------------------------------------------------------------
Post ID:2101
Sender:"nixerman" <nixerman@...>
Post Date/Time:2002-08-16 16:04:30
Subject:RWS-SDL: WSDL for Rest?
Message:

Guys,

Has anybody done any work on creating a WSDL-equivalent for REST?

I'm developing my own solution but I'm curious if there's work 
already being done.

- jkk







-----------------------------------------------------------------------------------
Post ID:2102
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-16 19:26:40
Subject:Re: [rest-discuss] No POST in an XML-based Web?
Message:

> In an XML-based Web I question the utility of the HTTP POST method.  The
> HTTP GET method allows a client to cleanly retrieve an XML document.
> The HTTP PUT method allows the client to cleanly send an XML document to
> the server.
The operation is not 'send' - it is 'set'. The server doesn't have as much
freedom to choose how to handle the request. The constraint is that a GET
will return a representation of the resource that should be the same state
as what was PUT.

> The HTTP POST method, however, requires name/value pairs in
> the payload.
Not true. POST supports Content-Type. I've used it to post xml for years.

> A client could submit an XML document using a name/value
> pair, where the value is an XML document.  However, that doesn't seem
> very clean.  In an XML-based Web I just want to exchange XML documents.
If it is still the 'Web', then you want to access and control resources.
Exchanging documents is one use of the Web.

> The payload is clean - just an XML document.
>
> I would like to (boldly) assert that the name/value pair style is a
> remnant of HTML and is not suitable for an XML-based world!  Thus, I
> propose that in The New Web that HTTP POST be dropped.
Re-examine the meaning of POST and PUT - I think you will find that their
meanings are necessary:
 GET = get
 PUT = set
 POST = add
 DELETE = remove

These are 'generic' - they apply to all resources - but that does not mean
they are 'ambiguous' or open to wildly different server interpretations.









-----------------------------------------------------------------------------------
Post ID:2103
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-16 19:22:09
Subject:Re: [rest-discuss] No POST in an XML-based Web?
Message:

> ----- Original Message -----
> From: Ramin Firoozye

> In an XML-based web, GET would retrieve an XML document and/or structure
(given parameters),
> PUT would send an XML document and/or structure, and POST would invoke a
remote XML-based web-service.
I hate to sound like yet another blind person feeling up an elephant... but
a PUT would /set/ a remote resource to the state described by the message
body, and a POST would /extend/ the resource targeted by the request with
data described by the message body.

> A web-service would either require key-value parameters, or a 'structure'
that needs to be filled out and sent down.
> The form fields would be extended to allow filling the structure data and
then sending it to the remote procedure.
A real WEB service would not require any particular content format, but
would accept multiple formats. Simple name-value pairs in a name=value
format or <name>value</name> or whatever would work. A more extensible
structured XML would work. An GIF/JPG/PNG would work.









-----------------------------------------------------------------------------------
Post ID:2104
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-08-16 21:40:51
Subject:Re: [rest-discuss] Http Digest Authentication
Message:

How so? Works for me with MSIE6 and Mozilla...


----- Original Message -----
From: "Chris Croome" <chris@...>
To: <rest-discuss@yahoogroups.com>
Sent: Friday, August 16, 2002 3:50 AM
Subject: Re: [rest-discuss] Http Digest Authentication


> Hi
>
> On Fri 16-Aug-2002 at 07:40:43AM -0000, nixerman wrote:
> >
> > My question is: is the client expected to include the Digest HTTP
> > header in all further requests to the server?
>
> Yes.
>
> I was reading the HTTP book that was recommended on this list the other
> day and I was pleasantly surprised to read about the detail of digest
> authentication, it's a shame it's not fully supported by current
> browsers.
>
> Chris
>
> --
> Chris Croome                               <chris@...>
> web design                             http://www.webarchitects.co.uk/
> web content management                               http://mkdoc.com/
> everything else                               http://chris.croome.net/
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:2105
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-16 23:26:19
Subject:Re: [rest-discuss] RWS-SDL: WSDL for Rest?
Message:

nixerman wrote:
> 
> Guys,
> 
> Has anybody done any work on creating a WSDL-equivalent for REST?
> 
> I'm developing my own solution but I'm curious if there's work
> already being done.
> 
> - jkk


Various people have looked into this:

WRDL: http://www.prescod.net/rest/wrdl/wrdl.html
RestRDF: http://www.markbaker.ca/2002/03/RestRDF/

(http://216.239.33.100/search?q=cache:A3kH6uQIhDUC:www.markbaker.ca/2002/03/RestRDF/+restrdf&hl=en&ie=UTF-8)
Jason Diamond did some work on something simple also but I don't have
the URL equivalent.

-- 
"When I walk on the floor for the final execution, I'll wear a denim 
suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith 
-- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk."
Congressman James Traficant.






-----------------------------------------------------------------------------------
Post ID:2106
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-16 23:43:41
Subject:"abstract model for HTTP Resource State"
Message:

http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model

http://216.239.33.100/search?q=cache:Pff2INpuzUgC:www.markbaker.ca/2001/09/draft-baker-http-resource-state-model+abstract+model+for+http+resource+state&hl=en&ie=UTF-8

"3.1.3.1 Identity-preserving composite state resources   

   A specialized type of "composite state resource" described in
   section 3.1.3, this resource has the additional property that "P"
   assigns a new identity to the representation of the resource being
   POSTed, while making those resources available through "R".
"
   
I have a lot of trouble parsing that. First, can identity be assigned to
representations? What is the "resource being posted"? Is that the same
as the "resource being posted to"? What does "available through" mean?
In a hypertext sense that there is a link from R to these resources?

And anyway, why do we use the same method when we want to create new
sub-resources versus mutate the existing resource? Seems confusing.
Would a better name for "identity preserving" be "sub-resource
creating?"

-- 
"When I walk on the floor for the final execution, I'll wear a denim 
suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith 
-- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk."
Congressman James Traficant.






-----------------------------------------------------------------------------------
Post ID:2107
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-16 23:46:30
Subject:Re: [rest-discuss] No POST in an XML-based Web?
Message:

"Roger L. Costello" wrote:
> 

Note that XForms is a standardized way of generating user interfaces
that submit XML (or name-value pairs) through POST (and now PUT).
-- 
"When I walk on the floor for the final execution, I'll wear a denim 
suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith 
-- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk."
Congressman James Traficant.






-----------------------------------------------------------------------------------
Post ID:2108
Sender:Chris Croome <chris@...>
Post Date/Time:2002-08-17 15:58:46
Subject:Re: [rest-discuss] Http Digest Authentication
Message:

Hi

On Fri 16-Aug-2002 at 02:40:51 -0700, Mark Nottingham wrote:
> How so? Works for me with MSIE6 and Mozilla...

I was under the impression, perhaps mistakenly, that features of
improved digest authentication such as Replay Protection, Mutal
Authentication, Repeat Client Security and Integrity Protection were not
fully supported. I would be happy to be totally wrong about this :-)

Chris

-- 
Chris Croome                               <chris@...>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   
everything else                               http://chris.croome.net/  






-----------------------------------------------------------------------------------
Post ID:2109
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-08-18 12:26:45
Subject:Re: [rest-discuss] Http Digest Authentication
Message:

What spec are these features mentioned in?

Thanks,

Walden Mathews
  ----- Original Message ----- 
  From: Chris Croome 
  To: rest-discuss@yahoogroups.com 
  Sent: Saturday, August 17, 2002 11:58 AM
  Subject: Re: [rest-discuss] Http Digest Authentication


  Hi

  On Fri 16-Aug-2002 at 02:40:51 -0700, Mark Nottingham wrote:
  > How so? Works for me with MSIE6 and Mozilla...

  I was under the impression, perhaps mistakenly, that features of
  improved digest authentication such as Replay Protection, Mutal
  Authentication, Repeat Client Security and Integrity Protection were not
  fully supported. I would be happy to be totally wrong about this :-)

  Chris

  -- 
  Chris Croome                               <chris@...>
  web design                             http://www.webarchitects.co.uk/ 
  web content management                               http://mkdoc.com/   
  everything else                               http://chris.croome.net/  

        Yahoo! Groups Sponsor 
              ADVERTISEMENT
             
       

  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 






-----------------------------------------------------------------------------------
Post ID:2110
Sender:Chris Croome <chris@...>
Post Date/Time:2002-08-18 18:25:34
Subject:Re: [rest-discuss] Http Digest Authentication
Message:

Hi

On Sun 18-Aug-2002 at 08:26:45AM -0400, Walden Mathews wrote:
> What spec are these features mentioned in?

I read about them in 'HTTP Essentials' (a book) but I *think* this
is the RFC:

  ftp://ftp.isi.edu/in-notes/rfc2617.txt

Chris







-----------------------------------------------------------------------------------
Post ID:2111
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-18 21:05:35
Subject:Resource Creation
Message:

Guys,

Has it been established yet what the best practices are for resource 
creation? I know the verb PUT should be used with with the 201 
Created code but what should the target of the verb be?

Currently I'm using: 
PUT /app/rest/container/new
<?xml version="1.0" encoding="utf-8"?>
...

Where 'new' is a special dummy object which represents an 
uninitialized objects.

The standard response is:

HTTP 201 Created
Location: /app/rest/container/4242 (eg)
Host: http://www.example.com

Other possible responses include 402 Payment Required, 403 Forbidden, 
413 Request Entity Too Large.

My questions:

1) What is the best way to indicate error to the client when the 
client sends malformed XML to the server? I'm not sure whether 407 
Not Acceptable, 409 Conflict, or 400 Bad Request is best. Currently I 
use 400 but the rfc says this error code should be avoided and the 
server should aim to be as specific as possible.

2) Does it make sense to have a dummy 'new' resource that is the 
target of resource creation request? You could ask what the result of 
GET /app/rest/container/new is and I'm not sure since it rarely makes 
sense. This leads me to believe resource creation should be done by a 
POST to the container where POST means 'Append'. The rfc is not 
completely clear on the difference in this unique case--it seems to 
indicate either PUT or POST works.

3) When the client is generating entities who is responsible for 
generating etags? The server is usually responsible because the 
server usually generated the resource, but when the client does 
resource generation should it have the burden of generating etags 
too? Should clients be trusted to generate etags?

Thanks for your advice.

- inthedarkplace







-----------------------------------------------------------------------------------
Post ID:2112
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-18 22:46:20
Subject:Re: [rest-discuss] Resource Creation
Message:

inthedarkplace wrote:
> 
> Guys,
> 
> Has it been established yet what the best practices are for resource
> creation? I know the verb PUT should be used with with the 201
> Created code but what should the target of the verb be?

For what you're doing, POST is correct. PUT would return the "/new"
Location. PUT is like writing to a file (whether creating or
overwriting). POST is like asking the server to create a new file with a
particular content.

>...
> 1) What is the best way to indicate error to the client when the
> client sends malformed XML to the server? I'm not sure whether 407
> Not Acceptable, 409 Conflict, or 400 Bad Request is best. Currently I
> use 400 but the rfc says this error code should be avoided and the
> server should aim to be as specific as possible.

You mean 406 Not Acceptable.

I think that 406 is intended for declaring an inability to generate an
acceptable *response* entity, not for rejecting the request entity.

I think that 409 is similarly unsuitable because the problem has nothing
to do with a clash between current state and intended state.

So I think 400 is best: "The request could not be understood by the
server due to malformed syntax."

> 2) Does it make sense to have a dummy 'new' resource that is the
> target of resource creation request? You could ask what the result of
> GET /app/rest/container/new is and I'm not sure since it rarely makes
> sense. This leads me to believe resource creation should be done by a
> POST to the container where POST means 'Append'. The rfc is not
> completely clear on the difference in this unique case--it seems to
> indicate either PUT or POST works.

I think POST is right. 

> 3) When the client is generating entities who is responsible for
> generating etags? The server is usually responsible because the
> server usually generated the resource, but when the client does
> resource generation should it have the burden of generating etags
> too? Should clients be trusted to generate etags?

The client can't really do resource generation in REST. The client can
hand a representation to the server and say "make this a resource
please" but that's different. So in the end the server has
responsibility for generating etags whether it created the resource from
scratch or from a supplied representation.
-- 
"When I walk on the floor for the final execution, I'll wear a denim 
suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith 
-- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk."
Congressman James Traficant.






-----------------------------------------------------------------------------------
Post ID:2113
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-18 23:41:41
Subject:Re: "abstract model for HTTP Resource State"
Message:

On Fri, Aug 16, 2002 at 07:43:41PM -0400, Paul Prescod wrote:
> "3.1.3.1 Identity-preserving composite state resources   
> 
>    A specialized type of "composite state resource" described in
>    section 3.1.3, this resource has the additional property that "P"
>    assigns a new identity to the representation of the resource being
>    POSTed, while making those resources available through "R".
> "
>    
> I have a lot of trouble parsing that. First, can identity be assigned to
> representations?

Sure.  They have identity.

> What is the "resource being posted"?

The wording assumes that the information being posted is the
representation of an existing resource, which may not be the case,
granted.

> Is that the same
> as the "resource being posted to"?

No.  The resource being posted to would be the container, like an
email archive, for example.

> What does "available through" mean?
> In a hypertext sense that there is a link from R to these resources?

Not just a link, but a subordinate relationship.  e.g. you might be
addressing http://example.org/foo/bar/baz, but /foo/bar/ could be a
container which is code which decides if/when/how you get to look at
'baz'.  The container may recognize that 'baz' is now unavailable and
return a 404, or permanently gone and return a 410.  etc..

> And anyway, why do we use the same method when we want to create new
> sub-resources versus mutate the existing resource? Seems confusing.

POST is the catch-all mutator in REST.  If there's a need to break out
a specific expected behaviour into its own method, then that's ok.  But
I personally prefer doing things in the POST-to-a-container model, ala
SOAPAction.

> Would a better name for "identity preserving" be "sub-resource
> creating?"

No, I was trying to get across that the processing done in P is
loss-less.  i.e. that what is POSTed will be what you get back when
you do a GET on the Location header in the 201 response.  Actually,
I suppose that's more "state preserving" than "identity preserving",
since there is no identity to preserve.  Oops.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2114
Sender:"Jean Berdge"<hghsupport2000@...>
Post Date/Time:2002-08-19 10:57:32
Subject:restaurants,Increase sexual energy and potency - or your money back!
Message:

Hello, restaurants@...

As seen on NBC, CBS, and CNN, and even Oprah! The health
discovery that actually reverses aging while burning fat,
without dieting or exercise! This proven discovery has even
been reported on by the New England Journal of Medicine.
Forget aging and dieting forever! And it's Guaranteed!


* Reduce body fat and build lean muscle WITHOUT EXERCISE!
* Enhace sexual performance
* Remove wrinkles and cellulite
* Lower blood pressure and improve cholesterol profile
* Improve sleep, vision and memory
* Restore hair color and growth
* Strengthen the immune system
* Increase energy and cardiac output
* Turn back your body's biological time clock 10-20 years
in 6 months of usage !!!

FOR FREE INFORMATION AND GET FREE 1 MONTH SUPPLY OF HGH CLICK HERE















You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here




-----------------------------------------------------------------------------------
Post ID:2115
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-19 20:34:53
Subject:Limitations of HTTP GET
Message:

Guys,

From: http://www.gotdotnet.com/team/dbox/spoutlet.aspx?key=2002-07-
11T21:50-08:00

<blockquote>For one, SOAP doesn't force me to encode my query as a 
URI (for example, I could use XML Query or XSLT to express the query 
expression). Also, SOAP's message model allows me to qualify queries 
through use of transport-neutral headers. For example, I may not have 
HTTP-based access to your machine, yet I may still want to send a 
SOAP request (over Jabber perhaps) that queries something on your 
box. By adopting the SOAP messaging model, I can express any number 
of aspects of my query (e.g., signatures, privacy requirements, 
idempotency, cache control) using fairly rich XML-based 
headers.</blockquote>

Is this true? I don't see anything in the spec which says that a HTTP 
GET request is not allowed to have an entity body (and therefore 
contain XML documents or anything).

Please comment.

- inthedarkplace







-----------------------------------------------------------------------------------
Post ID:2116
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-19 21:07:02
Subject:Re: [rest-discuss] Limitations of HTTP GET
Message:

On Mon, Aug 19, 2002 at 08:34:53PM -0000, inthedarkplace wrote:
> Guys,
> 
> From: http://www.gotdotnet.com/team/dbox/spoutlet.aspx?key=2002-07-
> 11T21:50-08:00
> 
> <blockquote>For one, SOAP doesn't force me to encode my query as a 
> URI (for example, I could use XML Query or XSLT to express the query 
> expression). Also, SOAP's message model allows me to qualify queries 
> through use of transport-neutral headers. For example, I may not have 
> HTTP-based access to your machine, yet I may still want to send a 
> SOAP request (over Jabber perhaps) that queries something on your 
> box. By adopting the SOAP messaging model, I can express any number 
> of aspects of my query (e.g., signatures, privacy requirements, 
> idempotency, cache control) using fairly rich XML-based 
> headers.</blockquote>
> 
> Is this true? I don't see anything in the spec which says that a HTTP 
> GET request is not allowed to have an entity body (and therefore 
> contain XML documents or anything).

It's a feature, not a bug, that identifying information should go in
the URI.  There's a large cost for not doing so, in that you can't hand
the identifier around to other people.

So while it might be cool to use XML like this to identify me;

  <person>Mark Baker</person>

There's no deployed way to actually turn that into information about me
over a network.  Oops!

Besides, there's always my POST/201/GET idiom to get the best of both
worlds, if you can afford an extra round trip;

http://lists.w3.org/Archives/Public/www-tag/2002Jan/0232

And FWIW, the GET/body issue just popped up again on the HTTP WG mailing
list;

http://lists.w3.org/Archives/Public/ietf-http-wg/2002JulSep/thread.html#24

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2117
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-19 21:14:39
Subject:Re: [rest-discuss] Limitations of HTTP GET
Message:

I can't follow that URI but these are all standards complaints and IMO
misguided.

inthedarkplace wrote:
> 
> Guys,
> 
> From: http://www.gotdotnet.com/team/dbox/spoutlet.aspx?key=2002-07-
> 11T21:50-08:00
> 
> <blockquote>For one, SOAP doesn't force me to encode my query as a
> URI (for example, I could use XML Query or XSLT to express the query
> expression). 

Let's be clear right off the bat that properly-executed REST is more
syntactically restrictive than SOAP. REST imposes a discipline that
leads to more interoperable applications. SOAP advocates only see the
discipline and not the interoperability benefits. SOAP makes almost no
demand on application developers. In all seriousness you can take a
proprietary binary protocol and claim that it is legal SOAP and justify
it through the SOAP specification!

This issue of interoperability versus "flexibility" is discussed more
here:

 * http://www.prescod.net/rest/rest_vs_soap_overview/

There is obviously nothing in HTTP that prevents querying using XML
Query or XSLT over POST but it is usually not good REST design. In fact,
it is usually not good *distributed application design*. Sending XML
Query is like sending arbitrary SQL over the network. Sending XSLT is
like sending executable code. Neither makes sense across the trust
boundaries that make the Internet so interesting.

I've discussed this here:

 * http://www.prescod.net/rest/rpc_for_get.html

If you redesign your service interface to use the Web's query model
rather than XML Query's, you get better security, better addressability,
better interoperability and a simpler interface to boot.

> ... Also, SOAP's message model allows me to qualify queries
> through use of transport-neutral headers. 

If you and your partner agree to use SOAP you have to implement SOAP
handlers on both ends. If you and your partner agree to use HTTP you
have to implement HTTP handlers on both ends. HTTP headers are equally
"transport neutral". They don't care whether you are using TCP or some
proprietary protocol.

> ... For example, I may not have
> HTTP-based access to your machine, yet I may still want to send a
> SOAP request (over Jabber perhaps) that queries something on your
> box. 

What box in the world has Jabber but not HTTP? What implementation
language is the jabber engine implemented in which is lacking an HTTP
server like the free ones you can download for Java, Python, Perl, C,
...

> ....By adopting the SOAP messaging model, I can express any number
> of aspects of my query (e.g., signatures, privacy requirements,
> idempotency, cache control) using fairly rich XML-based
> headers.</blockquote>

There are obviously standard HTTP headers for cache control and privacy.
Idempotency is guaranteed by the methods (headers for idempotency don't
make much sense to me). Signatures are no problem although I haven't
seen that done myself.

So Don is saying that with SOAP you *could do* all of these wonderful
things in the future and I say that with HTTP you *can do* most of these
wonderful things using existing standards today.
-- 
"When I walk on the floor for the final execution, I'll wear a denim 
suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith 
-- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk."
Congressman James Traficant.






-----------------------------------------------------------------------------------
Post ID:2118
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-20 00:45:41
Subject:RESTful URLs and sessions (broken record)
Message:

Okay, I know this has been talked about on the list in various ways before,
but I am still trying to grasp what the "proper" format of RESTful URLs
should be when taking into account the concept of sessions.  To put this in
context, I am starting up on a small project (written in PHP), the core of
which will be a sort of content management system.  Documents will be
publicly viewable, but additional features will require people to log in and
have an active "session".

So, Here's the general layout of the paths I am going to use:

/doc.php/docID

"docID" will be a unique value that identifies a given document.  The
returned document (html only for now) will contain the following links:

/doc.php/docID/discussions
/doc.php/docID/references
/doc.php/docID/revisions
/doc.php/docID/subdocuments

Each of those will contain additional links, etc.  I am comfortable with
this and it seems quite clean and simple to maintain.  However, these URLs
can be accessed in one of two modes.  A given viewer can have GET access or
can have POST access.  GET access basically allows a viewer to follow links.
However, there are several features where the view can choose to be
interactive (e.g. create references, post discussion messages, etc.).  When
this is the case, the viewer must be authenticated.

My current design requires a viewer to log in and create a session in order
to provide the necessary authentication.  Traditionally, I would have
created a session ID and passed it around in the query string of every URL
on a page.  However, as I get more an more into REST, I am beginning to
wonder if this is the right way of going about it.

There has been discussion as to whether

/doc.php/docID

and

/doc.php/docID?sid=12345

are equivalent URLs.  My take on them (now) is that they are actually two
different URLs that happen to return representations of the same resource.

However, the second URL contains a series of characters (the entire query
string in this case) that has nothing to do with the resource itself.
Therefore, it seems to me that it is not appropriate to use this URL to
point to the same resource as the first URL does, especially since in many
of the cases the same exact representation will be returned to the viewer.

I also do not want to use cookies to store the session ID for many reasons.
So what do I do?  How do I provide a common authentication mechanism that's
supported by most browsers and still keeps the URLs simple can clean (and
therefore more RESTful, I think)?

Or am I totally misunderstanding the REST issues for tracking sessions?

---
Seairth Jacobs
seairth@...








-----------------------------------------------------------------------------------
Post ID:2119
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-20 01:00:22
Subject:Re: [rest-discuss] RESTful URLs and sessions (broken record)
Message:

On Mon, Aug 19, 2002 at 08:45:41PM -0400, Seairth Jacobs wrote:
> I also do not want to use cookies to store the session ID for many reasons.
> So what do I do?  How do I provide a common authentication mechanism that's
> supported by most browsers and still keeps the URLs simple can clean (and
> therefore more RESTful, I think)?

Use HTTP authentication, and have your app check to see if the request
is authenticated or not while it constructs the content to return.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2120
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-20 01:18:02
Subject:RFC: RWS-Signon
Message:

Heya Guys,

I've been asked to rearchitect the design for a widely distributed 
content management system based on .NET, IRC and REST.

I'm looking for any comments based on a simply single-signon system 
I'm reworking to make more REST-ful. I wrote up a quick summary of 
the existing system at:

http://jkk.sumnurv.com/RWS-Signon-SpecLite.rtf

Lemme know what you think.

- inthedarkplace







-----------------------------------------------------------------------------------
Post ID:2121
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-20 02:03:27
Subject:WebDAV
Message:

Guys,

I'm just wondering how people feel about WebDAV. Personally I don't 
like it since I feel there's a more elegant (read RESTful) way to 
develop it rather than adding verbs to HTTP 1.1.

What do others think?

- inthedarkplace







-----------------------------------------------------------------------------------
Post ID:2122
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-08-20 07:02:43
Subject:RE: [rest-discuss] WebDAV
Message:

> From: inthedarkplace [mailto:inthedarkplace@...]
> Sent: Tuesday, August 20, 2002 4:03 AM
> To: rest-discuss@yahoogroups.com
> Subject: [rest-discuss] WebDAV
>
>
> Guys,
>
> I'm just wondering how people feel about WebDAV. Personally I don't
> like it since I feel there's a more elegant (read RESTful) way to
> develop it rather than adding verbs to HTTP 1.1.
>
> What do others think?

Make a proposal.

I've seen some ideas about giving properties their own URLs, but those were
just some ideas. One would need a more complete proposal to decide whether
this would work well.

Besides, why would be adding new verbs unRESTful?








-----------------------------------------------------------------------------------
Post ID:2123
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-08-20 07:10:10
Subject:RE: [rest-discuss] WebDAV
Message:

> I've seen some ideas about giving properties their own URLs, but those were
> just some ideas. One would need a more complete proposal to decide whether
> this would work well.
> 
> Besides, why would be adding new verbs unRESTful?

Presumably adding a synonym for GET which only applied to properties would 
not be very RESTful, as they could be exposed as resources in their own 
right. Adding verbs for locking or other strange things with new and 
unusual semantics would certainly be a good idea though...

Michael







-----------------------------------------------------------------------------------
Post ID:2124
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-08-20 08:40:09
Subject:RE: [rest-discuss] WebDAV
Message:

> From: Michael Day [mailto:mikeday@...]
> Sent: Tuesday, August 20, 2002 9:10 AM
> To: rest-discuss@yahoogroups.com
> Subject: RE: [rest-discuss] WebDAV
>
>
>
> > I've seen some ideas about giving properties their own URLs,
> but those were
> > just some ideas. One would need a more complete proposal to
> decide whether
> > this would work well.
> >
> > Besides, why would be adding new verbs unRESTful?
>
> Presumably adding a synonym for GET which only applied to
> properties would
> not be very RESTful, as they could be exposed as resources in their own

Yes, they could. Possibly. I think the discussion would be more interesting
if someone would present a workable proposal how to implement this, without
losing the PROPFIND/depth 1 functionality of WebDAV.

BTW: HEAD gets a fixed set of properties (entitity headers) as well. It's
not really different from PROPFIND/depth 0. So is HEAD unRESTful?

> right. Adding verbs for locking or other strange things with new and
> unusual semantics would certainly be a good idea though...

Correct. The interesting part is to decide wether a specific feature should
be a new verb or can be "tunnelled" through existing methods.








-----------------------------------------------------------------------------------
Post ID:2125
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-08-20 10:06:32
Subject:RE: [rest-discuss] WebDAV
Message:

> BTW: HEAD gets a fixed set of properties (entitity headers) as well. It's
> not really different from PROPFIND/depth 0. So is HEAD unRESTful?

More to the point, does anyone use HEAD on a regular basis? I would be
interested to hear some uses people might have for it.

Michael







-----------------------------------------------------------------------------------
Post ID:2126
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-08-20 10:28:13
Subject:RE: [rest-discuss] WebDAV
Message:

> From: Michael Day [mailto:mikeday@...]
> Sent: Tuesday, August 20, 2002 12:07 PM
> To: rest-discuss@yahoogroups.com
> Subject: RE: [rest-discuss] WebDAV
>
>
>
> > BTW: HEAD gets a fixed set of properties (entitity headers) as
> well. It's
> > not really different from PROPFIND/depth 0. So is HEAD unRESTful?
>
> More to the point, does anyone use HEAD on a regular basis? I would be
> interested to hear some uses people might have for it.

Well, we use it to fetch metadata about a resource without actually having
to get it's contents. That's what it's for, right?

Besides, GET gets the same amount of metadata as HEAD, and I don't think
that anybody claims that GET is unRESTful :-)








-----------------------------------------------------------------------------------
Post ID:2127
Sender:Chris Croome <chris@...>
Post Date/Time:2002-08-20 12:44:40
Subject:Debugging HTTP Headers [Was: Re: [rest-discuss] WebDAV]
Message:

Hi

On Tue 20-Aug-2002 at 08:06:32PM +1000, Michael Day wrote:
> 
> More to the point, does anyone use HEAD on a regular basis? I would be
> interested to hear some uses people might have for it.

Yes, I use HEAD often, for checking HTTP headers:

  $ lynx -head -dump http://example.com/

If you want to check GZ'ed content  you have to use something else like
Apache benchmark:

  $ /usr/local/apache/bin/ab -v 4 -n 1 -H \
    "Accept-Encoding: gzip, deflate" -i http://example.com/

Chris

-- 
Chris Croome                               <chris@...>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   
everything else                               http://chris.croome.net/  






-----------------------------------------------------------------------------------
Post ID:2128
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-20 14:05:03
Subject:Re: [rest-discuss] WebDAV
Message:

Julian Reschke wrote:
> 
>...
> 
> Yes, they could. Possibly. I think the discussion would be more interesting
> if someone would present a workable proposal how to implement this, without
> losing the PROPFIND/depth 1 functionality of WebDAV.

Is there any chance of the proposal making its way into software within
our lifetimes or is it just for intellectual interest? ;)

One could imagine combining the proposal with an idea unifying WebDAV
properties with the RDF model.
-- 
"When I walk on the floor for the final execution, I'll wear a denim 
suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith 
-- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk."
Congressman James Traficant.






-----------------------------------------------------------------------------------
Post ID:2129
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-08-20 16:22:15
Subject:RE: [rest-discuss] WebDAV
Message:

> From: Paul Prescod [mailto:paul@...]
> Sent: Tuesday, August 20, 2002 4:05 PM
> To: Julian Reschke
> Cc: Michael Day; rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] WebDAV
>
>
> Julian Reschke wrote:
> >
> >...
> >
> > Yes, they could. Possibly. I think the discussion would be more
> interesting
> > if someone would present a workable proposal how to implement
> this, without
> > losing the PROPFIND/depth 1 functionality of WebDAV.
>
> Is there any chance of the proposal making its way into software within
> our lifetimes or is it just for intellectual interest? ;)

Well,

I'd imagine that this would just introduce a second way to access/modify
metadata, so it could be introduced in a backwards-compatible way. I'm sure
that if the model is sound and has real benefits over PROPFIND,
Apache/moddav would adopt really fast...

> One could imagine combining the proposal with an idea unifying WebDAV
> properties with the RDF model.

Interesting. Could you elaborate?







-----------------------------------------------------------------------------------
Post ID:2130
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-20 16:34:03
Subject:Re: [rest-discuss] WebDAV
Message:

Julian Reschke wrote:
> 
>...
> 
> Well,
> 
> I'd imagine that this would just introduce a second way to access/modify
> metadata, so it could be introduced in a backwards-compatible way. I'm sure
> that if the model is sound and has real benefits over PROPFIND,
> Apache/moddav would adopt really fast...

Okay, thanks. I don't know if I'll have time for it.

> > One could imagine combining the proposal with an idea unifying WebDAV
> > properties with the RDF model.
> 
> Interesting. Could you elaborate?

Truthfully, not really. I haven't thought it through yet. Basically it
would be cool if you could use all RDF tools on WebDAV properties. Maybe
you can do that now by just using RDF in properties.
-- 
"When I walk on the floor for the final execution, I'll wear a denim 
suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith 
-- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk."
Congressman James Traficant.






-----------------------------------------------------------------------------------
Post ID:2131
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-19 19:28:21
Subject:Re: [rest-discuss] Resource Creation
Message:

----- Original Message -----
From: "inthedarkplace" <inthedarkplace@...>


> I know the verb PUT should be used with with the 201
> Created code but what should the target of the verb be?
I think POST is fine with the 201 response as well.

>
> Currently I'm using:
> PUT /app/rest/container/new
> <?xml version="1.0" encoding="utf-8"?>
> ...
>
> Where 'new' is a special dummy object which represents an
> uninitialized objects.
I think PUT to that URI means 'set' - so you would be better off using POST
to create new resources.
PUT is for updating known resources (a 'create' can be thought of as
'initial update').


>
> 1) What is the best way to indicate error to the client when the
> client sends malformed XML to the server? I'm not sure whether 407
> Not Acceptable, 409 Conflict, or 400 Bad Request is best. Currently I
> use 400 but the rfc says this error code should be avoided and the
> server should aim to be as specific as possible.

I wouldn't use "406 Not Acceptable" - this indicates that the format of the
/response/ doesn't match what the request asked for.
Problems with the format of the request probably should use "415 Unsupported
Media Type" - "The server is refusing to service the request because the
entity of the request is in a format not supported by the requested resource
for the requested method"


>
> 2) Does it make sense to have a dummy 'new' resource that is the
> target of resource creation request? You could ask what the result of
> GET /app/rest/container/new is and I'm not sure since it rarely makes
> sense. This leads me to believe resource creation should be done by a
> POST to the container where POST means 'Append'. The rfc is not
> completely clear on the difference in this unique case--it seems to
> indicate either PUT or POST works.
I'd recomment using POST as well.








-----------------------------------------------------------------------------------
Post ID:2132
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-08-21 01:02:57
Subject:PUT or POST Clarification
Message:

Let's say I've already POSTed a purchase order, which has been accepted and assigned
a URI by the server, and I'm allowed to modify it.  I notice I've misspelled my name, so I want to
correct that on the PO.  I could PUT a corrected copy of the whole PO, but what method do
I use if I only want to send the name field?  The name is "subordinate" to the PO, but this is
not an append type operation, and it happens to be idempotent, too.  If I use an XML PO
document with only the name field used, should that be a PUT, or is it always assumed that
PUT carries the full state of the addressed resource?

Walden Mathews





-----------------------------------------------------------------------------------
Post ID:2133
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-21 01:21:52
Subject:Re: PUT or POST Clarification
Message:

On Tue, Aug 20, 2002 at 09:02:57PM -0400, Walden Mathews wrote:
> Let's say I've already POSTed a purchase order, which has been accepted and assigned
> a URI by the server, and I'm allowed to modify it.  I notice I've misspelled my name, so I want to
> correct that on the PO.  I could PUT a corrected copy of the whole PO, but what method do
> I use if I only want to send the name field?  The name is "subordinate" to the PO, but this is
> not an append type operation, and it happens to be idempotent, too.  If I use an XML PO
> document with only the name field used, should that be a PUT, or is it always assumed that
> PUT carries the full state of the addressed resource?

Yup, the full state needs to go in a PUT.

You could negotiate name-changing behaviour such that a POST of a
representation of a name to the document resulted in the change, but
that's extra work for little benefit, as I see it.

You could also give the name its own URI, and do a PUT on it, but that
has its own problems; that the PO is a contract, and so should be
self-contained.  In other non-contract cases, this might be ok.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2134
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-08-21 08:43:06
Subject:RE: [rest-discuss] WebDAV
Message:

> From: Paul Prescod [mailto:paul@...] 
>
> > Julian Reschke wrote:
>
> > Interesting. Could you elaborate?
> 
> Truthfully, not really. I haven't thought it through yet. 
> Basically it would be cool if you could use all RDF tools on 
> WebDAV properties. Maybe you can do that now by just using 
> RDF in properties.

Mixing WebDAV with RDF is a win imo. The idea pops up every now and them
on rdf lists. . I /think/ the WebDAV folks considered using RDF and
decided not to. You should also look into DASL queries returning RDF
graphs

regards,
Bill de hra
..
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:2135
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-21 14:06:07
Subject:Security in a REST world?
Message:

Hello,

We are developing a REST system using straight HTTP and RDF.  We have n 
clients (both machine and humans) GETting and PUTting RDF into the 
system via HTTP.

The question is, are there any security frameworks for a HTTP world 
where the URI is opaque?  By that I mean, if the URI is virtual and 
doesn't have enough information in it to answer authorization questions, 
how would I go about securing my application?

Since that is, obviously, a huge question, I'll try to add some 
requirements.  Hopefully they are REST generic, as we are trying to stay 
within HTTP and REST.

The interface into the system is HTTP, so our methods are PUT, GET, and 
DELETE.  We then have users, and the objects they are PUT, GET, and 
DELETE.  Using Apache as an example, I can control who can access what 
URIs via GET.  That's fine if GET was the only method /and/ if the URIs 
are physical.  In our case, we can PUT and DELETE, plus the URIs point 
to virtual resources (constructed from data in a database).

We need to construct policies that have:

- Actor
- Method
- URI
- Content Filter

Where:

- Actor is the person (or machine) performing the HTTP call
- Method is GET, PUT, or DELETE
- URI is the (regexp?) pattern of the URI
- Content Filter is a collection of filters that can validate the 
content (body) of the HTTP call.  For instance, we need to allow Frank 
to PUT to /service/stuff/* ONLY documents that pass validations (like 
validate on an XML Schema or DAML+OIL schema)

What we've found is that simple Actor+Method+URI policies aren't enough. 
  We need to validate the incoming body of the HTTP request as well.

So, are there frameworks out there that do this sort of thing?  I looked 
at Apache and it doesn't seem to offer this type of control.  Our 
application is written in Java and Servlets, and the servlet environment 
doesn't seem to have those types of controls, either.

Any experience with this type of security system would be greatly 
appreciated!  I'll post a summary of useful information.

Thanks again,
Seth





-----------------------------------------------------------------------------------
Post ID:2136
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-21 14:23:46
Subject:RE: [rest-discuss] Security in a REST world?
Message:

I would say that servlet has most of what you want, and the part it doesn't
have has to come from your app anyhow.

Servelt config allows you to use servlet-mapping syntax and HTTP methods
to describe security domains, on each of which you can establish
authentication
and other security attributes.  See the latest Servlet spec, or pick up
Jason Hunter's O'Reilly book on the subject.

Your application still needs to *authorize* users after they've been HTTP
authenticated.  And your application needs to apply whatever filters to the
content to "authorize" that as well.

Hope this helps,

Walden Mathews

> -----Original Message-----
> From: Seth Ladd [mailto:seth@...]
> Sent: Wednesday, August 21, 2002 10:06 AM
> To: rest-discuss@yahoogroups.com
> Subject: [rest-discuss] Security in a REST world?
> 
> 
> Hello,
> 
> We are developing a REST system using straight HTTP and RDF.  
> We have n 
> clients (both machine and humans) GETting and PUTting RDF into the 
> system via HTTP.
> 
> The question is, are there any security frameworks for a HTTP world 
> where the URI is opaque?  By that I mean, if the URI is virtual and 
> doesn't have enough information in it to answer authorization 
> questions, 
> how would I go about securing my application?
> 
> Since that is, obviously, a huge question, I'll try to add some 
> requirements.  Hopefully they are REST generic, as we are 
> trying to stay 
> within HTTP and REST.
> 
> The interface into the system is HTTP, so our methods are 
> PUT, GET, and 
> DELETE.  We then have users, and the objects they are PUT, GET, and 
> DELETE.  Using Apache as an example, I can control who can 
> access what 
> URIs via GET.  That's fine if GET was the only method /and/ 
> if the URIs 
> are physical.  In our case, we can PUT and DELETE, plus the 
> URIs point 
> to virtual resources (constructed from data in a database).
> 
> We need to construct policies that have:
> 
> - Actor
> - Method
> - URI
> - Content Filter
> 
> Where:
> 
> - Actor is the person (or machine) performing the HTTP call
> - Method is GET, PUT, or DELETE
> - URI is the (regexp?) pattern of the URI
> - Content Filter is a collection of filters that can validate the 
> content (body) of the HTTP call.  For instance, we need to 
> allow Frank 
> to PUT to /service/stuff/* ONLY documents that pass validations (like 
> validate on an XML Schema or DAML+OIL schema)
> 
> What we've found is that simple Actor+Method+URI policies 
> aren't enough. 
>   We need to validate the incoming body of the HTTP request as well.
> 
> So, are there frameworks out there that do this sort of 
> thing?  I looked 
> at Apache and it doesn't seem to offer this type of control.  Our 
> application is written in Java and Servlets, and the servlet 
> environment 
> doesn't seem to have those types of controls, either.
> 
> Any experience with this type of security system would be greatly 
> appreciated!  I'll post a summary of useful information.
> 
> Thanks again,
> Seth
> 






-----------------------------------------------------------------------------------
Post ID:2137
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-21 14:33:55
Subject:Re: [rest-discuss] Re: PUT or POST Clarification
Message:

Mark Baker wrote:
> 
>...
> 
> Yup, the full state needs to go in a PUT.
> 
> You could negotiate name-changing behaviour such that a POST of a
> representation of a name to the document resulted in the change, but
> that's extra work for little benefit, as I see it.
> 
> You could also give the name its own URI, and do a PUT on it, but that
> has its own problems; that the PO is a contract, and so should be
> self-contained.  In other non-contract cases, this might be ok.

So you are saying: "Use PUT but send the whole PO?"
-- 
 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2138
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-21 14:38:11
Subject:RE: [rest-discuss] Re: PUT or POST Clarification
Message:

 >Yup, the full state needs to go in a PUT.

 > You could negotiate name-changing behaviour such that a POST of a
 > re  presentation of a name to the document resulted in the change, but
 > that  's extra work for little benefit, as I see it. 
 
 If I POST the following XML (sans XML Schema namespace clutter)
 
    <PO>
        <name>Walden H. Mathews</name>
    </PO>
 
to the URI at which the PO is living, what would need to be negotiated?  In
other words,
what other interpretation of my intent do you see in that example?
 
Walden 







-----------------------------------------------------------------------------------
Post ID:2139
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-21 14:39:08
Subject:Re: [rest-discuss] Re: PUT or POST Clarification
Message:

On Wed, Aug 21, 2002 at 07:33:55AM -0700, Paul Prescod wrote:
> So you are saying: "Use PUT but send the whole PO?"

Yep.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2140
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-21 14:46:42
Subject:Re: [rest-discuss] Re: PUT or POST Clarification
Message:

On Wed, Aug 21, 2002 at 10:38:11AM -0400, Mathews, Walden wrote:
>  If I POST the following XML (sans XML Schema namespace clutter)
>  
>     <PO>
>         <name>Walden H. Mathews</name>
>     </PO>
>  
> to the URI at which the PO is living, what would need to be negotiated?  In
> other words,
> what other interpretation of my intent do you see in that example?

Other interpretations of that action could be;

- adding a contact who's allowed to sign for the package
- adding a co-signer on the contract
- adding information about the manager who authorized the purchase
etc..

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2141
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-21 15:01:50
Subject:RE: [rest-discuss] Re: PUT or POST Clarification
Message:

Okay, but XML Schema could clear up all that confusion, couldn't it?
Since I didn't share the schema here, I couldn't expect you to know
that <PO/> allows exactly one <name/> element at that level.  Do you
still see multiple interpretations?

> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Wednesday, August 21, 2002 10:47 AM
> To: Mathews, Walden
> Cc: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Re: PUT or POST Clarification
> 
> 
> On Wed, Aug 21, 2002 at 10:38:11AM -0400, Mathews, Walden wrote:
> >  If I POST the following XML (sans XML Schema namespace clutter)
> >  
> >     <PO>
> >         <name>Walden H. Mathews</name>
> >     </PO>
> >  
> > to the URI at which the PO is living, what would need to be 
> negotiated?  In
> > other words,
> > what other interpretation of my intent do you see in that example?
> 
> Other interpretations of that action could be;
> 
> - adding a contact who's allowed to sign for the package
> - adding a co-signer on the contract
> - adding information about the manager who authorized the purchase
> etc..
> 
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
> 






-----------------------------------------------------------------------------------
Post ID:2142
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-21 15:13:51
Subject:Re: [rest-discuss] Re: PUT or POST Clarification
Message:

On Wed, Aug 21, 2002 at 11:01:50AM -0400, Mathews, Walden wrote:
> Okay, but XML Schema could clear up all that confusion, couldn't it?
> Since I didn't share the schema here, I couldn't expect you to know
> that <PO/> allows exactly one <name/> element at that level.  Do you
> still see multiple interpretations?

We might be able to construct an example where there's only one
interpretation of a POST example, but that doesn't suggest that this
is a good general solution.  It would require rethinking how schemas
are designed.  For example, you wouldn't want to use "name" elements
in multiple places, you'd have to use "purchaserName" and "shipToName",
etc.. rather than using a "purchaser" element which includes a "name"
element.  That's quite a burden to place on schema designers.

IMO, the best approach is to separate the concerns of specifying the
valid state of resources (XML schema, RDF, etc..), from the ways in
which the state is manipulated.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2143
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-21 15:29:10
Subject:Re: [rest-discuss] Security in a REST world?
Message:

> Your application still needs to *authorize* users after they've been HTTP
> authenticated.  And your application needs to apply whatever filters to the
> content to "authorize" that as well.

Exactly.  Authentication is easy, and nicely taken care of by the 
servlet container.  It's the Authentication that becomes more difficult. 
  What we're looking for is a framework that allows us to plug in rules 
for authorization and ask the question "Can User U PUT Data D?" easily. 
  I haven't seen much in controling PUT and DELETE.  I would love to do 
it in the Apache level, much like I can control GET there.

Seth





-----------------------------------------------------------------------------------
Post ID:2144
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-21 15:34:08
Subject:RE: [rest-discuss] Re: PUT or POST Clarification
Message:

<PO>
	<purchaser>
		<name>Walden H. Mathews</name>
	</purchaser>
	<ship-to>
		<name>Mark Q. Baker</name>
	</ship-to>
</PO>

I come from a market data feed application environment in which
bandwidth conservation is king, and the rule of thumb is "send only
the changes".  According to our understanding of HTTP "morph"
methods, it's not a good fit.  But the above looks clearly intended
to me.

Of course the kind of optimization I'm trying for here depends
on the MTU, something which in HTTP/TCP I can't influence, whereas
I "owned" that part of the transport in my datafeed apps.

Walden

> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Wednesday, August 21, 2002 11:14 AM
> To: Mathews, Walden
> Cc: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Re: PUT or POST Clarification
> 
> 
> On Wed, Aug 21, 2002 at 11:01:50AM -0400, Mathews, Walden wrote:
> > Okay, but XML Schema could clear up all that confusion, couldn't it?
> > Since I didn't share the schema here, I couldn't expect you to know
> > that <PO/> allows exactly one <name/> element at that level.  Do you
> > still see multiple interpretations?
> 
> We might be able to construct an example where there's only one
> interpretation of a POST example, but that doesn't suggest that this
> is a good general solution.  It would require rethinking how schemas
> are designed.  For example, you wouldn't want to use "name" elements
> in multiple places, you'd have to use "purchaserName" and 
> "shipToName",
> etc.. rather than using a "purchaser" element which includes a "name"
> element.  That's quite a burden to place on schema designers.
> 
> IMO, the best approach is to separate the concerns of specifying the
> valid state of resources (XML schema, RDF, etc..), from the ways in
> which the state is manipulated.
> 
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
> 






-----------------------------------------------------------------------------------
Post ID:2145
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-21 15:34:55
Subject:Re: [rest-discuss] Security in a REST world?
Message:

I'd implement it as a proxy, and put all my rules there.  Authentication
would remain at the origin server, and the proxy would know that.

MB

On Wed, Aug 21, 2002 at 11:29:10AM -0400, Seth Ladd wrote:
> 
> > Your application still needs to *authorize* users after they've been HTTP
> > authenticated.  And your application needs to apply whatever filters to the
> > content to "authorize" that as well.
> 
> Exactly.  Authentication is easy, and nicely taken care of by the 
> servlet container.  It's the Authentication that becomes more difficult. 
>   What we're looking for is a framework that allows us to plug in rules 
> for authorization and ask the question "Can User U PUT Data D?" easily. 
>   I haven't seen much in controling PUT and DELETE.  I would love to do 
> it in the Apache level, much like I can control GET there.
> 
> Seth



-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2146
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-21 15:45:57
Subject:Re: [rest-discuss] Re: PUT or POST Clarification
Message:

On Wed, Aug 21, 2002 at 11:34:08AM -0400, Mathews, Walden wrote:
> <PO>
> 	<purchaser>
> 		<name>Walden H. Mathews</name>
> 	</purchaser>
> 	<ship-to>
> 		<name>Mark Q. Baker</name>
> 	</ship-to>
> </PO>

Ok, like I say I'm sure there's a way to construct an example with a
single interpretation.  You'd just have to jump through hoops to do this
as a general solution.  It also doesn't help if you don't control the
schemas you're using, which will become increasingly common as their
standardized.

> I come from a market data feed application environment in which
> bandwidth conservation is king, and the rule of thumb is "send only
> the changes".  According to our understanding of HTTP "morph"
> methods, it's not a good fit.  But the above looks clearly intended
> to me.

Have you looked at RFC 3229?

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2147
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-21 15:50:32
Subject:New REST article
Message:

FYI,

http://www.oetrends.com/cgi-bin/page_display.cgi?82

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2148
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-21 15:57:08
Subject:RE: [rest-discuss] Security in a REST world?
Message:

Hmmm, coming from an "entitlement" application background, I'm wondering
whether standard
entitlement (authorization) proxy software already exists, or whether we
should beat feet and
get ours out there in HTTP proxy land.
 
Seth, when you say "can user U PUT data D?", by "data" do you mean the URI,
or do you mean
the content (which I understand you wish to filter).  If the former, then I
think you're missing the
full power of the servlet spec if you believe this can be done for GET but
not for PUT, DELETE,
etc.
 
Walden

-----Original Message-----
From: Mark Baker [mailto:distobj@...]
Sent: Wednesday, August 21, 2002 11:35 AM
To: Seth Ladd
Cc: rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] Security in a REST world?


I'd implement it as a proxy, and put all my rules there.  Authentication
would remain at the origin server, and the proxy would know that.

MB

On Wed, Aug 21, 2002 at 11:29:10AM -0400, Seth Ladd wrote:
> 
> > Your application still needs to *authorize* users after they've been
HTTP
> > authenticated.  And your application needs to apply whatever filters to
the
> > content to "authorize" that as well.
> 
> Exactly.  Authentication is easy, and nicely taken care of by the 
> servlet container.  It's the Authentication that becomes more difficult. 
>   What we're looking for is a framework that allows us to plug in rules 
> for authorization and ask the question "Can User U PUT Data D?" easily. 
>   I haven't seen much in controling PUT and DELETE.  I would love to do 
> it in the Apache level, much like I can control GET there.
> 
> Seth



-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca <http://www.markbaker.ca>
http://www.idokorro.com <http://www.idokorro.com> 


Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=228862.2128520.3581629.2204139/D=egroupweb/S=17057010
14:HM/A=1182694/R=0/*http://adfarm.mediaplex.com/ad/ck/990-1736-1039-336>


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 







-----------------------------------------------------------------------------------
Post ID:2149
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-21 16:06:05
Subject:RE: [rest-discuss] Re: PUT or POST Clarification
Message:

> Have you looked at RFC 3229?

Just did, THANKS!

Where do I send your librarian fee?

Walden






-----------------------------------------------------------------------------------
Post ID:2150
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-21 17:16:45
Subject:Re: [rest-discuss] Security in a REST world?
Message:

> Seth, when you say "can user U PUT data D?", by "data" do you mean the 
> URI, or do you mean
> the content (which I understand you wish to filter).  If the former, 
> then I think you're missing the
> full power of the servlet spec if you believe this can be done for GET 
> but not for PUT, DELETE,
> etc.

Good question.  I mean the content (the body of the HTTP message).  I 
have to do validation on the content for obvious reasons.  In my mind 
there is basic validation which I can easily mark up as rules (regexp, 
xpath statements, even xml schema).  That's the stuff I want to validate 
automatically.  Of course, there is some business validation which would 
be harder to do via declarative rules which I would still have to support.

Controlling the URI is easy.  Problem is, the URI doesn't have enough 
information in it to help me do all validation (by design).  So there is 
a second level of authorization control by looking at the actual content 
of the message.

That is what I was wondering if existed before.

A step closer is to do XML Schema validation on the content.  That's 
close, but not perfect.  For example:

Bob can PUT <stuff>A</stuff>
Alice can PUT <stuff>B</stuff>

Notice the contents of the stuff tag are different for each person.  If 
I need to support rules like that, I'd need two versions of the XML Schema.

To me, XPath statements are small enough to collect a large number of 
them for each user.  They can also be stored in the database.

Problem with that is our data is RDF/XML.  Since the RDF can be encoded 
in multiple valid ways, I can't write an XPath that can validate any RDF.

I'm currently toying with the idea of creating an XML Schema that can 
parse correctly as RDF.  That way, I still get benefits of RDF (once I 
tie into DAML+OIL schemas and do my inferencing) plus I can do XPath 
statements that I know will validate the document.

Also, I can store my validation rules in a database, and attach these 
rules as policies to URI patterns.

*phew*

Does this gel, or am I going at it completely wrong?

Thanks!
Seth





-----------------------------------------------------------------------------------
Post ID:2151
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-21 17:18:38
Subject:Re: [rest-discuss] Security in a REST world?
Message:

Mark Baker wrote:
> I'd implement it as a proxy, and put all my rules there.  Authentication
> would remain at the origin server, and the proxy would know that.

Yes.  In fact, we're doing it as a servlet filter (a convenient way to 
pre and post process HTTP requests).

Question is: is there a security framework for HTTP servers already 
(other than GET)?

Seth





-----------------------------------------------------------------------------------
Post ID:2152
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-21 17:40:46
Subject:RE: [rest-discuss] Security in a REST world?
Message:

> Bob can PUT <stuff>A</stuff>
> Alice can PUT <stuff>B</stuff>

I assume you mean to the same URI.  That's wierd, in my experience.
Usually,
the test is "what object can I access?", and "through what methods?".  Then,
the content, while a valid concern from a data integrity angle, is kind of
orthogonal to security issues per se.  Makes me wonder if your application
design
has identified the right resources, and whether reanalysis might clear up
your
"security" problem.

Well, they don't call me "Mr-Start-Over-From-Scratch" for nothing, but FWIW.

Walden






-----------------------------------------------------------------------------------
Post ID:2153
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-08-21 20:28:30
Subject:Re: [rest-discuss] New REST article
Message:

At 01:50 AM 22/08/2002, Mark Baker wrote:

>http://www.oetrends.com/cgi-bin/page_display.cgi?82

One factual error - in the resources and links section it says "OET found
one of the *best* interviews on "real world" of REST at the Tech Target
network ...".
If you read that interview it has a couple of gems in it such
as "If it's (REST) so simple, why hasn't it caught on like SOAP has? - It's
not as powerful. With REST, you're just grabbing content. " and "Let's say I
got the values from you, and I wanted to let you know that they're wrong. If
I wanted to send you back something that says they're wrong, with REST that
can't be done. With REST, you request information, you get it, and that's
where it ends."

Unfortunately, there is no facility to make comments on either of the articles.

Robert

PS Thinking on it, it may not be a factual error - if the real
world thinks that way about REST, it may actually be one of the *best*
interviews on "real world" of REST :-)







-----------------------------------------------------------------------------------
Post ID:2154
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-21 17:55:45
Subject:Re: [rest-discuss] Security in a REST world?
Message:

You might want to look at Netegrity - they have a bunch of security software that is HTTP aware. I doubt they can do /everything/ you are talking about, but they probably have URI based filtering & stuff.
I'm suprised Apache doesn't have rules that can operate against headers (like Content-Type, Content-Length, etc.)

  ----- Original Message ----- 
  From: Mathews, Walden 
  To: 'Mark Baker' ; Seth Ladd 
  Cc: rest-discuss@yahoogroups.com 
  Sent: Wednesday, August 21, 2002 8:57 AM
  Subject: RE: [rest-discuss] Security in a REST world?


  Hmmm, coming from an "entitlement" application background, I'm wondering whether standard
  entitlement (authorization) proxy software already exists, or whether we should beat feet and
  get ours out there in HTTP proxy land.

  Seth, when you say "can user U PUT data D?", by "data" do you mean the URI, or do you mean
  the content (which I understand you wish to filter).  If the former, then I think you're missing the
  full power of the servlet spec if you believe this can be done for GET but not for PUT, DELETE,
  etc.

  Walden
    -----Original Message-----
    From: Mark Baker [mailto:distobj@...]
    Sent: Wednesday, August 21, 2002 11:35 AM
    To: Seth Ladd
    Cc: rest-discuss@yahoogroups.com
    Subject: Re: [rest-discuss] Security in a REST world?


    I'd implement it as a proxy, and put all my rules there.  Authentication
    would remain at the origin server, and the proxy would know that.

    MB

    On Wed, Aug 21, 2002 at 11:29:10AM -0400, Seth Ladd wrote:
    > 
    > > Your application still needs to *authorize* users after they've been HTTP
    > > authenticated.  And your application needs to apply whatever filters to the
    > > content to "authorize" that as well.
    > 
    > Exactly.  Authentication is easy, and nicely taken care of by the 
    > servlet container.  It's the Authentication that becomes more difficult. 
    >   What we're looking for is a framework that allows us to plug in rules 
    > for authorization and ask the question "Can User U PUT Data D?" easily. 
    >   I haven't seen much in controling PUT and DELETE.  I would love to do 
    > it in the Apache level, much like I can control GET there.
    > 
    > Seth



    -- 
    Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
    Ottawa, Ontario, CANADA.               distobj@...
    http://www.markbaker.ca        http://www.idokorro.com


    To unsubscribe from this group, send an email to:
    rest-discuss-unsubscribe@yahoogroups.com



    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 






-----------------------------------------------------------------------------------
Post ID:2155
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-21 18:02:08
Subject:Re: [rest-discuss] Re: PUT or POST Clarification
Message:

Just making the implicit hyperlink into an explicit one...

RFC 3229
http://www.faqs.org/rfcs/rfc3229.html

Abstract

   This document describes how delta encoding can be supported as a
   compatible extension to HTTP/1.1.

   Many HTTP (Hypertext Transport Protocol) requests cause the retrieval
   of slightly modified instances of resources for which the client
   already has a cache entry.  Research has shown that such modifying
   updates are frequent, and that the modifications are typically much
   smaller than the actual entity.  In such cases, HTTP would make more
   efficient use of network bandwidth if it could transfer a minimal
   description of the changes, rather than the entire new instance of
   the resource.  This is called "delta encoding."

[...]

The goals do not include:
[...]
      -  Delta encoding of request messages, or of responses to methods
         other than GET.




----- Original Message -----
From: "Mathews, Walden" <waldenm@...>
To: "'Mark Baker'" <distobj@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Wednesday, August 21, 2002 9:06 AM
Subject: RE: [rest-discuss] Re: PUT or POST Clarification


> > Have you looked at RFC 3229?
>
> Just did, THANKS!
>
> Where do I send your librarian fee?
>
> Walden
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>






-----------------------------------------------------------------------------------
Post ID:2156
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-22 00:09:54
Subject:Re: [rest-discuss] Security in a REST world?
Message:

> I assume you mean to the same URI.  That's wierd, in my experience.
> Usually,
> the test is "what object can I access?", and "through what methods?".  Then,
> the content, while a valid concern from a data integrity angle, is kind of
> orthogonal to security issues per se.  Makes me wonder if your application
> design
> has identified the right resources, and whether reanalysis might clear up
> your
> "security" problem.

Excellent points!  And I've thought of them a lot, so they are totally 
valid concerns.

Our security has to control the object itself, PLUS the content of the 
object.  Take the example of PUTting an object from client to server. 
The object's URI has no information about what the object is.  So the 
server can not base security around the URI.  In our app, there is no 
difference between /blah/foo and /lee/laa.  Both are merely primary 
keys/URIs.  So to say that Seth can PUT /blah/foo/* isn't saying enough. 
  Because all the content is XML, I need to verify that what Seth is 
putting into /blah/foo/* makes sense.  The only real check I need to do 
for a PUT is if the URI has been created yet or not.

You're right in that this (what I've been talking about) is a data 
integrity concern.  We've been modeling it as "Does Seth have permission 
to say that?" with 'that' being the contents of the HTTP message.

The issue is very hard with PUT, since we can't write a policy for the 
object ID of the thing the client is PUTting since it doesn't exist yet. 
  We can only look at the incoming data to see if it is correct.

One way around this problem is to start using POST.  We can write a 
policy around POST and the object the client is POSTing to.  Since that 
object has to exist for the client to POST to it, we're able to control 
access to it.  POST would then become this "doIt" type of action/method, 
which we'd like to avoid.

In a SOAP world I don't have to worry too much about the contents of the 
message, since they have to be marshalled and unmarshalled by the SOAP 
engine anyway.  Any errors in content and formating will be picked up 
and result in a SOAP Fault of some sort.

In the REST world, I have to build that validation into every PUT.

With GET, it's a bit easier, since the object itself exists in the 
system.  I can place policies around existing objects easily to control 
access via GET.

It's fun to find these real world issues involved with building a pure 
HTTP/RDF+XML system.  I'm hoping that the solutions that come out of 
this project will be reusable in the ever so wished for "REST Toolkit".

thoughts?

thanks!
Seth







-----------------------------------------------------------------------------------
Post ID:2157
Sender:"usgqmsku" <usgqmsku@...>
Post Date/Time:2002-08-22 00:39:20
Subject:New Pics Here...
Message:

http://hjukalsk.tripod.com/index.html







-----------------------------------------------------------------------------------
Post ID:2158
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-22 01:11:31
Subject:Re: [rest-discuss] Re: PUT or POST Clarification
Message:

On Wed, Aug 21, 2002 at 11:02:08AM -0700, S. Mike Dierken wrote:
> The goals do not include:
> [...]
>       -  Delta encoding of request messages, or of responses to methods
>          other than GET.

Right.  But it also says;

 "Nothing in this specification specifically precludes the use of a delta encoding for the body of a PUT request. However, no mechanism currently exists for the client to discover if the server can interpret such messages, and so we do not attempt to specify how they might be used."

RFC 2774 should help with that problem.

There would still be some issues with PUT, such as ensuring that the
message remains stateless.  I think that specifying a target etag as
part request would help, but I haven't thought it through.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2159
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-22 01:20:42
Subject:Re: [rest-discuss] Re: PUT or POST Clarification
Message:

On Wed, Aug 21, 2002 at 09:11:31PM -0400, Mark Baker wrote:
> There would still be some issues with PUT, such as ensuring that the
> message remains stateless.  I think that specifying a target etag as
> part request would help, but I haven't thought it through.

Erm, with If-Match, of course.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2160
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-22 01:47:19
Subject:Re: [rest-discuss] PUT or POST Clarification
Message:

So here is the problem we are talking about:

We start by PUTting a resource on a server.  The server returns a URL to the
newly created resource.  Later, we realize that we need to change a part of
the resource, so we want to update only that part.  So why not just POST the
entire "resource" (the same that was PUT earlier, but now with the change)
to the given URL for the resource?  The server can then compare them and
determine if the change is allowed or not.

As an alternative, when the original resource is PUT on the server, the
server could return a series of URLs.  The first URL would be for the
resource itself.  The additional URLs would be for different representations
of the resource that effectively allow limited interaction with parts of the
resource.  For instance, you may get a response like this:

<purchaseOrder>
    <URL>http://sample.com/path/purchaseOrders/12345</URL>
    <editable>

<ShippingAddressURL>http://sample.com/path/purchaseOrders/12345/shipTo</Ship
pingAddressURL>

<ShippingMethodURL>http://sample.com/path/purchaseOrders/12345/shipVia</Ship
pingMethodURL>
    </editable>
</purchaseOrder>


Now, you could POST to any of the above URLs the parts that you want to
update.  If the requested update is in the shipping address only, then you
could use <ShippingAddressURL> and send only that part of the purchaseOrder.
This technique would allow each business to determine how much or how little
of the resource can be edited simply by returning only the URLs that allow
editing.  Of course, this technique is that it requires both parties to know
a common vocabulary, which may or may not be a good thing.  :)


Or has all of this been covered already?  :)

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2161
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-08-22 02:29:32
Subject:RE: [rest-discuss] New Pics Here...
Message:

Woohoo. REST spam.  I wonder if it's best to get the pictures using GET,
PUT, or POST? (:-)
  -----Original Message-----
  From: usgqmsku [mailto:usgqmsku@...]
  Sent: Wednesday, August 21, 2002 5:39 PM
  To: rest-discuss@yahoogroups.com
  Subject: [rest-discuss] New Pics Here...


  http://hjukalsk.tripod.com/index.html


        Yahoo! Groups Sponsor


  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.






-----------------------------------------------------------------------------------
Post ID:2162
Sender:Terrence Molson <inthedarkplace@...>
Post Date/Time:2002-08-22 02:58:47
Subject:Re: [rest-discuss] PUT or POST Clarification
Message:

Seairth,
I've found this to pretty much be a bad idea. Originally, in my app, I was going with a design that called for urls like:
/users/{UserID} ---> represents the user
/users/{UserID}/realname ---> the real name of the user
/users/{UserID}/email ---> the email addy of the user
 Your application simply needs to be smart enough to figure out what's going on. This allows users to only expose specific information as well as allowing users to update only specific parts of their profile. eg
PUT /users/{UserID}/email
<rwss:user><rwss:email>dwfefwfwefwe</rwss:email></rwss:user>
The problem with this is that I've found it essentially destroys HTTP caching controls. A client webservice can do a GET on /users/{userID}/email. Then another webservice can do a PUT /users/{userID} to change all information about the user including the email. Then when the first webservice does another GET on /users/{userID}/email they don't get the new email. 
This could just be due to my poor understanding of caching, but I think the issue simply goes to the heart of REST. Only objects which are truly resources, that is informationally significant, should be assigned URIs. Further, all messages should be coarse-grained and represent the complete state of the resource. Adam Bosworth has said a lot on coarse-grained messaging -- http://www.fawcette.com/xmlmag/2002_06/magazine/departments/endtag/
Anywyas, just my 2c
Seairth Jacobs wrote:So here is the problem we are talking about:

We start by PUTting a resource on a server.  The server returns a URL to the
newly created resource.  Later, we realize that we need to change a part of
the resource, so we want to update only that part.  So why not just POST the
entire "resource" (the same that was PUT earlier, but now with the change)
to the given URL for the resource?  The server can then compare them and
determine if the change is allowed or not.

As an alternative, when the original resource is PUT on the server, the
server could return a series of URLs.  The first URL would be for the
resource itself.  The additional URLs would be for different representations
of the resource that effectively allow limited interaction with parts of the
resource.  For instance, you may get a response like this:

<purchaseOrder>
    <URL>http://sample.com/path/purchaseOrders/12345</URL>
    <editable>

<ShippingAddressURL>http://sample.com/path/purchaseOrders/12345/shipTo</Ship
pingAddressURL>

<ShippingMethodURL>http://sample.com/path/purchaseOrders/12345/shipVia</Ship
pingMethodURL>
    </editable>
</purchaseOrder>


Now, you could POST to any of the above URLs the parts that you want to
update.  If the requested update is in the shipping address only, then you
could use <ShippingAddressURL> and send only that part of the purchaseOrder.
This technique would allow each business to determine how much or how little
of the resource can be edited simply by returning only the URLs that allow
editing.  Of course, this technique is that it requires both parties to know
a common vocabulary, which may or may not be a good thing.  :)


Or has all of this been covered already?  :)

---
Seairth Jacobs
seairth@...


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 



---------------------------------
Do You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New Jobs





-----------------------------------------------------------------------------------
Post ID:2163
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-22 03:03:13
Subject:Administrivia Re: [rest-discuss] New Pics Here...
Message:

Yah, it looks like the spammers have got the auto-subscribe bot working
for Yahoo Groups, because this "person" signed up last week (why the lag?).

If this becomes a problem, I'll have to moderate membership (*not* the
list, just who can join).  Bah.

BTW, we were at 200 members until I deleted the spammer.  8-) Very cool.

MB

On Wed, Aug 21, 2002 at 07:29:32PM -0700, Ramin Firoozye wrote:
> Woohoo. REST spam.  I wonder if it's best to get the pictures using GET,
> PUT, or POST? (:-)






-----------------------------------------------------------------------------------
Post ID:2164
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-22 03:27:48
Subject:Re: [rest-discuss] PUT or POST Clarification
Message:


> We start by PUTting a resource on a server.  The server returns a URL to
the
> newly created resource.
If you use PUT, then the URI you PUT to /is/ the created resource. It may be
possible that some response headers to PUT provide for a more 'canonical'
location, but I don't know much about that.
If you use POST, then the server would/could return the URI of any new
resource created.

> Later, we realize that we need to change a part of
> the resource, so we want to update only that part.  So why not just POST
the
> entire "resource" (the same that was PUT earlier, but now with the change)
> to the given URL for the resource?  The server can then compare them and
> determine if the change is allowed or not.
Sounds reasonable, but PUT means the same thing and is more specific.
For modifying portions of a resource, you could URI-ify those via sub-uris
or 'segment parameters'.

For example: "property32" could be the name of the shipping address of a PO
or something.
http://www.example.org/resources/resource27;property32/
or
http://www.example.org/resources/resource27/property32/


>
> As an alternative, when the original resource is PUT on the server, the
> server could return a series of URLs.  The first URL would be for the
> resource itself.  The additional URLs would be for different
representations
> of the resource that effectively allow limited interaction with parts of
the
> resource.  For instance, you may get a response like this:
>
> <purchaseOrder>
>     <URL>http://sample.com/path/purchaseOrders/12345</URL>
>     <editable>
>
>
<ShippingAddressURL>http://sample.com/path/purchaseOrders/12345/shipTo</Ship
> pingAddressURL>
>
>
<ShippingMethodURL>http://sample.com/path/purchaseOrders/12345/shipVia</Ship
> pingMethodURL>
>     </editable>
> </purchaseOrder>
Sure. I'd use POST, and relative URIs but the concept is sound. You might
even be able to 'annotate' existing PO schemas with href attributes and not
have to invent too much on your own.

>
>
> Now, you could POST to any of the above URLs the parts that you want to
> update.
PUT may make more sense. PUT = set, POST = add/extend/remove/etc.

> If the requested update is in the shipping address only, then you
> could use <ShippingAddressURL> and send only that part of the
purchaseOrder.
> This technique would allow each business to determine how much or how
little
> of the resource can be edited simply by returning only the URLs that allow
> editing.
Very nice. Or provide the URI - so people can 'get' - but have permissions
for the other operations.

> Of course, this technique is that it requires both parties to know
> a common vocabulary, which may or may not be a good thing.  :)
>
>
> Or has all of this been covered already?  :)

>
> ---
> Seairth Jacobs
> seairth@...
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>






-----------------------------------------------------------------------------------
Post ID:2165
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-22 03:35:27
Subject:Re: [rest-discuss] PUT or POST Clarification
Message:

----- Original Message -----
From: "Terrence Molson" <inthedarkplace@...>

> The problem with this is that I've found it essentially destroys HTTP
caching controls.
> A client webservice can do a GET on /users/{userID}/email.
> Then another webservice can do a PUT /users/{userID} to change all
> information about the user including the email.
> Then when the first webservice does another GET on /users/{userID}/email
they don't get the new email.

This is a very good point. I haven't found any good answers.

> This could just be due to my poor understanding of caching, but I think
the issue
> simply goes to the heart of REST. Only objects which are truly resources,
that is informationally significant,
> should be assigned URIs.
I'm not sure this is a good constraint or not. I think of it in terms of
'overlapping' resources. I don't know that it /can/ be avoided in any
practical system.

> Further, all messages should be coarse-grained and represent the complete
state of the resource.
All for that. I still don't rule out 'overlapping' resources though. I'd
like to hear some more discussion on this point.






-----------------------------------------------------------------------------------
Post ID:2166
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-22 03:46:26
Subject:Re: [rest-discuss] PUT or POST Clarification
Message:

This topic seems to be a real stickler for REST newbies, so I've written
up a rather long winded explanation of the role that each method plays
in the Big Picture - and outlined said Big Picture in the process, in
(hopefully) more approach language than with RestRDF.

http://www.markbaker.ca/2002/08/HowContainersWork/

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2167
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-22 03:53:00
Subject:Re: [rest-discuss] PUT or POST Clarification
Message:

On Wed, Aug 21, 2002 at 08:35:27PM -0700, S. Mike Dierken wrote:
> > The problem with this is that I've found it essentially destroys HTTP
> caching controls.
> > A client webservice can do a GET on /users/{userID}/email.
> > Then another webservice can do a PUT /users/{userID} to change all
> > information about the user including the email.
> > Then when the first webservice does another GET on /users/{userID}/email
> they don't get the new email.
> 
> This is a very good point. I haven't found any good answers.

It was the late Phil Karlton who said that there were two hard problems
in computer science; naming, and cache invalidation.  Sounds about
right. 8-)

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2168
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-22 04:27:57
Subject:Re: [rest-discuss] PUT or POST Clarification
Message:



>
> ----- Original Message -----
> From: "Terrence Molson" <inthedarkplace@...>
>
> > The problem with this is that I've found it essentially destroys HTTP
> caching controls.
> > A client webservice can do a GET on /users/{userID}/email.
> > Then another webservice can do a PUT /users/{userID} to change all
> > information about the user including the email.
> > Then when the first webservice does another GET on /users/{userID}/email
> they don't get the new email.
>
> This is a very good point. I haven't found any good answers.

It might be possible that if the intermediary does a HEAD/GET
If-modified-since or possibly using etag then it can detect changes -
assuming the origin server correctly knows the relationship between
/users/{userID}/email and /users/{userID}
This is more networking and probably not worth it unless the responses are
huge (many packets).

Another brute force approach would be to have the cache indicate interest in
/users/{userID}/email via a subscription and have the origin server echo
changes to /users/{userID}to listeners.








-----------------------------------------------------------------------------------
Post ID:2169
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-22 13:11:36
Subject:Re: [rest-discuss] PUT or POST Clarification
Message:

> If you use PUT, then the URI you PUT to /is/ the created resource. It may be
> possible that some response headers to PUT provide for a more 'canonical'
> location, but I don't know much about that.
> If you use POST, then the server would/could return the URI of any new
> resource created.

That is pretty much my understanding.  My problem I'm wrestling with 
when I use PUT is I can't set up a security policy for the PUT.  I don't 
know how to control access to a resource that doesn't exist yet.  It is 
because of that I am currently considering POST, since the resource must 
exist before hand, and therefor I can control access to it.

Any ideas?

Seth





-----------------------------------------------------------------------------------
Post ID:2170
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-22 13:39:29
Subject:RE: [rest-discuss] Re: PUT or POST Clarification
Message:

Just RESTifying the email, Dierken-style:
 
RFC 2774: http://www.ietf.org/rfc/rfc2774.txt?number=2774
<http://www.ietf.org/rfc/rfc2774.txt?number=2774> 
 
 

-----Original Message-----
From: Mark Baker [mailto:distobj@...]
Sent: Wednesday, August 21, 2002 9:12 PM
To: S. Mike Dierken
Cc: rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] Re: PUT or POST Clarification


On Wed, Aug 21, 2002 at 11:02:08AM -0700, S. Mike Dierken wrote:
> The goals do not include:
> [...]
>       -  Delta encoding of request messages, or of responses to methods
>          other than GET.

Right.  But it also says;

"Nothing in this specification specifically precludes the use of a delta
encoding for the body of a PUT request. However, no mechanism currently
exists for the client to discover if the server can interpret such messages,
and so we do not attempt to specify how they might be used."

RFC 2774 should help with that problem.

There would still be some issues with PUT, such as ensuring that the
message remains stateless.  I think that specifying a target etag as
part request would help, but I haven't thought it through.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca <http://www.markbaker.ca>
http://www.idokorro.com <http://www.idokorro.com> 


Yahoo! Groups Sponsor	
 
<http://rd.yahoo.com/M=229641.2166546.3626727.2204139/D=egroupweb/S=17057010
14:HM/A=1142328/R=0/*http://promo.yahoo.com/debtscape/>  	

To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 







-----------------------------------------------------------------------------------
Post ID:2171
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-22 13:53:47
Subject:Re: [rest-discuss] Security in a REST world?
Message:

Mathews, Walden wrote:
> Seth,
>  
> I'm left having to infer a lot from your description of your app because 
> you're not saying
> what the application domain is.  That's your call, but it might be 
> easier if you said.

Yeah, sorry about being vague with the application.  I felt it wasn't 
important to the security discussion, so I didn't want to create the noise.

> except that within your server application core there MUST be some 
> mapping from
> URI to object, even if it's just a hash, or the app has no chance of 
> working.  So your
> objection is that you can't push data validation out into the servlet 
> container...

That mapping you speak of is done by looking at the content.  The 
content of the PUT is RDF, and there is a Statement that tells me what 
type the RDF object is.  I can look at that to determine where to store 
this object.  The URI unfortunately doesn't tell me enough information 
to determine (and often infer) the type of the resource.

I'm not objecting to pushing data validation into the servlet container. 
  In fact, I think that's the only place I can do it.  I was wondering 
if there was an existing framework for the types of security checks I 
need to it.

Here is an example:

http://example.com/car - A car object that people can drive

In the NON-REST world, if I wanted to drive it, I would do:

car.drive(start, finish)

But we all know and love REST, so I would do this in the REST world:

car.create(new Trip(start, finish))

or even:

server.create( new Trip(car, start, finish) )

In other words, I have to create a noun (an object/resource) that 
describes the action that I want to take place.  So instead of driving 
the car via drive(), I have to create (or PUT) a Trip.

If I'm wrong about the above assumption, please let me know.  That might 
be the root of my problems. :)

Assuming I need to create a Trip, let's now talk about security.

Person A can drive the car from Point P1 to Point P2.
Person B can drive the car from Point P1 to Point P3.

So, Person A can:

server.create( new Trip(car, P1, P2) )

And that should pass.  If Person A tries to:

server.create( new Trip(car, P1, P3) )

That should fail.

So now I'm looking at data validation as a means to control access to 
the data.  REST is about information, not methods, so it makes sense I 
have to create a security framework that validates the data.

What do the RESTphiles think of the above example?

>  
> If you use POST to an 'object container' URI and let the server assign 
> URIs upon
> object creation, does that solve that part of the problem?  Note that 

That certainly does make it easier.  I'm currently leaning towards the 
container idea and appending objects to it.  Makes controlling access to 
a resource a lot easier.  Still have to do data validation, though, but 
that's cool.

Seth





-----------------------------------------------------------------------------------
Post ID:2172
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-22 13:55:25
Subject:RE: [rest-discuss] PUT or POST Clarification
Message:

Mark, HowContainersWork does a nice job of explaining how an application
should
use HTTP to *create* new resources.  I'd like it if you'd append a section
that details
the *updating* of resources, especially to make it clear that when you PUT,
you are
including the ENTIRE state of the addressed resource, and that if you wish
to update
a subset of that state, you need to either view that through some kind of
composite
model in which the subset has identity, or you need to negotiate a way for
the server
to distinguish the POST of a subordinate (subset) as "update" vs "create".
 
Thanks,
Walden

-----Original Message-----
From: Mark Baker [mailto:distobj@...]
Sent: Wednesday, August 21, 2002 11:46 PM
To: Seairth Jacobs
Cc: rest-discuss
Subject: Re: [rest-discuss] PUT or POST Clarification


This topic seems to be a real stickler for REST newbies, so I've written
up a rather long winded explanation of the role that each method plays
in the Big Picture - and outlined said Big Picture in the process, in
(hopefully) more approach language than with RestRDF.

http://www.markbaker.ca/2002/08/HowContainersWork/
<http://www.markbaker.ca/2002/08/HowContainersWork/> 

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca <http://www.markbaker.ca>
http://www.idokorro.com <http://www.idokorro.com> 

To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 







-----------------------------------------------------------------------------------
Post ID:2173
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-22 14:19:48
Subject:RE: [rest-discuss] Security in a REST world?
Message:

> Yeah, sorry about being vague with the application.  I felt it wasn't 
> important to the security discussion, so I didn't want to 
> create the noise.

Yes, but now we know it's not a security issue.

> That mapping you speak of is done by looking at the content.  The 
> content of the PUT is RDF, and there is a Statement that 
> tells me what 
> type the RDF object is.  I can look at that to determine 
> where to store 
> this object.  The URI unfortunately doesn't tell me enough 
> information 
> to determine (and often infer) the type of the resource.

I think you're carrying the opaqueness of URI too far.  As I understand,
URI should be opaque *to clients*, but are allowed to be (and should be
encouraged to be) meaningful for servers.  Else you're constrained to
"bag" storage at the conceptual level, and that looks like your problem
at this point.

> I'm not objecting to pushing data validation into the servlet 
> container. 
>   In fact, I think that's the only place I can do it.  

You read me wrong.  I said you objected to NOT being able to push
validation all the way out.  Not knowing your application, it's not for
me to say, except that pushing ALL validation out to the container
leaves you what for an application?


> Here is an example:
> 
> http://example.com/car - A car object that people can drive
> 
> In the NON-REST world, if I wanted to drive it, I would do:
> 
> car.drive(start, finish)

Curious as to what that means.  To begin with, the car ought to know
where it's starting from, i.e., where it is now, no?


> 
> But we all know and love REST, so I would do this in the REST world:

Note the order above: KNOW comes before LOVE :-)

> In other words, I have to create a noun (an object/resource) that 
> describes the action that I want to take place.  So instead 
> of driving 
> the car via drive(), I have to create (or PUT) a Trip.

In my most orthodox interpretation of Representational State Transfer,
I believe you can accomplish your trip by PUTting a version of your
car whose current location is the destination you seek.  But we don't
really know what the purpose of Car is, so again we're kind of stuck
giving advice.

> Assuming I need to create a Trip, let's now talk about security.
> 
> Person A can drive the car from Point P1 to Point P2.
> Person B can drive the car from Point P1 to Point P3.
> 
> So, Person A can:
> 
> server.create( new Trip(car, P1, P2) )
> 
> And that should pass.  If Person A tries to:
> 
> server.create( new Trip(car, P1, P3) )
> 
> That should fail.
> 
> So now I'm looking at data validation as a means to control access to 
> the data.  REST is about information, not methods, so it 
> makes sense I 
> have to create a security framework that validates the data.
> 
> What do the RESTphiles think of the above example?

The model seems broken because you can only drive the car from P1
to P-something if the car is at P1.  As I process it, P2 is a resource
accessible person A, while P3 is a resource not accessible to person A.
So if you modeled destinations as resources and make their URIs meaningful
to the server, then you can "push" some of that validation out, it seems.
But I have low confidence yet that I understand your application.

> 
> >  
> > If you use POST to an 'object container' URI and let the 
> server assign 
> > URIs upon
> > object creation, does that solve that part of the problem?  
> Note that 
> 
> That certainly does make it easier.  I'm currently leaning 
> towards the 
> container idea and appending objects to it.  Makes 
> controlling access to 
> a resource a lot easier.  Still have to do data validation, 
> though, but 
> that's cool.

Yes, validation is cool.

Walden






-----------------------------------------------------------------------------------
Post ID:2174
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-22 14:37:52
Subject:RE: [rest-discuss] Re: PUT or POST Clarification
Message:

I think "thinking it through" is a matter of making the 3229-introduced
headers
symmetric for requests and responses, which seems messy. Because of the
problem of determining "Delta-Base" for deltas, the "pull" model seems
cleaner
overall, and suggests a solution in which "current version" information is
all that
gets pushed.  Looks like event notification.
 
Walden

-----Original Message-----
From: Mark Baker [mailto:distobj@...]
Sent: Wednesday, August 21, 2002 9:21 PM
To: Mark Baker
Cc: S. Mike Dierken; rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] Re: PUT or POST Clarification


On Wed, Aug 21, 2002 at 09:11:31PM -0400, Mark Baker wrote:
> There would still be some issues with PUT, such as ensuring that the
> message remains stateless.  I think that specifying a target etag as
> part request would help, but I haven't thought it through.

Erm, with If-Match, of course.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca <http://www.markbaker.ca>
http://www.idokorro.com <http://www.idokorro.com> 

To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 







-----------------------------------------------------------------------------------
Post ID:2175
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-22 14:37:56
Subject:New, new REST article
Message:

http://www.sys-con.com/xml/article.cfm?id=454
-- 
 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2176
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-22 14:52:20
Subject:Re: [rest-discuss] Security in a REST world?
Message:

> I think you're carrying the opaqueness of URI too far.  As I understand,
> URI should be opaque *to clients*, but are allowed to be (and should be
> encouraged to be) meaningful for servers.  Else you're constrained to
> "bag" storage at the conceptual level, and that looks like your problem
> at this point.

Probably.  I agree that the URI has to be at least mildly understood by 
the container.

> You read me wrong.  I said you objected to NOT being able to push
> validation all the way out.  Not knowing your application, it's not for
> me to say, except that pushing ALL validation out to the container
> leaves you what for an application?

Well, the app still needs to do something intelligent.  That's the 
servlet itself (or the implementation).  The information would only get 
to the servlet if it passed all authorization and validation checks.

I used the car example below to simplify the example.  Our application 
deals with security and access control to resources (physical and 
virtual) so the question of "Can this person do this method to this 
thing" is essentially our application.

In trying to apply REST to it, we're changing "do this method" to 
"PUT/GET/DELETE/POST".  The car example below illustrates this.  Suppose 
I can only drive the car to the repair center, while my sister can drive 
to the movies.  I have to somehow ask the car, "Can I drive you to the 
movies" which it should then say no.

So, question is:

Am I sending the state of myself at the movies to the car?
Am I sending the state of the car at the movies to the car?

Would would I be PUTting and to what resource is where I'm getting all 
confused.  I keep thinking the car knows whether or not I'm allowed at 
the movies, so I need to ask the car.

Pretend all this talk of me, the car, and the movies each has a URI and 
are web enabled and very RESTful. :)


> Curious as to what that means.  To begin with, the car ought to know
> where it's starting from, i.e., where it is now, no?

Good point.  Let's remove starting from in this example.  Let's just use 
where I want to take it as an example (see movies example above).

> In my most orthodox interpretation of Representational State Transfer,
> I believe you can accomplish your trip by PUTting a version of your
> car whose current location is the destination you seek.  But we don't
> really know what the purpose of Car is, so again we're kind of stuck
> giving advice.

I think you understand really well!  I also think you're right... to get 
the car to the movies, I would PUT a version of the car at the movies, 
with me at the steering wheel.  In the HTTP request, via HTTP Auth, the 
server knows who is asking the question, so the Who and the What are all 
known.  This is cool.

Now comes the interesting part.  How do we secure this?  We need to say:

Seth can PUT this:

PUT /car HTTP/1.0

<car>
   <at rdf:resource="http://example.com/movies"/>
</car>

But can't PUT this:

PUT /car HTTP/1.0

<car>
   <at rdf:resource="http://example.com/liquorstore"/>
</car>

Basic web site security will govern if I can PUT to a resource or not, 
but doesn't talk about WHAT I'm PUTting.

That's where this discussion stems from.  I need to control certain 
states of resources, plus who is trying to put them into that state.  To 
do this, I need to look at the RDF/XML and ask "Are all Statements 
correct for this person?"

Phew! :)

Thanks for helping me sort all this out,
Seth





-----------------------------------------------------------------------------------
Post ID:2177
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-22 15:50:10
Subject:Re: [rest-discuss] Security in a REST world?
Message:

Mathews, Walden wrote:
> I think, in your example, the car is irrelevant.  Seth wants to put
> himself at the movies, and that's not allowed.  Movies is the resource,
> Seth is the principal, PUT is the method, and NO is the answer,
> presumably because Seth is in the wrong *role*, if we're talking servlet
> authorization.

That's an excellent point!

If we split this into two questions:

Can Seth Use Car?
Can Seth Go To Movies?

Then it's easier, because each resource (car, movies) controls their 
destiny.  How would the car know whether or not I can go to the movies?

> state), then the application has to decide, via its business rules, whether
> he can drive to the movies.

And I bet this is where distributed security models come in.  If the 
whole system is wired together and very smart, the car could then pass 
the PUT request all the way to the movie theatre.  If the movies said NO 
to Seth being there, the car could then say "Sorry, I'm not going to 
drive you there".

BTW your thoughts are excellent understand not only the security model 
but REST in general.

So now the question becomes:

Seth hasParent Mother
Mother grants Permission1
Permission1 allowsActor Seth
Permission1 allowsMethod Enter
Permission1 allowsActee Store

Now, who does Mother tell this Permission1 to?  We decided up above that 
the car doesn't know/care about that.  In a real world, would Store 
allow Mother to PUT Permission1 there?  Or would Store delegate those 
permission questions back to Mother?

We can take this offline or drop this any time you want.  It's getting 
fuzzy but I think the lessons learned are excellent ones.

Thanks,
Seth





-----------------------------------------------------------------------------------
Post ID:2178
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-22 15:48:17
Subject:PUT, POST, authorization and purchase orders
Message:

Another angle on the above subjects:

As Mark Baker wrote, an order is a contract.

In formal contract situations, neither the buyer nor the seller may 
change the contract unilaterally.  All changes to a bound contract 
must be accepted by both parties.

So what they do in EDI is create Change Orders, which are documents 
defining either a changed contract in total, or just the requested 
changes to an existing contract.  

One party requests changes by issuing a Change Order, and the other 
party either accepts or rejects them or they may go into negotiation.

So in this situation, I think a Change Order could be POSTed by one 
party to the original contract resource as a sub-resource, and if the 
other party accepts the changes, the contract resource would be 
changed, and also the Change Order and its acceptance would be 
retained as part of the audit trail of the contract.

Takes care of both authorization for changes as well as deltas.

I know, it seems like admitting an operation through the back door, 
but that's the way it's done when people want to be formal about it.

Possibly overkill for many situations, but I'd be interested if 
anybody thinks it's unRESTful.  (RESTless?)

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2179
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-22 16:19:43
Subject:Just when I thought I had it...
Message:

I thought I had finally figured out the POST vs. PUT thing, then this last
thread (PUT and POST clarification) comes along and everything gets fuzzy
again.  Here is what I understand (I think) so far:


GET
------
Retrieves a resource (actually, a representation of a resource).  Resource
must exist.  Action should/must be idempotent, meaning that the state of the
resource should not change.

PUT
------
Creates a resource.  The client dictates the URL for the new resource.
Newly created resource on the server should/must be identical to the
resource sent via PUT when retrieved through GET.  In other words, the
returned representation must match the original contents of the PUT.  If a
client wants to create a new resource, but does not have the authority to
dictate the resource's URL, then the client should use POST instead (see
below).  If the client wants to update a resource by replacing the entire
resource, PUT may be used. Ootherwise, use POST (again, see below).

POST
------
Edit/Update a resource.  Resource must exist.  However, this does not
necessarily mean that a subsequent GET will return a different
representation from a GET issued before the POST.  POSTs may update a
resource such that an existing URL will return a different representation
via GET, or POST may cause the creation of a new resource.  Likewise, it may
be possible for a POST to effect only interal changes such that subsequent
GETs return the same representation as before the POST.

In the case where POST causes the creation of a new resource, the server
will assign the new URL, not the client.  Unlike PUT, if the server returns
a URL for the new resource, there is no requirement for the new resource to
return an identical representation that that which was POSTed in the first
place.

While POST will most often be used to update a resource or create a new
resource, it is also possible to use POST as a "black box" method, where
data is being sent to the server, but the client has no knowledge of whether
anything was done with the data or not.  Now, I know this is /possible/.
However, with REST, is this /acceptable/?

When I compare the HTTP verbs to SQL actions (HTTP POST => SQL UPDATE), I
have trouble seeing the use of POST as a "black box" function.  In other
words, I have never encountered an example of using SQL UPDATE that did
anything other than update exactly the table I told it to update (though, as
a side effect, it may also update additional tables).  In this comparison,
it seems to me that either I have a gross missunderstanding of what POST is
used for, or else POST is much more general-purpose that SQL UPDATE.


DELETE
------
Deletes a resource.  Resource must(?) exist.





So, what do I have wrong?  Are there any scenarios for these verbs
(particularly PUT and POST) that I have not mentioned which are also
possible within the REST model?


---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2180
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-08-22 17:09:28
Subject:Re: [rest-discuss] Just when I thought I had it...
Message:

[This is not realy a response to Seairth - I already had most of this 
written when I saw Seairth's new thread, so instead of starting yet 
another thread, I'll just attach it to this one]

In following some of the threads on PUT vs POST, I've become somewhat 
less comfortable with my understanding of the RESTful use of those two 
methods.

All along, I've thought of the RESTful use of HTTP's GET/PUT/POST/DELETE 
as analogous to CRUD or SQL's SELECT/INSERT/UPDATE/DELETE - the mapping 
I had in my head was something like:

  HTTP    CRUD     SQL
  ----    ----     ---
  GET     READ     SELECT
  PUT     CREATE   INSERT
  POST    UPDATE   UPDATE
  DELETE  DELETE   DELETE

While reading Paul's new article [1], I suddenly realized what part of 
my problem was.  In his article, Paul makes that now standard comparison 
of HTTP's GET/PUT/POST/DELETE with SQL's SELECT/INSERT/UPDATE/DELETE. 
 At some level, this is probably a reasonable comparison to make. 
Unfortunately, I think a lot of people people take that high level 
analogy and then try to do a one-to-one mapping between the methods of 
the two schemes - something that for me ended up being very misleading.

As far as HTTP's GET and DELETE mapping to SQL's SELECT and DELETE - I 
don't see there being any problem.  However, trying to do a one-to-one 
mapping of PUT to INSERT or POST to UPDATE doesnt work so well.  PUT 
actually maps to either INSERT or UPDATE depending on whether the target 
resource already exists. POST maps to either INSERT or UPDATE depending 
on whether or not the resource you're POSTing to is a container (using 
Mark's model of HTTP resource state [2],[3]).

So, realizing my mistake, I now have a model of RESTful use of HTTP 
methods that's something like this:

GET - retrieve (a representation of) the resource's state
PUT - directly set the resource's state
POST - indirectly change the resource's state
DELETE - delete the resource

It seems to me, then, that the difference between PUT and POST is in 
part related to whether or not you are directly manipulating a 
resource's state.  With PUT, you are directly setting the resource's 
state by explicitly providing a representation of the resource's 
(entire) new state.  

With POST, you can only indirectly change the resource's state by 
providing a representation of something that the resource will then use 
in a manner of its choosing to change its own state.  In other words, 
you dont directly or explicitly specify the resource's new state - you 
just provide the resource with some information and it decides how to 
change its state based on that new information.

I think this is more or less just a restatement of what Mark has said in 
[2] and [3].  I'm just suggesting that maybe some of us have trouble 
understanding the difference between PUT and POST because we've made too 
literal an association between HTTP's methods and the methods of SQL or 
CRUD.  Yes, both HTTP and SQL can do CRUD.  But, unlike SQL, HTTP's 
methods do not have a one-to-one mapping to CRUD's create, read, update 
and delete.

--Chuck


[1] http://www.sys-con.com/xml/article.cfm?id=454
[2] http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model
[3] http://www.markbaker.ca/2002/08/HowContainersWork/









-----------------------------------------------------------------------------------
Post ID:2181
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-22 17:10:45
Subject:RE: [rest-discuss] Security in a REST world?
Message:

This is all a question of modeling.  If you can model your security
concerns in terms of principal, method and resource, then you can use
the existing security framework in servlet/HTTP.  If Seth becomes
a resource instead of a principal, you're screwed.  If what Seth wants
to do to the Store is something that needs more granularity than
{GET, PUT, POST, DELETE}, then you're screwed.  "Screwed" in the
sense that you have to write an application. :-)

That sounds like a bottom line to me.

Walden

> -----Original Message-----
> From: Seth Ladd [mailto:seth@...]
> Sent: Thursday, August 22, 2002 11:50 AM
> To: rest-discuss
> Subject: Re: [rest-discuss] Security in a REST world?
> 
> 
> Mathews, Walden wrote:
> > I think, in your example, the car is irrelevant.  Seth wants to put
> > himself at the movies, and that's not allowed.  Movies is 
> the resource,
> > Seth is the principal, PUT is the method, and NO is the answer,
> > presumably because Seth is in the wrong *role*, if we're 
> talking servlet
> > authorization.
> 
> That's an excellent point!
> 
> If we split this into two questions:
> 
> Can Seth Use Car?
> Can Seth Go To Movies?
> 
> Then it's easier, because each resource (car, movies) controls their 
> destiny.  How would the car know whether or not I can go to 
> the movies?
> 
> > state), then the application has to decide, via its 
> business rules, whether
> > he can drive to the movies.
> 
> And I bet this is where distributed security models come in.  If the 
> whole system is wired together and very smart, the car could 
> then pass 
> the PUT request all the way to the movie theatre.  If the 
> movies said NO 
> to Seth being there, the car could then say "Sorry, I'm not going to 
> drive you there".
> 
> BTW your thoughts are excellent understand not only the 
> security model 
> but REST in general.
> 
> So now the question becomes:
> 
> Seth hasParent Mother
> Mother grants Permission1
> Permission1 allowsActor Seth
> Permission1 allowsMethod Enter
> Permission1 allowsActee Store
> 
> Now, who does Mother tell this Permission1 to?  We decided up 
> above that 
> the car doesn't know/care about that.  In a real world, would Store 
> allow Mother to PUT Permission1 there?  Or would Store delegate those 
> permission questions back to Mother?
> 
> We can take this offline or drop this any time you want.  
> It's getting 
> fuzzy but I think the lessons learned are excellent ones.
> 
> Thanks,
> Seth
> 






-----------------------------------------------------------------------------------
Post ID:2182
Sender:Phil Eskelin <philip.eskelin@...>
Post Date/Time:2002-08-22 17:10:56
Subject:RE: [rest-discuss] Just when I thought I had it...
Message:

Seairth,

Whenever I have questions like yours, I always consult RFC 2616.  Here is an
excerpt from section 9.6[1] regarding the PUT/POSt contrast:

"The fundamental difference between the POST and PUT requests is reflected
in the different meaning of the Request-URI. The URI in a POST request
identifies the resource that will handle the enclosed entity. That resource
might be a data-accepting process, a gateway to some other protocol, or a
separate entity that accepts annotations. In contrast, the URI in a PUT
request identifies the entity enclosed with the request -- the user agent
knows what URI is intended and the server MUST NOT attempt to apply the
request to some other resource."

To paraphrase, POST identifies the resource that will handle your request,
and PUT identifies the resource itself.

-Philip

1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6

-----Original Message-----
From: Seairth Jacobs [mailto:seairth@...]
Sent: Thursday, August 22, 2002 12:20 PM
To: rest-discuss
Subject: [rest-discuss] Just when I thought I had it...


I thought I had finally figured out the POST vs. PUT thing, then this last
thread (PUT and POST clarification) comes along and everything gets fuzzy
again.  Here is what I understand (I think) so far:

[snip]

________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.






-----------------------------------------------------------------------------------
Post ID:2183
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-22 17:21:52
Subject:Re: [rest-discuss] Just when I thought I had it...
Message:

On Thu, Aug 22, 2002 at 01:09:28PM -0400, Chuck Hinson wrote:
> So, realizing my mistake, I now have a model of RESTful use of HTTP 
> methods that's something like this:
> 
> GET - retrieve (a representation of) the resource's state
> PUT - directly set the resource's state
> POST - indirectly change the resource's state
> DELETE - delete the resource
> 
> It seems to me, then, that the difference between PUT and POST is in 
> part related to whether or not you are directly manipulating a 
> resource's state.  With PUT, you are directly setting the resource's 
> state by explicitly providing a representation of the resource's 
> (entire) new state.  
> 
> With POST, you can only indirectly change the resource's state by 
> providing a representation of something that the resource will then use 
> in a manner of its choosing to change its own state.  In other words, 
> you dont directly or explicitly specify the resource's new state - you 
> just provide the resource with some information and it decides how to 
> change its state based on that new information.

Bingo, exactly.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2184
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-22 17:43:31
Subject:Re: [rest-discuss] Security in a REST world?
Message:

Mathews, Walden wrote:
> This is all a question of modeling.  If you can model your security
> concerns in terms of principal, method and resource, then you can use
> the existing security framework in servlet/HTTP.  If Seth becomes
> a resource instead of a principal, you're screwed.  If what Seth wants
> to do to the Store is something that needs more granularity than
> {GET, PUT, POST, DELETE}, then you're screwed.  "Screwed" in the
> sense that you have to write an application. :-)

Hehe true, true.  I actually like writing applications like this, so 
it's a good time.  :)

One last point about all of this that I would love your feedback on.

Let's take a simple example of opening a door (the door to the Store for 
instance).   To open a door, Seth would try to PUT the state of the door 
as OPEN.  The door would then say "Yup, seth can put me in an open state".

If the above it true, then the door has to do data validation based on 
rules and permissions.  For only certain people can change the state of 
the door to open.

So a security policy would look a little like:

Allow Seth to change Door1's isOpen property to true.
Deny Bob to change Door1's isOpen property to true.

I am controlling access to an object's properties and its values.

That way, when I say:

PUT /door1 HTTP/1.0
WWW-Authentication: seth

<door id="Door1">
   <isOpen>true</isOpen>
</door>

The authorization filter can easily check if this a valid state, not 
only for the door, but if Seth can put that door into that state.

SELECT count(*) FROM security_policy
WHERE actor = 'seth' AND              -- from WWW-Authentication
       object = 'Door1' AND            -- from id attr, or rdf:about attr
       object_prop = 'isOpen' AND
       prop_value = 'true'

All one has to do now is enumerate all properties of the object that is 
being PUT (easy to do if RDF) and compare all against a security_policy 
table which can be fast.

Are we there?  Does this make sense?

feelin good,
Seth





-----------------------------------------------------------------------------------
Post ID:2185
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-22 17:41:22
Subject:RE: [rest-discuss] PUT, POST, authorization and purchase orders
Message:

In my (orthodox for the hell of it) view, resources have no meaning to the
rest of the
world beyond the state they can expose through representations.  The gist
of orthodox REST is this: describe changes through representations of
end-state,
not through named operations.  Since you're limited to state-centric
interaction,
it follows that the word "subordinate" means precisely "subset of state", no
more
and no less.  In particular, an operation or processing instruction cannot
be
subordinate to a resource defined solely in terms of state, any more than an
apple can be subordinate to an orange.  But that's the rule we seem to love
to bend!
 
One side-effect of describing change only in representations of post-state
is
that the client *has to know* the rules for getting there.  Oh my, that
works fine when
you're building a document, but when you're trying to interact with the
Oracle
it doesn't work at all.  What would software be without the magical
transformations
that result from the application of behind-the-scenes business logic?
 
Am I making any sense at all?
 
Walden
 
 -----Original Message-----
From: bhaugen32 [mailto:bhaugen32@...]
Sent: Thursday, August 22, 2002 11:48 AM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] PUT, POST, authorization and purchase orders



Another angle on the above subjects:

As Mark Baker wrote, an order is a contract.

In formal contract situations, neither the buyer nor the seller may 
change the contract unilaterally.  All changes to a bound contract 
must be accepted by both parties.

So what they do in EDI is create Change Orders, which are documents 
defining either a changed contract in total, or just the requested 
changes to an existing contract.  

One party requests changes by issuing a Change Order, and the other 
party either accepts or rejects them or they may go into negotiation.

So in this situation, I think a Change Order could be POSTed by one 
party to the original contract resource as a sub-resource, and if the 
other party accepts the changes, the contract resource would be 
changed, and also the Change Order and its acceptance would be 
retained as part of the audit trail of the contract.

Takes care of both authorization for changes as well as deltas.

I know, it seems like admitting an operation through the back door, 
but that's the way it's done when people want to be formal about it.

Possibly overkill for many situations, but I'd be interested if 
anybody thinks it's unRESTful.  (RESTless?)

-Bob Haugen


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 







-----------------------------------------------------------------------------------
Post ID:2186
Sender:Phil Eskelin <philip.eskelin@...>
Post Date/Time:2002-08-22 18:01:01
Subject:RE: [rest-discuss] PUT, POST, authorization and purchase orders
Message:

Walden,
 
I think your description totally makes sense.  This is exactly how I think
of resources and their subordinates.  I see it in metaphysical terms.  If
you're more of a believer in the temporal philosophy of perdurance [than in
endurance], the identity of a resource is seen as a perduring collection of
its initial state (upon creation) and all subordinate states as parts that
make up the whole.  So in our case, resource can't be transferred themselves
because only representations of it, or its parts, can be transferred between
components.  In our lingo, you have an intial PUT and subsequent PUTs and/or
POSTs that give a resource its perduring "spatiotemporal" [sic] identity.
 
Thanks,
Philip

-----Original Message-----
From: Mathews, Walden [mailto:waldenm@...]
Sent: Thursday, August 22, 2002 1:41 PM
To: 'bhaugen32'; rest-discuss@yahoogroups.com
Subject: RE: [rest-discuss] PUT, POST, authorization and purchase orders



In my (orthodox for the hell of it) view, resources have no meaning to the
rest of the
world beyond the state they can expose through representations.  The gist
of orthodox REST is this: describe changes through representations of
end-state,
not through named operations.  Since you're limited to state-centric
interaction,
it follows that the word "subordinate" means precisely "subset of state", no
more
and no less.  In particular, an operation or processing instruction cannot
be
subordinate to a resource defined solely in terms of state, any more than an
apple can be subordinate to an orange.  But that's the rule we seem to love
to bend!
 
One side-effect of describing change only in representations of post-state
is
that the client *has to know* the rules for getting there.  Oh my, that
works fine when
you're building a document, but when you're trying to interact with the
Oracle
it doesn't work at all.  What would software be without the magical
transformations
that result from the application of behind-the-scenes business logic?
 
Am I making any sense at all?
 
Walden
 
 -----Original Message-----
From: bhaugen32 [mailto:bhaugen32@...]
Sent: Thursday, August 22, 2002 11:48 AM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] PUT, POST, authorization and purchase orders



Another angle on the above subjects:

As Mark Baker wrote, an order is a contract.

In formal contract situations, neither the buyer nor the seller may 
change the contract unilaterally.  All changes to a bound contract 
must be accepted by both parties.

So what they do in EDI is create Change Orders, which are documents 
defining either a changed contract in total, or just the requested 
changes to an existing contract.  

One party requests changes by issuing a Change Order, and the other 
party either accepts or rejects them or they may go into negotiation.

So in this situation, I think a Change Order could be POSTed by one 
party to the original contract resource as a sub-resource, and if the 
other party accepts the changes, the contract resource would be 
changed, and also the Change Order and its acceptance would be 
retained as part of the audit trail of the contract.

Takes care of both authorization for changes as well as deltas.

I know, it seems like admitting an operation through the back door, 
but that's the way it's done when people want to be formal about it.

Possibly overkill for many situations, but I'd be interested if 
anybody thinks it's unRESTful.  (RESTless?)

-Bob Haugen


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



Yahoo! Groups Sponsor	
 
<http://rd.yahoo.com/M=229641.2166546.3626727.2204139/D=egroupweb/S=17057010
14:HM/A=1142330/R=0/*http://promo.yahoo.com/debtscape/>  	

To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.





-----------------------------------------------------------------------------------
Post ID:2187
Sender:Chris Croome <chris@...>
Post Date/Time:2002-08-22 18:02:07
Subject:Re: [rest-discuss] Just when I thought I had it...
Message:

Hi

On Thu 22-Aug-2002 at 12:19:43 -0400, Seairth Jacobs wrote:
> 
> PUT
> ------
> Creates a resource.  The client dictates the URL for the new resource.
> Newly created resource on the server should/must be identical to the
> resource sent via PUT when retrieved through GET.  In other words, the
> returned representation must match the original contents of the PUT. 

What about using PUT to place a file that has some SSI that do things
like write the last modified date and include a navigation bar -- it
wouldn't be identical then?

Chris

-- 
Chris Croome                               <chris@...>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   
everything else                               http://chris.croome.net/  






-----------------------------------------------------------------------------------
Post ID:2188
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-22 18:17:30
Subject:RE: [rest-discuss] Security in a REST world?
Message:

I don't see any reason why you can't do what you've proposed below,
but at the same time, it's only for you to decide if you're "there",
and the reservation I have is leverage:

When they say "security policy", the mean policy, i.e., generalizations
about what makes things "secure".  You're going away from policy and
into a sort of interpreter-based implementation where instead of general
rules you have a zillion specific ones.  Do you have to?

If you can be more general about who can see or affect what, then
you can push more out to the servlet authorization mechanism.  This
is, arguably, one of the powers of "generic methods".  So, is Seth
allowed to open and close doors? (PUT/POST)  Is he allowed to sense
the state of a door? (GET).  Is he allowed to remodel the building?
(DELETE)

Thanks, this example has been fun and educational!

Walden

> -----Original Message-----
> From: Seth Ladd [mailto:seth@...]
> Sent: Thursday, August 22, 2002 1:44 PM
> Cc: rest-discuss
> Subject: Re: [rest-discuss] Security in a REST world?
> 
> 
> Mathews, Walden wrote:
> > This is all a question of modeling.  If you can model your security
> > concerns in terms of principal, method and resource, then 
> you can use
> > the existing security framework in servlet/HTTP.  If Seth becomes
> > a resource instead of a principal, you're screwed.  If what 
> Seth wants
> > to do to the Store is something that needs more granularity than
> > {GET, PUT, POST, DELETE}, then you're screwed.  "Screwed" in the
> > sense that you have to write an application. :-)
> 
> Hehe true, true.  I actually like writing applications like this, so 
> it's a good time.  :)
> 
> One last point about all of this that I would love your feedback on.
> 
> Let's take a simple example of opening a door (the door to 
> the Store for 
> instance).   To open a door, Seth would try to PUT the state 
> of the door 
> as OPEN.  The door would then say "Yup, seth can put me in an 
> open state".
> 
> If the above it true, then the door has to do data validation 
> based on 
> rules and permissions.  For only certain people can change 
> the state of 
> the door to open.
> 
> So a security policy would look a little like:
> 
> Allow Seth to change Door1's isOpen property to true.
> Deny Bob to change Door1's isOpen property to true.
> 
> I am controlling access to an object's properties and its values.
> 
> That way, when I say:
> 
> PUT /door1 HTTP/1.0
> WWW-Authentication: seth
> 
> <door id="Door1">
>    <isOpen>true</isOpen>
> </door>
> 
> The authorization filter can easily check if this a valid state, not 
> only for the door, but if Seth can put that door into that state.
> 
> SELECT count(*) FROM security_policy
> WHERE actor = 'seth' AND              -- from WWW-Authentication
>        object = 'Door1' AND            -- from id attr, or 
> rdf:about attr
>        object_prop = 'isOpen' AND
>        prop_value = 'true'
> 
> All one has to do now is enumerate all properties of the 
> object that is 
> being PUT (easy to do if RDF) and compare all against a 
> security_policy 
> table which can be fast.
> 
> Are we there?  Does this make sense?
> 
> feelin good,
> Seth
> 






-----------------------------------------------------------------------------------
Post ID:2189
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-22 18:31:29
Subject:Re: [rest-discuss] Just when I thought I had it...
Message:

I am beginning to think you use a POST in this case, except that it has to
be to an existing resource (since you cannot POST to a URL that does not
exist).  The server should then return a URL to the newly created resource.

---
Seairth Jacobs
seairth@...

----- Original Message -----
From: "Chris Croome" <chris@...>
To: <rest-discuss@yahoogroups.com>
Sent: Thursday, August 22, 2002 2:02 PM
Subject: Re: [rest-discuss] Just when I thought I had it...


> Hi
>
> On Thu 22-Aug-2002 at 12:19:43 -0400, Seairth Jacobs wrote:
> >
> > PUT
> > ------
> > Creates a resource.  The client dictates the URL for the new resource.
> > Newly created resource on the server should/must be identical to the
> > resource sent via PUT when retrieved through GET.  In other words, the
> > returned representation must match the original contents of the PUT.
>
> What about using PUT to place a file that has some SSI that do things
> like write the last modified date and include a navigation bar -- it
> wouldn't be identical then?
>
> Chris
>
> --
> Chris Croome                               <chris@...>
> web design                             http://www.webarchitects.co.uk/
> web content management                               http://mkdoc.com/
> everything else                               http://chris.croome.net/
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>







-----------------------------------------------------------------------------------
Post ID:2190
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-22 19:36:54
Subject:Re: PUT, POST, authorization and purchase orders
Message:

Walden, 

I'm not sure if you meant your reply as a comment on or correction to 
my message which you left attached.  If so, I don't understand.  

But I will comment on some of your statements on their own.

"Mathews, Walden" wrote:
> In my (orthodox for the hell of it) view, resources 
> have no meaning to the rest of the
> world beyond the state they can expose through representations.  

I thought that was what RDF was for.

> The gist of orthodox REST is this: 
> describe changes through representations of end-state,
> not through named operations.  

Agreed.

> Since you're limited to state-centric interaction,
> it follows that the word "subordinate" means precisely 
> "subset of state", no more and no less.  

Disagreed, depending on what you mean.  
See Mark's recent paper.
If the resource is a container, 
then to post a subordinate is to request
that the server create a new resource
linked to the container.
If the resource can act as a container
(as an order to its audit trail),
why wouldn't the same apply?

> One side-effect of describing change only in representations 
> of post-state is that the client *has to know* the rules 
> for getting there.  

Make the rules into a related resource.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2191
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-22 19:55:08
Subject:Re: [rest-discuss] Re: PUT, POST, authorization and purchase orders
Message:

On Thu, Aug 22, 2002 at 07:36:54PM -0000, bhaugen32 wrote:
> If the resource is a container, 
> then to post a subordinate is to request
> that the server create a new resource
> linked to the container.

Actually, it doesn't.  I should fix that in my note, as it isn't clear.
Creating a new resource might be a side effect, but need not be.  The
POSTed data could just be processed, effect some state change, and then
be discarded.  This would correspond to a non-201 HTTP response.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2192
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-22 21:10:36
Subject:Re: PUT, POST, authorization and purchase orders
Message:

Mark Baker wrote:
> On Thu, Aug 22, 2002 at 07:36:54PM -0000, bhaugen32 wrote:
> > If the resource is a container, 
> > then to post a subordinate is to request
> > that the server create a new resource
> > linked to the container.
> 
> Actually, it doesn't.  I should fix that in my note, as it isn't 
clear.
> Creating a new resource might be a side effect, but need not be.  
The
> POSTed data could just be processed, effect some state change, and 
then
> be discarded.  This would correspond to a non-201 HTTP response.

The context was "the resource is a container".

Ok, let me try again, because there is a lot of confusion on this 
point:
*If* the resource is a container, 
then it is *allowed* to post a subordinate
and request that the server create a new resource
linked to the container.

Or would you put it some other way?

The reason I'm belaboring the point is that people read into these 
statements all kinds of things, and it would be possible to read into 
your statement that my assertion was incorrect, and you cannot POST a 
subordinate resource to a container and have the server create a new 
resource for you.

And yes of course POST can have other effects as well.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2193
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-22 22:04:41
Subject:Re: [rest-discuss] Re: PUT, POST, authorization and purchase orders
Message:

On Thu, Aug 22, 2002 at 09:10:36PM -0000, bhaugen32 wrote:
> The context was "the resource is a container".

Right.  Not all containers create subordinate resources.

In my abstract model, and in RestRDF, I presented the following
hierarchy;

Resource
  -> Container
     -> StatePreservingContainer (ne IdentityPreservingContainer) (1)
     -> Processor (2)
     -> 
  -> Replaceable
  etc..

(1) is meant to describe containers who create a resource and return a
201

(2) is meant to describe containers who do not create a resource, but
instead just use the data to somehow do something, but do not hold
any state themselves.

I suppose it might be useful to add a class to the taxonomy that
represents non-state preserving, but state-holding resources, but I
didn't do that.  But anyhow, the point being that "Container" is
very high up in the hierarchy, and therefore covers a whole lot of
varied functionality, including process-and-forget.

> Ok, let me try again, because there is a lot of confusion on this 
> point:
> *If* the resource is a container, 
> then it is *allowed* to post a subordinate
> and request that the server create a new resource
> linked to the container.

Nope, at least not with this definition of container.  And FWIW, I think
it's pretty standard.  It would be equivalent to a tuple space, or an
OpenDoc container, or a Java Beans Context, etc..

> Or would you put it some other way?

As above.

> The reason I'm belaboring the point is that people read into these 
> statements all kinds of things, and it would be possible to read into 
> your statement that my assertion was incorrect, and you cannot POST a 
> subordinate resource to a container and have the server create a new 
> resource for you.

Hmm, ok.  I certainly don't mean that.  I just mean that if you only
know the thing is a container, it may or may not create a resource for
you.  If you know it's a StatePreservingContainer, then you know that
it will.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2194
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-22 23:00:33
Subject:Re: PUT, POST, authorization and purchase orders
Message:

My thoughts:

> In my abstract model, and in RestRDF, I presented the following
> hierarchy;
> 
> Resource
>   -> Container
>      -> StatePreservingContainer (ne IdentityPreservingContainer) 
(1)
>      -> Processor (2)
>      -> 
>   -> Replaceable
>   etc..
> 
> (1) is meant to describe containers who create a resource and 
return a
> 201
> 
> (2) is meant to describe containers who do not create a resource, 
but
> instead just use the data to somehow do something, but do not hold
> any state themselves.

Personally, I would strongly suggest avoiding the use of RDF to 
describe the structure of a restful webservice. RDF is not expressive 
enough as real XML, nor is it meant to hold 'concrete' data that 
should be used in a real XML document.

Further, there are really only two types of objects in REST. There 
are resources which expose the methods GET, PUT, DELETE, POST, 
(TRACE, and OPTIONS). Then there are 'collection' resources (a 
subclass of resource) which expose the aditional method 'FindById
(String id)'. 

This object model can be derived from examining the nature of URLs. 
URLs are hiearchical and it's understood that when one 'part' (let's 
call it 'resource-id') of a url appears behind another part of a URL 
then the former is said to be contained by the latter. This is the 
thinking behind /purchase-orders/3242342342 <-- this URL should be 
understood to mean there is a resource '3242343342' within the 
resource 'purchase-orders'. 

- inthedarkplace







-----------------------------------------------------------------------------------
Post ID:2195
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-22 23:16:12
Subject:No, URIs are opaque (was Re: PUT, POST, authorization and purchase orders)
Message:

From: "inthedarkplace" <inthedarkplace@...>
>
> This object model can be derived from examining the nature of URLs.
> URLs are hiearchical and it's understood that when one 'part' (let's
> call it 'resource-id') of a url appears behind another part of a URL
> then the former is said to be contained by the latter. This is the
> thinking behind /purchase-orders/3242342342 <-- this URL should be
> understood to mean there is a resource '3242343342' within the
> resource 'purchase-orders'.

As I understand it, this is absolutely wrong.  Absolutely nothing should be
assumed based on what is in the URI.  It is just as valid to have the
following two URLs where the first is a container of the second:

/purchase-orders
/3242342342

Only the server can apply meaning to the internal structure of a URI.  The
client cannot assume anything.  Period.  All it knows is that when it POSTed
data to "/purchase-orders", it got back "/3242342342".  You can then say
that the first is a container of the second, but only because the server
told that it was.

(boy, if I am wrong about this, I am chuckin' the entire REST stuff and go
join a monestary that's never heard of the stuff....)

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2196
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-22 23:36:11
Subject:Re: PUT, POST, authorization and purchase orders
Message:

Communication is so difficult....8(

Mark Baker wrote:
> On Thu, Aug 22, 2002 at 09:10:36PM -0000, bhaugen32 wrote:
> > The context was "the resource is a container".
> 
> Right.  Not all containers create subordinate resources.
> 
> In my abstract model, and in RestRDF, I presented the following
> hierarchy;
> 
> Resource
>   -> Container
>      -> StatePreservingContainer (ne IdentityPreservingContainer) 
(1)
> (1) is meant to describe containers who create a resource and 
return a 201

> > Ok, let me try again, because there is a lot of confusion on this 
> > point:
> > *If* the resource is a container, 
> > then it is *allowed* to post a subordinate
> > and request that the server create a new resource
> > linked to the container.
> 
> Nope, at least not with this definition of container.  
> And FWIW, I think it's pretty standard.  
> It would be equivalent to a tuple space, or an
> OpenDoc container, or a Java Beans Context, etc..
> 
> > Or would you put it some other way?
> 
> As above.

Nope?!! I thought I said the same thing.  
What's the difference?  Where am I wrong?
I don't get it at all.

> > The reason I'm belaboring the point is that people read into 
these 
> > statements all kinds of things, and it would be possible to read 
into 
> > your statement that my assertion was incorrect, and you cannot 
POST a 
> > subordinate resource to a container and have the server create a 
new 
> > resource for you.
> 
> Hmm, ok.  I certainly don't mean that.  I just mean that if you only
> know the thing is a container, it may or may not create a resource 
for
> you.  If you know it's a StatePreservingContainer, then you know 
that
> it will.

Ok, I'm gonna keep trying until I get this right.

*If* the resource is a StatePreservingContainer, 
and if I post the proper request to create a subordinate resource,
then the container will create a resource and return a 201.

By the way, I've tried to repeat the same thing you wrote in slightly 
different words three times now and been told I was wrong by both you 
and Walden Mathews and still don't know what I'm doing wrong. 
I know this is possible, and you seem to agree it's possible, but 
there is obviously some sublety that I am missing.

Also, the name StatePreservingContainer is not very clear, at least 
to me. Nor is IdentityPreservingContainer. But maybe that's because 
I'm still missing some subtlety.

I think this is an important capability for meeting business 
requirements.  I'm happy to revert to a hybrid of REST + SOAP, but am 
still trying to figure out how far I can go with pure REST.
And I do need to know how to describe it so that it meets the 
business requirements and will not get shot down by the REST gang.








-----------------------------------------------------------------------------------
Post ID:2197
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-08-23 01:52:26
Subject:Re: [rest-discuss] Re: PUT, POST, authorization and purchase orders
Message:

Bob,

First of all, I don't recall telling you you were wrong, and if I did, you should probably
attach no significant to that at all.  Right now I'm experimenting with holding up an impossibly
strict interpretation of REST to see what happens to my understanding, with apologies
to all innocent bystanders.

On this issue of data-accepting resource types, Mark has created the taxonomy in order
to help us understand the range of possible responses w.r.t. resource creation and so
forth, but there can be no such thing as "knowing a resource is this type or that", because
the resource is free to handle POST as it sees fit.  In other words, "IdentityPreservingResource"
may be what it's doing sometimes, but it's not a contract with you.  At least that's the
understanding I've come away with.

I thought the only (minor) slip in your description of the POST where a sub-resource is
created is that you say the client can *request* creation (or expect creation).  You can expect
whatever you want, but as I said there's no contract*.  And you're not really requesting that
a resource be created.  You're trusting the wizard (behind the resource curtain) to do the right
thing.

* I guess you could negotiate a contract like this, but what I meant is that it's not REST
or HTTP baseline stuff.

PS - thanks for trying to understand my esoteric ramblings, and yes, every bit does help.

Walden
  ----- Original Message ----- 
  From: bhaugen32 
  To: rest-discuss@yahoogroups.com 
  Sent: Thursday, August 22, 2002 7:36 PM
  Subject: [rest-discuss] Re: PUT, POST, authorization and purchase orders


  Communication is so difficult....8(

  Mark Baker wrote:
  > On Thu, Aug 22, 2002 at 09:10:36PM -0000, bhaugen32 wrote:
  > > The context was "the resource is a container".
  > 
  > Right.  Not all containers create subordinate resources.
  > 
  > In my abstract model, and in RestRDF, I presented the following
  > hierarchy;
  > 
  > Resource
  >   -> Container
  >      -> StatePreservingContainer (ne IdentityPreservingContainer) 
  (1)
  > (1) is meant to describe containers who create a resource and 
  return a 201

  > > Ok, let me try again, because there is a lot of confusion on this 
  > > point:
  > > *If* the resource is a container, 
  > > then it is *allowed* to post a subordinate
  > > and request that the server create a new resource
  > > linked to the container.
  > 
  > Nope, at least not with this definition of container.  
  > And FWIW, I think it's pretty standard.  
  > It would be equivalent to a tuple space, or an
  > OpenDoc container, or a Java Beans Context, etc..
  > 
  > > Or would you put it some other way?
  > 
  > As above.

  Nope?!! I thought I said the same thing.  
  What's the difference?  Where am I wrong?
  I don't get it at all.

  > > The reason I'm belaboring the point is that people read into 
  these 
  > > statements all kinds of things, and it would be possible to read 
  into 
  > > your statement that my assertion was incorrect, and you cannot 
  POST a 
  > > subordinate resource to a container and have the server create a 
  new 
  > > resource for you.
  > 
  > Hmm, ok.  I certainly don't mean that.  I just mean that if you only
  > know the thing is a container, it may or may not create a resource 
  for
  > you.  If you know it's a StatePreservingContainer, then you know 
  that
  > it will.

  Ok, I'm gonna keep trying until I get this right.

  *If* the resource is a StatePreservingContainer, 
  and if I post the proper request to create a subordinate resource,
  then the container will create a resource and return a 201.

  By the way, I've tried to repeat the same thing you wrote in slightly 
  different words three times now and been told I was wrong by both you 
  and Walden Mathews and still don't know what I'm doing wrong. 
  I know this is possible, and you seem to agree it's possible, but 
  there is obviously some sublety that I am missing.

  Also, the name StatePreservingContainer is not very clear, at least 
  to me. Nor is IdentityPreservingContainer. But maybe that's because 
  I'm still missing some subtlety.

  I think this is an important capability for meeting business 
  requirements.  I'm happy to revert to a hybrid of REST + SOAP, but am 
  still trying to figure out how far I can go with pure REST.
  And I do need to know how to describe it so that it meets the 
  business requirements and will not get shot down by the REST gang.



        Yahoo! Groups Sponsor 
              ADVERTISEMENT
             
       

  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 






-----------------------------------------------------------------------------------
Post ID:2198
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-23 02:39:29
Subject:Searching Containers
Message:

Guys,

I'm curious; has anybody established any best practices for 
performing arbitrary searching of collection resources? Eg, say I 
have the collection /users and I want to find a user with the 
username 'kd'. What's the most RESTful and elegant way to do this? 

It seems like there's basically three options.

1) Have the user POST an XML-document describing the query to the 
collection

Pros: Logically intuitive. If I have a collection, I should ask it to 
execute queries. 

Cons: Because searching is not a mutator-method (ie it doesn't change 
the state of the users collection) it doesn't seem like POST is the 
best method. But neither do GET, PUT, or DELETE make much sense 
unless  I do a GET with a body which I've been told is in poor taste. 
This also makes it very difficult to write the collection code 
because now the collection must parse the XML document, figure out 
which operation is happening (either user creation or searching) and 
then essentially reparse the algorithm.

2) Have the user do a GET on the users collection, passing the search 
query in through the query string. eg /users?username='xxx'

Pros: Intuitive. This is what for the query string is for, I think. 
It also allows the user to bookmark searches which might be 
potentially very useful for working with sets of users.

Cons: Severely limits the expressiveness of queries. Also puts more 
code in the users code, but this isn't a huge issue.

3) Create a special query resource located at /users/query. This 
query resource can have simply queries passed in through the query 
string or more complex queries passed in through a POST. 

Pros: This seems to the most elegant. It also makes sense because 
POSTing to a query resource can be seen as creating a query. 
Potentially, this query could even be assigned a URI. Because queries 
can be passed in through GET or POST it allows for arbitrarily 
expressive queries.

Cons: Potentially, this could lead to resource explosion because 
every container resource now needs an additional 'query' resource. 
This might not be such a good thing.

Right now I'm leaning more towards number 3. But I'm curious, what 
other solutions have people come up with?

- inthedarkplace







-----------------------------------------------------------------------------------
Post ID:2199
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-23 06:35:43
Subject:Re: [rest-discuss] Just when I thought I had it...
Message:

----- Original Message -----
From: "Chuck Hinson" <cmhinson@...>

> I had in my head was something like:
>
>   HTTP    CRUD     SQL
>   ----    ----     ---
>   GET     READ     SELECT
>   PUT     CREATE   INSERT
>   POST    UPDATE   UPDATE
>   DELETE  DELETE   DELETE
>

I would use PUT=UPDATE/INSERT and POST=INSERT. The meaning of HTTP PUT is
directly analagous to an 'upsert' in DB land.
The reason POST is an INSERT is that it is not idempotent - if you call
INSERT on your table 3 times, you get 3 records. If you call UPDATE on your
table 3 times you get one very fresh record.

I think there was a message quite a while ago on the comparison of CRUD &
SQL with HTTP methods - can't find it right now...







-----------------------------------------------------------------------------------
Post ID:2200
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-23 11:48:52
Subject:Re: PUT, POST, authorization and purchase orders
Message:

Walden Mathews wrote:
> First of all, I don't recall telling you you were wrong, and if I 
did, you should probably
> attach no significant to that at all.  Right now I'm experimenting 
with holding up an impossibly
> strict interpretation of REST to see what happens to my 
understanding, with apologies
> to all innocent bystanders.

Don't mind me, I'm just flailing about trying to get unconfused.
We're pretty much in the same boat, trying different ways to 
understand what seem to be powerful ideas that are a different from 
what (at least I'm) used to.

> On this issue of data-accepting resource types, Mark has created 
the taxonomy in order
> to help us understand the range of possible responses w.r.t. 
resource creation and so
> forth, but there can be no such thing as "knowing a resource is 
this type or that", 

I thought that's what RDF was for.
I also wonder if anybody has bent HTTP Header content-type in this 
direction?  (Can't get to Mark's articles right now to see if he 
mentioned this possibility. I think I remember somebody doing so in a 
previous message in this list, but can't find that, either.)

> because
> the resource is free to handle POST as it sees fit.  In other 
words, "IdentityPreservingResource"
> may be what it's doing sometimes, but it's not a contract with 
you.  At least that's the
> understanding I've come away with.

I want to be able to negotiate legally binding contracts 
electronically.  I am sure it is possible to do that.
It requires some kind of predictability of response.
It might be predictability of the same type as Mark describes on ws-
arch for getting reliable coordination without reliable messaging.

> I thought the only (minor) slip in your description of the POST 
where a sub-resource is
> created is that you say the client can *request* creation (or 
expect creation).  You can expect
> whatever you want, but as I said there's no contract*.  And you're 
not really requesting that
> a resource be created.  You're trusting the wizard (behind the 
resource curtain) to do the right
> thing.

I want a contract.  I don't need to start with a contract.
I expect some kind of predictability to emerge from conversation.
I think it will involve stereotyped conversational patterns.
I think they can be described via RDF or XML.

> * I guess you could negotiate a contract like this, but what I 
meant is that it's not REST
> or HTTP baseline stuff.

I expect it will require something like an RDF contract for 
conversational behavior, which could also be a REST resource.

> PS - thanks for trying to understand my esoteric ramblings, and 
yes, every bit does help.

I appreciate your ramblings because I sense that you are another 
person who is honestly trying to get it.  If we can help each other, 
I'm happy.  If we just confuse each other more, well, par for the 
course I guess, and we'll get over it.

-Bob







-----------------------------------------------------------------------------------
Post ID:2201
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-08-23 14:03:14
Subject:Re: [rest-discuss] Just when I thought I had it...
Message:


S. Mike Dierken wrote:

>----- Original Message -----
>From: "Chuck Hinson" <cmhinson@...>
>
>>I had in my head was something like:
>>
>>  HTTP    CRUD     SQL
>>  ----    ----     ---
>>  GET     READ     SELECT
>>  PUT     CREATE   INSERT
>>  POST    UPDATE   UPDATE
>>  DELETE  DELETE   DELETE
>>
>
>I would use PUT=UPDATE/INSERT and POST=INSERT. The meaning of HTTP PUT is
>directly analagous to an 'upsert' in DB land.
>The reason POST is an INSERT is that it is not idempotent - if you call
>INSERT on your table 3 times, you get 3 records. If you call UPDATE on your
>table 3 times you get one very fresh record.
>
But POST doesn't always mean insert (where insert mean create new 
resource).  A POST to a resource R can have one of three general results 
(ignoring errors):
    1. the creation of a new resource S
    2. a modification to R's state resulting in R'
    3. no change in R's state

--Chuck








-----------------------------------------------------------------------------------
Post ID:2202
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-23 14:24:42
Subject:session stuff (again)
Message:

Okay, a few threads back, I asked what was the preferred way to handle
sessions.  The most popular response was "http authentication".  Since I am
working on this project in PHP, I asked php.net's newsgroups where I might
find code for digest authentication (basic authentication is easy enough).
What I got back was that PHP currently does not support digest
authentication (though I would have thought I could code around that
problem).  And to make things worse, it seems not a lot of browsers support
digest authentication in a compatible manner.  For instance, I came across
one article that says:

    Opera and Amaya both support Apache's version of digest authentication
    IE5+ both support IIS's version of digest authentication
    Opera and Amays do not work with IIS and IE does not work with Apache

Now, this may have changed with IE6, but I have not been able to find
anything to substanciate that.

So, this leaves me with using basic authentication.  However, I am not crazy
about using it for two reasons:

1) Repeatedly sending login information over the wire in plaintext.  Now, I
realize that I could use SSL, but that would be both expensive and slow the
site down.

2) I don't see a way to "expire" the login information.  But maybe there is
a method that I am just not aware of...



So, this brings me to session cookies.  Some time back, I recall reading the
statement that "cookies are not RESTful".  Now, is this all use of cookies
or just persistant cookies?  Is it okay to use a single session cookie?  I
would see this as no different from using http authentication (i.e. the
client resending identifying [set of] values over and over again), except
that I can occasionally change the cookie's value to limit replay attacks
and limit the possibility of stealing the password to only one request
instead of every request (assuming basic authentication).


There is one other thing I do like about http authentication:  it doesn't
"interfere" with the application process.  In other words, the browser just
resubmits the last request with additional headers.  To implement html login
forms and cookies, I have to take on the responsibility of keeping track of
the submitted data in the last request.  It also means that the browser
caches the login page in it's history (which does not happen with http
authentication).


So, how do you deal with the security issues of http authentication vs. html
form/cookie authentication when you are running over a unsecure conneciton?
And how do you do this and keep it all RESTful?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2203
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-23 14:35:30
Subject:Re: [rest-discuss] Re: PUT, POST, authorization and purchase orders
Message:

I have to run, but ...

On Thu, Aug 22, 2002 at 09:52:26PM -0400, Walden Mathews wrote:
> In other words, "IdentityPreservingResource"
> may be what it's doing sometimes, but it's not a contract with you.  At least that's the
> understanding I've come away with.

My intent was that exposing a type be equivalent to publishing an intent
to enter into a contract.  So you could imagine a hierarchy such as;

Container
  StatePreservingContainer
    Archiver
      EternityArchiver

and if you expose that type, and I give you my data (with POST), I
expect that you will keep it for eternity ... as described by the RDF
you get when you GET the type URI (plus info that relates it to its
parent, so that if you're only looking for an Archiver and don't care
what kind, you can use EternityArchivers.

> * I guess you could negotiate a contract like this, but what I meant is that it's not REST
> or HTTP baseline stuff.

Sure, it's not baseline.  But it seems like the only way forward for
laying out a coherrent framework for fitting RDF into REST.  At least
that's how I see it.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2204
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-08-23 14:47:26
Subject:is Tomcat RESTful?
Message:

Don't know why I didn't think of this before. 

Tomcat uses a URL based API for managing web applications. It's
documented here:
<http://jakarta.apache.org/tomcat/tomcat-4.0-doc/manager-howto.html>. 

You send it URLs, it returns text/plain responses (essentially, 'ok' and
'fail'). Also it's maybe a live example of a resource with nested
resources (the Tomcat model is an uber application which manages nested
applications, which manage nested servlets/jsps/images... you get the
idea). 

The thing is, it uses GET to alter|deploy|start|stop applications in its
container; ie it has GETs with side effects. Which doesn't seem very
RESTful.

Thoughts?

regards,
Bill de hra







-----------------------------------------------------------------------------------
Post ID:2205
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-23 15:05:26
Subject:RE: [rest-discuss] Re: PUT, POST, authorization and purchase orde rs
Message:

Bob,
 
There are contracts, and there are contracts.  I recognize that you are
interested
in a business-level contract, i.e., "contract as REST resource".  When I
said there was
no contract, I meant at the application protocol level inside POST.  In
other words, you
might compose hypertext entity C and POST it to some business resource as a
contract
work in progress, and that resource may
 
    a. declare itself on vacation and do nothing with your submittal except
to
        notify you that no action is being taken
 
    b. take your contract proposal and publish it as a resource to be
modified
        collaboratively until both sides are ready to sign it.
 
The contract I assert does not exist is the contract to recognize another
contract
and host it.  And in business, this is also the case, is it not?
 
By the way, I think the problem here is one of HTTP, not REST.  REST says
there
are generic methods, i.e, methods that conceivably apply to all resources.
HTTP says
there is a POST method, and then makes some statements for us to interpret.
 
    If REST, by calling for generic methods, implies in the meaning of
'generic'
    that method semantics are clearly defined and understood, then the POST
    method of HTTP may violate REST a little.  The generality of POST is so
great
    that the semantic visibility of POST requests to intermediaries is
highly
    questionable, and hence the desired "induced" architectural property is
partly
    missing.  Another way of saying this is that POST is a built-in tunnel
    for doing RPC over HTTP.  The exception being that you really shouldn't
    use it for data retrieval (GET).
 
If you want explicit, reliable sub-resource creation through the protocol,
you can
define a method with those semantics, and that would violate neither REST
nor
HTTP as far as I know.  Heck, what's to stop you from extending HTTP methods
with the set from SQL?  Then you know precisely what INSERT means.
 
What do you think?
 
Walden
 
 
 -----Original Message-----
From: bhaugen32 [mailto:bhaugen32@...]
Sent: Friday, August 23, 2002 7:49 AM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] Re: PUT, POST, authorization and purchase orders



Walden Mathews wrote:
> First of all, I don't recall telling you you were wrong, and if I 
did, you should probably
> attach no significant to that at all.  Right now I'm experimenting 
with holding up an impossibly
> strict interpretation of REST to see what happens to my 
understanding, with apologies
> to all innocent bystanders.

Don't mind me, I'm just flailing about trying to get unconfused.
We're pretty much in the same boat, trying different ways to 
understand what seem to be powerful ideas that are a different from 
what (at least I'm) used to.

> On this issue of data-accepting resource types, Mark has created 
the taxonomy in order
> to help us understand the range of possible responses w.r.t. 
resource creation and so
> forth, but there can be no such thing as "knowing a resource is 
this type or that", 

I thought that's what RDF was for.
I also wonder if anybody has bent HTTP Header content-type in this 
direction?  (Can't get to Mark's articles right now to see if he 
mentioned this possibility. I think I remember somebody doing so in a 
previous message in this list, but can't find that, either.)

> because
> the resource is free to handle POST as it sees fit.  In other 
words, "IdentityPreservingResource"
> may be what it's doing sometimes, but it's not a contract with 
you.  At least that's the
> understanding I've come away with.

I want to be able to negotiate legally binding contracts 
electronically.  I am sure it is possible to do that.
It requires some kind of predictability of response.
It might be predictability of the same type as Mark describes on ws-
arch for getting reliable coordination without reliable messaging.

> I thought the only (minor) slip in your description of the POST 
where a sub-resource is
> created is that you say the client can *request* creation (or 
expect creation).  You can expect
> whatever you want, but as I said there's no contract*.  And you're 
not really requesting that
> a resource be created.  You're trusting the wizard (behind the 
resource curtain) to do the right
> thing.

I want a contract.  I don't need to start with a contract.
I expect some kind of predictability to emerge from conversation.
I think it will involve stereotyped conversational patterns.
I think they can be described via RDF or XML.

> * I guess you could negotiate a contract like this, but what I 
meant is that it's not REST
> or HTTP baseline stuff.

I expect it will require something like an RDF contract for 
conversational behavior, which could also be a REST resource.

> PS - thanks for trying to understand my esoteric ramblings, and 
yes, every bit does help.

I appreciate your ramblings because I sense that you are another 
person who is honestly trying to get it.  If we can help each other, 
I'm happy.  If we just confuse each other more, well, par for the 
course I guess, and we'll get over it.

-Bob



Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=232673.2253070.3709326.1774049/D=egroupweb/S=17057010
14:HM/A=1194123/R=0/*http://www.adinsdirect.com/> 	

To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 







-----------------------------------------------------------------------------------
Post ID:2206
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-08-23 15:22:57
Subject:RE: [rest-discuss] is Tomcat RESTful?
Message:

-----Original Message-----
From: Mathews, Walden [mailto:waldenm@...] 

I hope it at least sets responses to non-cacheable! 
>>

It doesn't. I'm using the back button now and hitting refresh to
redeploy an application. You do have to login at the get go.

regards,
Bill de hra







-----------------------------------------------------------------------------------
Post ID:2207
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-08-23 15:29:29
Subject:RE: [rest-discuss] is Tomcat RESTful?
Message:


> From: Mathews, Walden [mailto:waldenm@...] 
>
> So then what happens the second time you access a resource like
> 
> 	GET /manager/refresh?my_app ?
> 
> Does the browser satisfy the request from its cache, meaning 
> that the "refresh" command never reaches the server?


Yes I think so (I don't know how to view traffic on this box); you go
back and actively refresh to resubmit. On the hand, I'd need to look at
the manager servlet to see what it's really doing up there...

regards
Bill de hra







-----------------------------------------------------------------------------------
Post ID:2208
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-23 15:32:19
Subject:RE: [rest-discuss] Re: PUT, POST, authorization and purchase orde rs
Message:

The root of all evil here is the fact that *operations* are also first class
abstractions,
every bit as first class as *resource state*, except in REST (and for well
understood
reasons there).
 
So how do you evaluate the tradeoff between using RDF as part of resource
state
to extend the semantics of 'generic' methods?  As opposed to extending the
defined set of
methods for the sake of greater method specificity?  As opposed to adding
'control' data
(mentioned in the thesis, but not in association with HTTP) to qualify
methods?  As
opposed to any other meta-method for working around generic method
limitations?
 
Walden

-----Original Message-----
From: Mark Baker [mailto:distobj@...]
Sent: Friday, August 23, 2002 10:36 AM
To: Walden Mathews
Cc: bhaugen32; rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] Re: PUT, POST, authorization and purchase orders


I have to run, but ...

On Thu, Aug 22, 2002 at 09:52:26PM -0400, Walden Mathews wrote:
> In other words, "IdentityPreservingResource"
> may be what it's doing sometimes, but it's not a contract with you.  At
least that's the
> understanding I've come away with.

My intent was that exposing a type be equivalent to publishing an intent
to enter into a contract.  So you could imagine a hierarchy such as;

Container
  StatePreservingContainer
    Archiver
      EternityArchiver

and if you expose that type, and I give you my data (with POST), I
expect that you will keep it for eternity ... as described by the RDF
you get when you GET the type URI (plus info that relates it to its
parent, so that if you're only looking for an Archiver and don't care
what kind, you can use EternityArchivers.

> * I guess you could negotiate a contract like this, but what I meant is
that it's not REST
> or HTTP baseline stuff.

Sure, it's not baseline.  But it seems like the only way forward for
laying out a coherrent framework for fitting RDF into REST.  At least
that's how I see it.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca <http://www.markbaker.ca>
http://www.idokorro.com <http://www.idokorro.com> 


Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=228862.2128520.3581629.2204139/D=egroupweb/S=17057010
14:HM/A=1182711/R=0/*http://adfarm.mediaplex.com/ad/ck/990-1736-1039-336>


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 







-----------------------------------------------------------------------------------
Post ID:2209
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-23 15:50:27
Subject:Re: PUT, POST, authorization and purchase orde rs
Message:

"Mathews, Walden" wrote:
> There are contracts, and there are contracts.  
> I recognize that you are interested
> in a business-level contract, i.e., "contract as REST resource".  > 
> When I said there was no contract, 
> I meant at the application protocol level inside POST.  

Yeah, I understood.  
I am interested in contracts in both senses,
business and protocol, and they are related.
Can't have real legally binding electronic
business contracts without protocol contracts.
I know it's not base HTTP POST, but I thought
that was the direction Mark was going with RDF.

Now, I'm not gonna make the mistake of saying
any more about what I think Mark means, since
I'm still not sure what I did wrong the last
time.  

But what I mean is that I think it is possible
to define a business protocol contract with
either RDF or XML or something else computable
and have it govern conversations about 
business contracts as resources.

Working on a variety of ways to do it.
More to come when I think I got something real.

> In other words, you might compose hypertext entity C 
> and POST it to some business resource as a contract
> work in progress, and that resource may
>  
>     a. declare itself on vacation and do nothing 
>        with your submittal except to
>        notify you that no action is being taken

...except that I'm gonna put a time constraint on
my contract proposal.  If no action when due,
the proposal is void.

>     b. take your contract proposal and publish it 
>        as a resource to be modified collaboratively 
>        until both sides are ready to sign it.
>  
> The contract I assert does not exist is the contract 
> to recognize another  contract and host it.  

We've discussed two models:
1. one resource, which one party hosts, and
2. two resources, which must be kept in sync.

(In real life, there will always be two copies,
but in the first model, only one has a URI.)

> And in business, this is also the case, is it not?

The contract for negotiating contracts 
must be negotiated first.  
Fortunately, such things are being developed
by standards orgs.
Unfortunately, none are RESTful (so far).

But after having worked on some of the non-RESTful
approaches, I think the REST principle that 
everything important be a resource with its own URI 
would solve a lot of currently unsolved problems.
(That's why I'm here, by the way.)

Can REST can solve all the conversational
protocol problems? Don't know for sure.
I think so.  Can't prove it yet.

P.S. In case it wasn't clear, when I wrote that 
it is possible to have POST create sub-resource, 
* I didn't mean that POST cannot also be used
in other ways, and
* I meant that a "sub-resource"  or "subordinate resource" 
is a real resource with its own URI, just hyperlinked 
to its container.










-----------------------------------------------------------------------------------
Post ID:2210
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-23 16:04:37
Subject:RE: [rest-discuss] Re: PUT, POST, authorization and purchase orde rs
Message:

[ Bob Haugen wrote:] 
 > Can't have real legally binding electronic
 > business contracts without protocol contracts.
 > I know it's not base HTTP POST, but I thought
 > that was the direction Mark was going with RDF. 
 
And you can't have protocol contracts without lower level protocol
contracts, and so on and so on?  I don't believe this is true.  There is
such a thing as bootstrapping commitment, and I believe it's the norm
rather than the exception.  
 
Every time you communicate with someone, there's the possibility
that they will not even understand you, let alone enter into a contract
with you, but when the latter happens mutually, you can recognize
it an build upon it.
 
So just because HTTP or REST doesn't guarantee the creation semantics
you want from POST does not mean you can't still negotiate through
that method to the desired contract state.
 
I see a parallel between this subject and the subject of 'reliable
messaging'
as the substrate for reliable applications.  Do you see my analogy
clearly, or should I elaborate?
 
Walden 





-----------------------------------------------------------------------------------
Post ID:2211
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-23 16:25:12
Subject:Re: PUT, POST, authorization and purchase orde rs
Message:

"Mathews, Walden" wrote:
> There is such a thing as bootstrapping commitment, 
> and I believe it's the norm rather than the exception.  

I'm not communicating well.
That's exactly what I have in mind,
except that I think some seeds will be useful
(beyond raw POST).

> Every time you communicate with someone, there's the possibility
> that they will not even understand you, let alone enter into a 
contract
> with you, but when the latter happens mutually, you can recognize
> it an build upon it.
>  
> So just because HTTP or REST doesn't guarantee the creation 
semantics
> you want from POST does not mean you can't still negotiate through
> that method to the desired contract state.

Sure, no disagreement.
But business relationships tend to be repetitive.
Once I negotiate a protocol with you, 
we can start with the previous protocol
either as something to use or something
to tweak, instead of pretending we never met.

And if somebody else has defined a conversational 
pattern that we can reference, that might help, too.

And whether we capture our previously negotiated
pattern or use somebody else's, it needs to be
represented in some form.  

You can see how difficult communication between
humans can be, when we were evolved to be good
at it.  I think our computers will need all 
the help they can get.

> I see a parallel between this subject and the subject of 'reliable
> messaging'
> as the substrate for reliable applications.  Do you see my analogy
> clearly, or should I elaborate?

Yes I think there is a parallel,
but please do elaborate, because
assumptions aren't working very well
in this arena.







-----------------------------------------------------------------------------------
Post ID:2212
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-23 16:49:19
Subject:Re: session stuff (again)
Message:

Seairth,

Personally, I've never heard of different versions of digest 
authentication between the browsers. Plus I don't really see how PHP 
can not support digest authentication. Digest authentication just 
involves parsing the 'Authorization' header and generating the 'WWW-
Authenticate' header. 

I'd suggest you look at: 
http://www.rassoc.com/gregr/weblog/stories/2002/07/09/webServicesSecur
ityHttpDigestAuthenticationWithoutActiveDirectory.html

That is a 'native' implementation of digest authentication. It 
doesn't matter on the browser or container.

- inthedarkplace

--- In rest-discuss@y..., "Seairth Jacobs" <seairth@s...> wrote:
> Okay, a few threads back, I asked what was the preferred way to 
handle
> sessions.  The most popular response was "http authentication".  
Since I am
> working on this project in PHP, I asked php.net's newsgroups where 
I might
> find code for digest authentication (basic authentication is easy 
enough).
> What I got back was that PHP currently does not support digest
> authentication (though I would have thought I could code around that
> problem).  And to make things worse, it seems not a lot of browsers 
support
> digest authentication in a compatible manner.  For instance, I came 
across
> one article that says:
> 
>     Opera and Amaya both support Apache's version of digest 
authentication
>     IE5+ both support IIS's version of digest authentication
>     Opera and Amays do not work with IIS and IE does not work with 
Apache
> 
> Now, this may have changed with IE6, but I have not been able to 
find
> anything to substanciate that.
> 
> So, this leaves me with using basic authentication.  However, I am 
not crazy
> about using it for two reasons:
> 
> 1) Repeatedly sending login information over the wire in 
plaintext.  Now, I
> realize that I could use SSL, but that would be both expensive and 
slow the
> site down.
> 
> 2) I don't see a way to "expire" the login information.  But maybe 
there is
> a method that I am just not aware of...
> 
> 
> 
> So, this brings me to session cookies.  Some time back, I recall 
reading the
> statement that "cookies are not RESTful".  Now, is this all use of 
cookies
> or just persistant cookies?  Is it okay to use a single session 
cookie?  I
> would see this as no different from using http authentication (i.e. 
the
> client resending identifying [set of] values over and over again), 
except
> that I can occasionally change the cookie's value to limit replay 
attacks
> and limit the possibility of stealing the password to only one 
request
> instead of every request (assuming basic authentication).
> 
> 
> There is one other thing I do like about http authentication:  it 
doesn't
> "interfere" with the application process.  In other words, the 
browser just
> resubmits the last request with additional headers.  To implement 
html login
> forms and cookies, I have to take on the responsibility of keeping 
track of
> the submitted data in the last request.  It also means that the 
browser
> caches the login page in it's history (which does not happen with 
http
> authentication).
> 
> 
> So, how do you deal with the security issues of http authentication 
vs. html
> form/cookie authentication when you are running over a unsecure 
conneciton?
> And how do you do this and keep it all RESTful?
> 
> ---
> Seairth Jacobs
> seairth@s...







-----------------------------------------------------------------------------------
Post ID:2213
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-23 17:41:57
Subject:Re: Just when I thought I had it...
Message:

> 
> PUT should never insert, it really only means UPDATE. 
Sorry, but that is not the way the HTTP specification works.
It RDBMS/SQL terms it means "UPSERT".

-- http://www.ietf.org/rfc/rfc2616.txt --
9.6 PUT

   The PUT method requests that the enclosed entity be stored under the
   supplied Request-URI. If the Request-URI refers to an already
   existing resource, the enclosed entity SHOULD be considered as a
   modified version of the one residing on the origin server. If the
   Request-URI does not point to an existing resource, and that URI is
   capable of being defined as a new resource by the requesting user
   agent, the origin server can create the resource with that URI. If a
   new resource is created, the origin server MUST inform the user agent
   via the 201 (Created) response. If an existing resource is modified,
   either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
   to indicate successful completion of the request. If the resource
   could not be created or modified with the Request-URI, an appropriate
   error response SHOULD be given that reflects the nature of the
   problem. 







-----------------------------------------------------------------------------------
Post ID:2214
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-23 18:22:00
Subject:Re: [rest-discuss] Re: session stuff (again)
Message:

First, thanks for the link.  That certainly makes it more clear how it
works.  The RFC is a bit "dry".  :)

Second, here is the article I encountered:
http://www.eweek.com/print_article/0,3668,a%3D24177,00.asp

---
Seairth Jacobs
seairth@...

----- Original Message -----
From: "inthedarkplace" <inthedarkplace@...>
To: <rest-discuss@yahoogroups.com>
Sent: Friday, August 23, 2002 12:49 PM
Subject: [rest-discuss] Re: session stuff (again)


> Seairth,
>
> Personally, I've never heard of different versions of digest
> authentication between the browsers. Plus I don't really see how PHP
> can not support digest authentication. Digest authentication just
> involves parsing the 'Authorization' header and generating the 'WWW-
> Authenticate' header.
>
> I'd suggest you look at:
> http://www.rassoc.com/gregr/weblog/stories/2002/07/09/webServicesSecur
> ityHttpDigestAuthenticationWithoutActiveDirectory.html
>
> That is a 'native' implementation of digest authentication. It
> doesn't matter on the browser or container.
>
> - inthedarkplace
>
> --- In rest-discuss@y..., "Seairth Jacobs" <seairth@s...> wrote:
> > Okay, a few threads back, I asked what was the preferred way to
> handle
> > sessions.  The most popular response was "http authentication".
> Since I am
> > working on this project in PHP, I asked php.net's newsgroups where
> I might
> > find code for digest authentication (basic authentication is easy
> enough).
> > What I got back was that PHP currently does not support digest
> > authentication (though I would have thought I could code around that
> > problem).  And to make things worse, it seems not a lot of browsers
> support
> > digest authentication in a compatible manner.  For instance, I came
> across
> > one article that says:
> >
> >     Opera and Amaya both support Apache's version of digest
> authentication
> >     IE5+ both support IIS's version of digest authentication
> >     Opera and Amays do not work with IIS and IE does not work with
> Apache
> >
> > Now, this may have changed with IE6, but I have not been able to
> find
> > anything to substanciate that.
> >
> > So, this leaves me with using basic authentication.  However, I am
> not crazy
> > about using it for two reasons:
> >
> > 1) Repeatedly sending login information over the wire in
> plaintext.  Now, I
> > realize that I could use SSL, but that would be both expensive and
> slow the
> > site down.
> >
> > 2) I don't see a way to "expire" the login information.  But maybe
> there is
> > a method that I am just not aware of...
> >
> >
> >
> > So, this brings me to session cookies.  Some time back, I recall
> reading the
> > statement that "cookies are not RESTful".  Now, is this all use of
> cookies
> > or just persistant cookies?  Is it okay to use a single session
> cookie?  I
> > would see this as no different from using http authentication (i.e.
> the
> > client resending identifying [set of] values over and over again),
> except
> > that I can occasionally change the cookie's value to limit replay
> attacks
> > and limit the possibility of stealing the password to only one
> request
> > instead of every request (assuming basic authentication).
> >
> >
> > There is one other thing I do like about http authentication:  it
> doesn't
> > "interfere" with the application process.  In other words, the
> browser just
> > resubmits the last request with additional headers.  To implement
> html login
> > forms and cookies, I have to take on the responsibility of keeping
> track of
> > the submitted data in the last request.  It also means that the
> browser
> > caches the login page in it's history (which does not happen with
> http
> > authentication).
> >
> >
> > So, how do you deal with the security issues of http authentication
> vs. html
> > form/cookie authentication when you are running over a unsecure
> conneciton?
> > And how do you do this and keep it all RESTful?
> >
> > ---
> > Seairth Jacobs
> > seairth@s...
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>







-----------------------------------------------------------------------------------
Post ID:2215
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-23 19:29:24
Subject:Re: Just when I thought I had it...
Message:

Mike,

Oops, it looks like you're totally right, PUT can be used for 
resource creation. Thanks for pointing that out.

- inthedarkplace
--- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote:
> 
> > 
> > PUT should never insert, it really only means UPDATE. 
> Sorry, but that is not the way the HTTP specification works.
> It RDBMS/SQL terms it means "UPSERT".
> 
> -- http://www.ietf.org/rfc/rfc2616.txt --
> 9.6 PUT
> 
>    The PUT method requests that the enclosed entity be stored under 
the
>    supplied Request-URI. If the Request-URI refers to an already
>    existing resource, the enclosed entity SHOULD be considered as a
>    modified version of the one residing on the origin server. If the
>    Request-URI does not point to an existing resource, and that URI 
is
>    capable of being defined as a new resource by the requesting user
>    agent, the origin server can create the resource with that URI. 
If a
>    new resource is created, the origin server MUST inform the user 
agent
>    via the 201 (Created) response. If an existing resource is 
modified,
>    either the 200 (OK) or 204 (No Content) response codes SHOULD be 
sent
>    to indicate successful completion of the request. If the resource
>    could not be created or modified with the Request-URI, an 
appropriate
>    error response SHOULD be given that reflects the nature of the
>    problem.







-----------------------------------------------------------------------------------
Post ID:2216
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-26 01:29:55
Subject:Re: [rest-discuss] Re: PUT, POST, authorization and purchase orders
Message:

On Thu, Aug 22, 2002 at 11:36:11PM -0000, bhaugen32 wrote:
> Communication is so difficult....8(

So I hear. 8-)

> return a 201
> 
> > > Ok, let me try again, because there is a lot of confusion on this 
> > > point:
> > > *If* the resource is a container, 
> > > then it is *allowed* to post a subordinate
> > > and request that the server create a new resource
> > > linked to the container.
> > 
> > Nope, at least not with this definition of container.  
> > And FWIW, I think it's pretty standard.  
> > It would be equivalent to a tuple space, or an
> > OpenDoc container, or a Java Beans Context, etc..
> > 
> > > Or would you put it some other way?
> > 
> > As above.
> 
> Nope?!! I thought I said the same thing.  
> What's the difference?  Where am I wrong?
> I don't get it at all.

It's your use of the word "request".  The client can't request it.  It
just sends the data, and it's up to the container to do it, or not.

I suppose you could consider the use of SOAPAction with a URI
identifying the expected type (in this case, a
StatePreservingContainer), a "request".  But I didn't get the impression
that that's what you were suggesting.  If so, then you were right.

> Ok, I'm gonna keep trying until I get this right.
> 
> *If* the resource is a StatePreservingContainer, 
> and if I post the proper request to create a subordinate resource,
> then the container will create a resource and return a 201.

Modulo the "request" issue, yes.

> By the way, I've tried to repeat the same thing you wrote in slightly 
> different words three times now and been told I was wrong by both you 
> and Walden Mathews and still don't know what I'm doing wrong. 
> I know this is possible, and you seem to agree it's possible, but 
> there is obviously some sublety that I am missing.
> 
> Also, the name StatePreservingContainer is not very clear, at least 
> to me. Nor is IdentityPreservingContainer. But maybe that's because 
> I'm still missing some subtlety.

No, it could be the name.  If you've got any suggestions after this,
I'm all ears.

> I think this is an important capability for meeting business 
> requirements.  I'm happy to revert to a hybrid of REST + SOAP, but am 
> still trying to figure out how far I can go with pure REST.
> And I do need to know how to describe it so that it meets the 
> business requirements and will not get shot down by the REST gang.

SOAP's still purely optional.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2217
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-26 02:46:24
Subject:Beating my head against the "session management" wall
Message:

*sigh*  Do you ever have the feeling that the solutions set before you are
all not-quite-good-enough, each in their own way?  Currently, this is how I
am feeling about session management when it comes to REST...

Known options:

1) HTTP Authentication:  This is a simple, non-intrusive solution.  However,
"basic" is insecure and "digest" is not consistently implemented.

2) Generating your own "session id".  This has the problem that you must
provide an "intrusive" login screen/process.  Further, you then need to
continue tracking the session id.  With this, there are two techniques
(well, three sorta):

    a) Session Cookie:  If done properly, this is effectively no different
than http authentication in the sense that the browser is sending an
"authenticating" identifier with each request.  Session cookies are somewhat
nicer than http authentication in that they are potentially more secure (if
done correctly) and that it is easier for the server to handle them (e.g.
deleting them, updating them, etc.).  The major down side is that current
browsers allow the users to reject session cookies.

    b) Query String:  This one, from a REST POV, seems like a really bad
technique.  This effectively creates non-permanent unique URL spaces for
each user session.  Further, the session id may not actually be related to
the resource that the URL (with the query string) is pointing to.  However,
the good thing about query strings is that, short of a user typing an
address into the browser or using a stored link, the server has control over
them and the user does not have the ability to reject them.

    c) Hidden Field: if you are not using the QueryString method and are
have a form, you could put the session id in a hidden field.  However, you
are then limited to using only the POST method.  Otherwise, the browser will
generate a URL with your hidden field showing up in a QueryString.  But, if
the request is guaranteed to be idempotent, then it is my understanding that
the GET method should be used, not POST.


Now, I know that all of the above methods (with the possible exception of
digest authentication, if done correctly and at a certain cost) still allows
someone to sniff the connection and get enough information to potentially
mimic the session.  This could all be taken care of using SSL (at which
point, even basic authentication is secure), but that seems to be adding a
lot of overhead.  When I only need to authenticate the request, not secure
the response, this seems like overkill (and it can be expensive too).



Frankly, I think I am leaning towards session cookies at this point.  Since
the site will primarily be for web developers, I am hoping that they at
least accept session cookies.  I would have liked to go the HTTP
authentication route, but it just seems to unsecure for my taste
(considering the fact that I am not using SSL).  If anyone out there can
convince my why I should not follow this route, esp. as far as REST is
concerned, please say so.  I really would like to be convinced of another
method.


IN THE MEANTIME....

I have been thinking of this dilemma (the one above).  And I have an idea.
I am wondering whether the idea would work well with the REST model or not.
If it would, I would like to get a group of people together to formalize it
and get it submitted to the right people.

What I propose is that web browsers should support a new HTTP header called
"session-id".  This header would conform to the following rules:

1) The header works sort of like a session cookie.  When the header is sent
to the browser, you can specify the domain and path (http authentication
realm?) and an expiration timestamp.  The timestamp only ensures that the
header will stop being sent back to the server if the browser is not closed
by that point.  Just like current cookies, setting the timestamp to the past
will cause the session-id header to become immediately stale.

2) THE USER MAY NOT REJECT THE HEADER.  Browsers that allow optional
rejection will be considered NON-STANDARDS-COMPLIANT.  Proxies SHOULD NOT
REJECT THE HEADER.  I would prefer to make this MAY NOT, but I doubt it
would stick.  What are proxies allowed to do with the www-authenticate
header?

3) the www-authenticate and session-id headers are mutually exclusive.  In
other words, if a browser receives a session-id header which matches the
existing realm, the browser dumps the www-authenticate response and uses
session-id instead.  This allows the http authentication methods to still be
used, but also allows the request headers to be replaced with something that
is more controllable by the server.


Though I know that more thought needs to be put into the idea, I feel it
would provide the consistency of basic authentication, the flexibility and
overhead of cookies, and the security of digest authentication.  Note that
it is not even necessary to use HTML forms, since http authentication could
be used as the first step then replaced as in #3 above.  However, if one
*really* wants the nice look, they could do that as well.

So, what do you all think?  Would this interfere with the REST model?

---
Seairth Jacobs
seairth@...









-----------------------------------------------------------------------------------
Post ID:2218
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-08-26 05:39:32
Subject:Re: [rest-discuss] Beating my head against the "session management" wall
Message:

This may be helpful:

  "There is no session"

and

  "You'll come to realize, as I did, that there's a difference between
knowing the resource and representing the resource."

(with apologies)



----- Original Message -----
From: "Seairth Jacobs" <seairth@...>
To: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Sunday, August 25, 2002 7:46 PM
Subject: [rest-discuss] Beating my head against the "session management"
wall


> *sigh*  Do you ever have the feeling that the solutions set before you
are
> all not-quite-good-enough, each in their own way?  Currently, this is
how I
> am feeling about session management when it comes to REST...
>
> Known options:
>
> 1) HTTP Authentication:  This is a simple, non-intrusive solution.
However,
> "basic" is insecure and "digest" is not consistently implemented.
>
> 2) Generating your own "session id".  This has the problem that you must
> provide an "intrusive" login screen/process.  Further, you then need to
> continue tracking the session id.  With this, there are two techniques
> (well, three sorta):
>
>     a) Session Cookie:  If done properly, this is effectively no
different
> than http authentication in the sense that the browser is sending an
> "authenticating" identifier with each request.  Session cookies are
somewhat
> nicer than http authentication in that they are potentially more secure
(if
> done correctly) and that it is easier for the server to handle them
(e.g.
> deleting them, updating them, etc.).  The major down side is that
current
> browsers allow the users to reject session cookies.
>
>     b) Query String:  This one, from a REST POV, seems like a really bad
> technique.  This effectively creates non-permanent unique URL spaces for
> each user session.  Further, the session id may not actually be related
to
> the resource that the URL (with the query string) is pointing to.
However,
> the good thing about query strings is that, short of a user typing an
> address into the browser or using a stored link, the server has control
over
> them and the user does not have the ability to reject them.
>
>     c) Hidden Field: if you are not using the QueryString method and are
> have a form, you could put the session id in a hidden field.  However,
you
> are then limited to using only the POST method.  Otherwise, the browser
will
> generate a URL with your hidden field showing up in a QueryString.  But,
if
> the request is guaranteed to be idempotent, then it is my understanding
that
> the GET method should be used, not POST.
>
>
> Now, I know that all of the above methods (with the possible exception
of
> digest authentication, if done correctly and at a certain cost) still
allows
> someone to sniff the connection and get enough information to
potentially
> mimic the session.  This could all be taken care of using SSL (at which
> point, even basic authentication is secure), but that seems to be adding
a
> lot of overhead.  When I only need to authenticate the request, not
secure
> the response, this seems like overkill (and it can be expensive too).
>
>
>
> Frankly, I think I am leaning towards session cookies at this point.
Since
> the site will primarily be for web developers, I am hoping that they at
> least accept session cookies.  I would have liked to go the HTTP
> authentication route, but it just seems to unsecure for my taste
> (considering the fact that I am not using SSL).  If anyone out there can
> convince my why I should not follow this route, esp. as far as REST is
> concerned, please say so.  I really would like to be convinced of
another
> method.
>
>
> IN THE MEANTIME....
>
> I have been thinking of this dilemma (the one above).  And I have an
idea.
> I am wondering whether the idea would work well with the REST model or
not.
> If it would, I would like to get a group of people together to formalize
it
> and get it submitted to the right people.
>
> What I propose is that web browsers should support a new HTTP header
called
> "session-id".  This header would conform to the following rules:
>
> 1) The header works sort of like a session cookie.  When the header is
sent
> to the browser, you can specify the domain and path (http authentication
> realm?) and an expiration timestamp.  The timestamp only ensures that
the
> header will stop being sent back to the server if the browser is not
closed
> by that point.  Just like current cookies, setting the timestamp to the
past
> will cause the session-id header to become immediately stale.
>
> 2) THE USER MAY NOT REJECT THE HEADER.  Browsers that allow optional
> rejection will be considered NON-STANDARDS-COMPLIANT.  Proxies SHOULD
NOT
> REJECT THE HEADER.  I would prefer to make this MAY NOT, but I doubt it
> would stick.  What are proxies allowed to do with the www-authenticate
> header?
>
> 3) the www-authenticate and session-id headers are mutually exclusive.
In
> other words, if a browser receives a session-id header which matches the
> existing realm, the browser dumps the www-authenticate response and uses
> session-id instead.  This allows the http authentication methods to
still be
> used, but also allows the request headers to be replaced with something
that
> is more controllable by the server.
>
>
> Though I know that more thought needs to be put into the idea, I feel it
> would provide the consistency of basic authentication, the flexibility
and
> overhead of cookies, and the security of digest authentication.  Note
that
> it is not even necessary to use HTML forms, since http authentication
could
> be used as the first step then replaced as in #3 above.  However, if one
> *really* wants the nice look, they could do that as well.
>
> So, what do you all think?  Would this interfere with the REST model?
>
> ---
> Seairth Jacobs
> seairth@...
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:2219
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-26 08:28:15
Subject:Schemas, RELAX NG, and REST SDL
Message:

Guys,

Lately I've been putting a lot of time into learning/mastering XML 
Schema and I have to say I'm extremely disappointed with this 
technology. It's horrendously complex and it's not even simple enough 
to solve some of the trivial problems I'm throwing at it (unless you 
revert to using xs:token for every datatype which kind of defeats the 
purpose). I really don't like it and I don't see the average 
developer liking and/or using it.

I've done a bit of research on the alternatives and I've come across 
RELAX NG which is muuch better and simpler but the problem is that 
the tool support for RELAX NG is non-existent. I'm not aware of a 
RELAX NG API for either Java or .NET which is my primary audience at 
this point.

That being said, I remember a while back Roger suggested that HTML 
should be used to describe the XML/Interface for RESTful webservices 
(eg what gets POSTed to resource X). I didn't really understand what 
he was saying then, but now it makes perfect sense to me. The primary 
goal for interface specifications (primarily describing data 
structures, that is the structure of XML documents) should be for 
documentation purposes, not code generation purposes (which is the 
only real goal of XML Schema). Since no elegant or simple 
technologies exist to describe XML document structure, I'm starting 
to lean towards Roger's solution of using HTML which is undeniably 
the most accessible and understood markup language out there today.

What do others think? 







-----------------------------------------------------------------------------------
Post ID:2220
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-08-26 10:06:26
Subject:Re: [rest-discuss] Schemas, RELAX NG, and REST SDL
Message:

On Mon, Aug 26, 2002 at 08:28:15AM -0000, inthedarkplace wrote:
> 
> I've done a bit of research on the alternatives and I've come across 
> RELAX NG which is muuch better and simpler but the problem is that 
> the tool support for RELAX NG is non-existent. I'm not aware of a 
> RELAX NG API for either Java or .NET which is my primary audience at 
> this point.

Well, for Java there's Jing:
  http://www.thaiopensource.com/relaxng/jing.html

> only real goal of XML Schema). Since no elegant or simple 
> technologies exist to describe XML document structure,

DTDs are arguably both elegant and simple. But maybe you need to use
namespaces?

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:2221
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-26 11:44:06
Subject:Re: PUT, POST, authorization and purchase orders
Message:

Mark Baker wrote:
> > Nope?!! I thought I said the same thing.  
> > What's the difference?  Where am I wrong?
> > I don't get it at all.
> 
> It's your use of the word "request".  The client can't request it.  
It
> just sends the data, and it's up to the container to do it, or not.

I meant "request" in the sense of HTTP Request.
(Not the everyday use of the word.)
I thought HTTP was a Request-Response protocol.
The URI for the new resource comes back on the Response.

No?

But I'm happy to change the word.
What would you say instead?

> I suppose you could consider the use of SOAPAction with a URI
> identifying the expected type (in this case, a
> StatePreservingContainer), a "request".  But I didn't get the 
impression
> that that's what you were suggesting.  If so, then you were right.

No, I want to stay away from SOAP in these discussions as long as 
possible.

> > Also, the name StatePreservingContainer is not very clear, at 
least 
> > to me. Nor is IdentityPreservingContainer. But maybe that's 
because 
> > I'm still missing some subtlety.
> 
> No, it could be the name.  If you've got any suggestions after this,
> I'm all ears.

The feature we are discussing is the creation of a new resource in 
response to a POST, right?  "IdentityPreserving" sounds like it 
already has an identity, and the container is preserving it, whereas 
the server is creating the identity.  How long the identity is 
preserved is another consideration; "forever" may not be needed.
"ResourceCreatingContainer" would work for me, if that is the main 
distinguishing feature of this type.








-----------------------------------------------------------------------------------
Post ID:2222
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-26 14:06:06
Subject:Re: [rest-discuss] Beating my head against the "session management" wall
Message:

That wasn't helpful at all (with apologies :)).  If "there is no session"
means to say that you get rid of the concept of sessions when using the REST
model, then I honestly do not see how REST could be successfully applied to
the majority of existing web applications today.  Further, if anyone
considers HTTP authentication to not be a session-handling method (though I
know you didn't say this), I strongly disagree.

And what do you mean by the second quote?


If these quotes are the answers to my session-handling issues, then I
obviously have a gross misunderstanding about how REST is meant to work...

---
Seairth Jacobs
seairth@...


----- Original Message -----
From: "Mark Nottingham" <mnot@...>

> This may be helpful:
>
>   "There is no session"
>
> and
>
>   "You'll come to realize, as I did, that there's a difference between
> knowing the resource and representing the resource."
>
> (with apologies)
>
>
>
> ----- Original Message -----
> From: "Seairth Jacobs" <seairth@...>
> To: "rest-discuss" <rest-discuss@yahoogroups.com>
> Sent: Sunday, August 25, 2002 7:46 PM
> Subject: [rest-discuss] Beating my head against the "session management"
> wall
>
>
> > *sigh*  Do you ever have the feeling that the solutions set before you
> are
> > all not-quite-good-enough, each in their own way?  Currently, this is
> how I
> > am feeling about session management when it comes to REST...
> >
> > Known options:
> >
> > 1) HTTP Authentication:  This is a simple, non-intrusive solution.
> However,
> > "basic" is insecure and "digest" is not consistently implemented.
> >
> > 2) Generating your own "session id".  This has the problem that you must
> > provide an "intrusive" login screen/process.  Further, you then need to
> > continue tracking the session id.  With this, there are two techniques
> > (well, three sorta):
> >
> >     a) Session Cookie:  If done properly, this is effectively no
> different
> > than http authentication in the sense that the browser is sending an
> > "authenticating" identifier with each request.  Session cookies are
> somewhat
> > nicer than http authentication in that they are potentially more secure
> (if
> > done correctly) and that it is easier for the server to handle them
> (e.g.
> > deleting them, updating them, etc.).  The major down side is that
> current
> > browsers allow the users to reject session cookies.
> >
> >     b) Query String:  This one, from a REST POV, seems like a really bad
> > technique.  This effectively creates non-permanent unique URL spaces for
> > each user session.  Further, the session id may not actually be related
> to
> > the resource that the URL (with the query string) is pointing to.
> However,
> > the good thing about query strings is that, short of a user typing an
> > address into the browser or using a stored link, the server has control
> over
> > them and the user does not have the ability to reject them.
> >
> >     c) Hidden Field: if you are not using the QueryString method and are
> > have a form, you could put the session id in a hidden field.  However,
> you
> > are then limited to using only the POST method.  Otherwise, the browser
> will
> > generate a URL with your hidden field showing up in a QueryString.  But,
> if
> > the request is guaranteed to be idempotent, then it is my understanding
> that
> > the GET method should be used, not POST.
> >
> >
> > Now, I know that all of the above methods (with the possible exception
> of
> > digest authentication, if done correctly and at a certain cost) still
> allows
> > someone to sniff the connection and get enough information to
> potentially
> > mimic the session.  This could all be taken care of using SSL (at which
> > point, even basic authentication is secure), but that seems to be adding
> a
> > lot of overhead.  When I only need to authenticate the request, not
> secure
> > the response, this seems like overkill (and it can be expensive too).
> >
> >
> >
> > Frankly, I think I am leaning towards session cookies at this point.
> Since
> > the site will primarily be for web developers, I am hoping that they at
> > least accept session cookies.  I would have liked to go the HTTP
> > authentication route, but it just seems to unsecure for my taste
> > (considering the fact that I am not using SSL).  If anyone out there can
> > convince my why I should not follow this route, esp. as far as REST is
> > concerned, please say so.  I really would like to be convinced of
> another
> > method.
> >
> >
> > IN THE MEANTIME....
> >
> > I have been thinking of this dilemma (the one above).  And I have an
> idea.
> > I am wondering whether the idea would work well with the REST model or
> not.
> > If it would, I would like to get a group of people together to formalize
> it
> > and get it submitted to the right people.
> >
> > What I propose is that web browsers should support a new HTTP header
> called
> > "session-id".  This header would conform to the following rules:
> >
> > 1) The header works sort of like a session cookie.  When the header is
> sent
> > to the browser, you can specify the domain and path (http authentication
> > realm?) and an expiration timestamp.  The timestamp only ensures that
> the
> > header will stop being sent back to the server if the browser is not
> closed
> > by that point.  Just like current cookies, setting the timestamp to the
> past
> > will cause the session-id header to become immediately stale.
> >
> > 2) THE USER MAY NOT REJECT THE HEADER.  Browsers that allow optional
> > rejection will be considered NON-STANDARDS-COMPLIANT.  Proxies SHOULD
> NOT
> > REJECT THE HEADER.  I would prefer to make this MAY NOT, but I doubt it
> > would stick.  What are proxies allowed to do with the www-authenticate
> > header?
> >
> > 3) the www-authenticate and session-id headers are mutually exclusive.
> In
> > other words, if a browser receives a session-id header which matches the
> > existing realm, the browser dumps the www-authenticate response and uses
> > session-id instead.  This allows the http authentication methods to
> still be
> > used, but also allows the request headers to be replaced with something
> that
> > is more controllable by the server.
> >
> >
> > Though I know that more thought needs to be put into the idea, I feel it
> > would provide the consistency of basic authentication, the flexibility
> and
> > overhead of cookies, and the security of digest authentication.  Note
> that
> > it is not even necessary to use HTML forms, since http authentication
> could
> > be used as the first step then replaced as in #3 above.  However, if one
> > *really* wants the nice look, they could do that as well.
> >
> > So, what do you all think?  Would this interfere with the REST model?
> >
> > ---
> > Seairth Jacobs
> > seairth@...
> >
> >
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> >
> >
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>







-----------------------------------------------------------------------------------
Post ID:2223
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-26 14:39:58
Subject:Re: [rest-discuss] Re: PUT, POST, authorization and purchase orde rs
Message:

On Fri, Aug 23, 2002 at 11:32:19AM -0400, Mathews, Walden wrote:
> The root of all evil here is the fact that *operations* are also first class
> abstractions,
> every bit as first class as *resource state*, except in REST (and for well
> understood
> reasons there).
>  
> So how do you evaluate the tradeoff between using RDF as part of resource
> state
> to extend the semantics of 'generic' methods?  As opposed to extending the
> defined set of
> methods for the sake of greater method specificity?

Extending the methods means being able to reuse the semantics of the
existing contract between client and server; aka firewall safe.  If I
POST some data to /foo with an intent of /bar, I'm still doing a POST,
and it's still the server that has the ultimate say (because it's still
a POST).  This is in contrast to invoking the BAR method, which could
mean anything.

>  As opposed to adding
> 'control' data
> (mentioned in the thesis, but not in association with HTTP) to qualify
> methods?

AFAIK, "control data" refers to fringe "management" aspects of the
connection; caching, varyability, connection stuff, mux, ordering,
etc..  It doesn't change or extend the methods.

>  As
> opposed to any other meta-method for working around generic method
> limitations?

Not sure what other approaches there might be.  PEP had the "PEP"
method, which was sort of a wildcard so that you could URI-identify
an extension method.  Think of it as a layer 6 construct, so that the
URI could identify the layer 7 extension.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2224
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-26 15:24:09
Subject:Re: [rest-discuss] Re: PUT, POST, authorization and purchase orders
Message:

On Mon, Aug 26, 2002 at 11:44:06AM -0000, bhaugen32 wrote:
> > It's your use of the word "request".  The client can't request it.  
> It
> > just sends the data, and it's up to the container to do it, or not.
> 
> I meant "request" in the sense of HTTP Request.
> (Not the everyday use of the word.)
> I thought HTTP was a Request-Response protocol.
> The URI for the new resource comes back on the Response.
> 
> No?

Ok, but I took your use of the word to imply that there was something
about the HTTP request message that made the server think that this
message was explicitly asking that a new resource be created.

> But I'm happy to change the word.
> What would you say instead?

"Intent" is the word that SOAP uses to describe SOAPAction.  I like it.
i.e. "this HTTP POST request is sent with the intent of archiving the
data".

> > I suppose you could consider the use of SOAPAction with a URI
> > identifying the expected type (in this case, a
> > StatePreservingContainer), a "request".  But I didn't get the 
> impression
> > that that's what you were suggesting.  If so, then you were right.
> 
> No, I want to stay away from SOAP in these discussions as long as 
> possible.

Ok, but this mechanism is needed in vanilla HTTP too, whether or not it
comes from SOAP.  Basically, a header that must be understood by the
recipient, otherwise the intent will be lost and communication will be
unclear.

> > No, it could be the name.  If you've got any suggestions after this,
> > I'm all ears.
> 
> The feature we are discussing is the creation of a new resource in 
> response to a POST, right?  "IdentityPreserving" sounds like it 
> already has an identity, and the container is preserving it, whereas 
> the server is creating the identity.

Right.  Hence the change ..

>  How long the identity is 
> preserved is another consideration; "forever" may not be needed.
> "ResourceCreatingContainer" would work for me, if that is the main 
> distinguishing feature of this type.

It sort of is, but it's not that any old resource is created, it's that
one whose initial state is equivalent to what was POSTed is created.
That's what we need a good name for.  "ResourceCreatingContainer"
describes the behaviour - resource creation - not the purpose of the
container.  I'm not sure how that would be used.  Or to rephrase, the
interesting thing is not to know whether or not a resource is to be
created, because you'll know that anyhow after the POST - the
interesting thing to know is *why* it will be created and what it
means that it was.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2225
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-26 15:37:19
Subject:Re: [rest-discuss] Re: PUT, POST, authorization and purchase orde rs
Message:

On Mon, Aug 26, 2002 at 11:21:26AM -0400, Mathews, Walden wrote:
> > Extending the methods means being able to reuse the semantics of the
> > existing contract between client and server; aka firewall safe.  If I
> > POST some data to /foo with an intent of /bar, I'm still doing a POST,
> > and it's still the server that has the ultimate say (because 
> > it's still
> > a POST).  This is in contrast to invoking the BAR method, which could
> > mean anything.
> > 
> 
> I'd like to understand this point better.  Nothing I can do as a client
> in the HTTP method space can change the fact that "it's still the server
> that has the ultimate say".  BAR *could* mean anything, while POST already
> *does* mean anything (virtually).

Whatever BAR might mean, if the community (i.e. IETF) has specified that
HTTP implementations MUST support BAR, then the server doesn't have the
final say, the spec does.

> A little clarification: the fact that a server doesn't have to do what I
> say in a POST is not a property of POST; it's a property of HTTP, and more
> broadly, of server side applications that are autonomous in their
> respective domains, regardless of which level 7 protocol they use.

In the broader space of "server side applications", I'd say that the
party(s) that define the contract get the final say.  With most RPC
systems, this could be the very people who implement the system, and so
they do/can have the final say.  But when the world sits down to design
an application protocol, it is done with the expectation that
implementors - many/most of whom won't be at the standardization table -
will follow the rules in the specification.  And this is, in fact, what
happens most of the time.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2226
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-26 16:05:37
Subject:RE: [rest-discuss] Re: PUT, POST, authorization and purchase orde rs
Message:


> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Monday, August 26, 2002 11:37 AM
> To: Mathews, Walden
> Cc: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Re: PUT, POST, authorization and purchase
> orde rs
> 
> 
> On Mon, Aug 26, 2002 at 11:21:26AM -0400, Mathews, Walden wrote:
> > > Extending the methods means being able to reuse the 
> semantics of the
> > > existing contract between client and server; aka firewall 
> safe.  If I
> > > POST some data to /foo with an intent of /bar, I'm still 
> doing a POST,
> > > and it's still the server that has the ultimate say (because 
> > > it's still
> > > a POST).  This is in contrast to invoking the BAR method, 
> which could
> > > mean anything.
> > > 
> > 
> > I'd like to understand this point better.  Nothing I can do 
> as a client
> > in the HTTP method space can change the fact that "it's 
> still the server
> > that has the ultimate say".  BAR *could* mean anything, 
> while POST already
> > *does* mean anything (virtually).
> 
> Whatever BAR might mean, if the community (i.e. IETF) has 
> specified that
> HTTP implementations MUST support BAR, then the server 
> doesn't have the
> final say, the spec does.

Sorry, I'm confused.  By "HTTP implementations" do you mean things
like libwww, or applications that use HTTP?  Then, I'll infer the meaning
of "support BAR" from that, hopefully.  But in the meantime, for
technologies like libwww, HttpClient and Servlet to "support BAR"
means little more than forwarding messages with them.  On the other
hand, applications seem to be free to choose which methods they will
and will not support (or else there are some superfluous response
codes).  Like I said, I'm confused...

> 
> > A little clarification: the fact that a server doesn't have 
> to do what I
> > say in a POST is not a property of POST; it's a property of 
> HTTP, and more
> > broadly, of server side applications that are autonomous in their
> > respective domains, regardless of which level 7 protocol they use.
> 
> In the broader space of "server side applications", I'd say that the
> party(s) that define the contract get the final say.  With most RPC
> systems, this could be the very people who implement the 
> system, and so
> they do/can have the final say.  But when the world sits down 
> to design
> an application protocol, it is done with the expectation that
> implementors - many/most of whom won't be at the 
> standardization table -
> will follow the rules in the specification.  And this is, in 
> fact, what
> happens most of the time.

And that's fine for methods GET, PUT and DELETE, all of whose meanings
are bounded to a single conceptual resource.  POST is in a different
class, as you know.  One might say that it's *underspecified* as an
application
semantic, or from the other point of view, that it's overloaded to catch
everything that's not meant by the other methods.

What I'm trying to understand is why it is more of a security concern
to use a very underspecified HTTP method (e.g., "BAR", which is not
specified
at all as an HTTP method) as opposed to a somewhat underspecified method,
"POST".  POST seems like a ready-made tunnel for resource mutation, and
hence even in RESTful design it is used this way.  Why should a firewall
treat POST any differently than BAR, given the real limitations to
visibility?

Thanks,
Walden






-----------------------------------------------------------------------------------
Post ID:2227
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-26 17:02:55
Subject:HTTP and safety
Message:

We're creeping into rest-explore territory here.

On Mon, Aug 26, 2002 at 12:05:37PM -0400, Mathews, Walden wrote:
> > Whatever BAR might mean, if the community (i.e. IETF) has 
> > specified that
> > HTTP implementations MUST support BAR, then the server 
> > doesn't have the
> > final say, the spec does.
> 
> Sorry, I'm confused.  By "HTTP implementations" do you mean things
> like libwww, or applications that use HTTP?

Mostly the former, but ultimately both, since it takes both together
to complete the task.  For example, a servlet can give you doGet(),
and manage etags and cache control and stuff for you, but it's still up
to the app to not to change state when it's invoked.

>  Then, I'll infer the meaning
> of "support BAR" from that, hopefully.  But in the meantime, for
> technologies like libwww, HttpClient and Servlet to "support BAR"
> means little more than forwarding messages with them.  On the other
> hand, applications seem to be free to choose which methods they will
> and will not support (or else there are some superfluous response
> codes).  Like I said, I'm confused...
> 
> > 
> > > A little clarification: the fact that a server doesn't have 
> > to do what I
> > > say in a POST is not a property of POST; it's a property of 
> > HTTP, and more
> > > broadly, of server side applications that are autonomous in their
> > > respective domains, regardless of which level 7 protocol they use.
> > 
> > In the broader space of "server side applications", I'd say that the
> > party(s) that define the contract get the final say.  With most RPC
> > systems, this could be the very people who implement the 
> > system, and so
> > they do/can have the final say.  But when the world sits down 
> > to design
> > an application protocol, it is done with the expectation that
> > implementors - many/most of whom won't be at the 
> > standardization table -
> > will follow the rules in the specification.  And this is, in 
> > fact, what
> > happens most of the time.
> 
> And that's fine for methods GET, PUT and DELETE, all of whose meanings
> are bounded to a single conceptual resource.  POST is in a different
> class, as you know.  One might say that it's *underspecified* as an
> application
> semantic, or from the other point of view, that it's overloaded to catch
> everything that's not meant by the other methods.

I wouldn't say that it's underspecified at all.  Why do you believe it
is?

> What I'm trying to understand is why it is more of a security concern
> to use a very underspecified HTTP method (e.g., "BAR", which is not
> specified
> at all as an HTTP method) as opposed to a somewhat underspecified method,
> "POST".  POST seems like a ready-made tunnel for resource mutation, and
> hence even in RESTful design it is used this way.  Why should a firewall
> treat POST any differently than BAR, given the real limitations to
> visibility?

The fundamental issue to firewall admins is that somebody on the other
side of the firewall should not be able to extend the semantics of the
connection such that visibility to the firewall is reduced.  i.e. the
system shouldn't be able to break itself.

People have, for some time, talked about being able to *prove* the
security of application protocols like HTTP, by examining exactly these
sorts of issues; what kinds of extended agreement can be created, and
can it ever be used to do something that goes against a security policy
enacted by an intermediary.  For RFC 2616 POST, this *cannot* be done.
But it's not automatically the case for extension methods - they need to
be studied closely.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2228
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-08-26 18:58:19
Subject:Re: [rest-discuss] Beating my head against the "session management" wall
Message:

My pop culture references weren't meant to answer your questions; I was
hoping/assuming that someone more REST enlightened than I would do so.

Since noone has, here are my thoughts;

HTTP authentication clearly involves keeping state on the client; as such,
whenever I try to resource model an application, this is the main means of
identifying a client in order to tailor information for it. As you
surmise, cookies are often used in place of HTTP authentication because
they can be persistent across invocations of the browser (although modern
browsers address this with a 'password store' mechanism), they can be
deleted, and because there is more control over the UI. Authentication,
OTOH, has advantages in that the state can be incorporated into the URI
(cookies can't), and the mechanism is standardized, allowing for machines
to present credentials (this could be possible with cookies, but
practically, it's impossible; they'd have to understand your specific
authentication scheme).

Doing it in the request body (POST) is clearly not RESTful, and doing it
correctly with the URI query is tricky at best, IMHO.

So, when choosing between these mechanisms, I prefer HTTP authentication
wherever possible; if you investigate modern browsers, you should find
that Digest has been implemented correctly (I use it opften with IE6,
Mozilla and Amaya; IIRC it also works on Opera).

All of this notwithstanding, and most importantly, if you approach your
application from a model of 'sessions' (which most environments encourage
you to do), you'll find it very hard to keep it RESTful. Model your
application as resources which expose state as representations, and the
issue of sessions will (hopefully) dissolve into the background, for the
most part.

Architecting applications that don't require client state brings many
benefits. Witness search engines, translation services, annotation
services, shared caching, 'this page has changed' bots, etc., etc.
Requiring client state reduces the effectiveness or even eliminates these
benefits, and locks your users into exactly one way of seeing the data:
the way that you lead them through it. While this is attractive to the
application developer, it isn't to users, and hence ultimately reduces the
potential benefit of making the application part of the Web.

Regards,


----- Original Message -----
From: "Seairth Jacobs" <seairth@...>
To: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Monday, August 26, 2002 7:06 AM
Subject: Re: [rest-discuss] Beating my head against the "session
management" wall


> That wasn't helpful at all (with apologies :)).  If "there is no
session"
> means to say that you get rid of the concept of sessions when using the
REST
> model, then I honestly do not see how REST could be successfully applied
to
> the majority of existing web applications today.  Further, if anyone
> considers HTTP authentication to not be a session-handling method
(though I
> know you didn't say this), I strongly disagree.
>
> And what do you mean by the second quote?
>
>
> If these quotes are the answers to my session-handling issues, then I
> obviously have a gross misunderstanding about how REST is meant to
work...
>
> ---
> Seairth Jacobs
> seairth@...
>
>
> ----- Original Message -----
> From: "Mark Nottingham" <mnot@...>
>
> > This may be helpful:
> >
> >   "There is no session"
> >
> > and
> >
> >   "You'll come to realize, as I did, that there's a difference between
> > knowing the resource and representing the resource."
> >
> > (with apologies)
> >
> >
> >
> > ----- Original Message -----
> > From: "Seairth Jacobs" <seairth@...>
> > To: "rest-discuss" <rest-discuss@yahoogroups.com>
> > Sent: Sunday, August 25, 2002 7:46 PM
> > Subject: [rest-discuss] Beating my head against the "session
management"
> > wall
> >
> >
> > > *sigh*  Do you ever have the feeling that the solutions set before
you
> > are
> > > all not-quite-good-enough, each in their own way?  Currently, this
is
> > how I
> > > am feeling about session management when it comes to REST...
> > >
> > > Known options:
> > >
> > > 1) HTTP Authentication:  This is a simple, non-intrusive solution.
> > However,
> > > "basic" is insecure and "digest" is not consistently implemented.
> > >
> > > 2) Generating your own "session id".  This has the problem that you
must
> > > provide an "intrusive" login screen/process.  Further, you then need
to
> > > continue tracking the session id.  With this, there are two
techniques
> > > (well, three sorta):
> > >
> > >     a) Session Cookie:  If done properly, this is effectively no
> > different
> > > than http authentication in the sense that the browser is sending an
> > > "authenticating" identifier with each request.  Session cookies are
> > somewhat
> > > nicer than http authentication in that they are potentially more
secure
> > (if
> > > done correctly) and that it is easier for the server to handle them
> > (e.g.
> > > deleting them, updating them, etc.).  The major down side is that
> > current
> > > browsers allow the users to reject session cookies.
> > >
> > >     b) Query String:  This one, from a REST POV, seems like a really
bad
> > > technique.  This effectively creates non-permanent unique URL spaces
for
> > > each user session.  Further, the session id may not actually be
related
> > to
> > > the resource that the URL (with the query string) is pointing to.
> > However,
> > > the good thing about query strings is that, short of a user typing
an
> > > address into the browser or using a stored link, the server has
control
> > over
> > > them and the user does not have the ability to reject them.
> > >
> > >     c) Hidden Field: if you are not using the QueryString method and
are
> > > have a form, you could put the session id in a hidden field.
However,
> > you
> > > are then limited to using only the POST method.  Otherwise, the
browser
> > will
> > > generate a URL with your hidden field showing up in a QueryString.
But,
> > if
> > > the request is guaranteed to be idempotent, then it is my
understanding
> > that
> > > the GET method should be used, not POST.
> > >
> > >
> > > Now, I know that all of the above methods (with the possible
exception
> > of
> > > digest authentication, if done correctly and at a certain cost)
still
> > allows
> > > someone to sniff the connection and get enough information to
> > potentially
> > > mimic the session.  This could all be taken care of using SSL (at
which
> > > point, even basic authentication is secure), but that seems to be
adding
> > a
> > > lot of overhead.  When I only need to authenticate the request, not
> > secure
> > > the response, this seems like overkill (and it can be expensive
too).
> > >
> > >
> > >
> > > Frankly, I think I am leaning towards session cookies at this point.
> > Since
> > > the site will primarily be for web developers, I am hoping that they
at
> > > least accept session cookies.  I would have liked to go the HTTP
> > > authentication route, but it just seems to unsecure for my taste
> > > (considering the fact that I am not using SSL).  If anyone out there
can
> > > convince my why I should not follow this route, esp. as far as REST
is
> > > concerned, please say so.  I really would like to be convinced of
> > another
> > > method.
> > >
> > >
> > > IN THE MEANTIME....
> > >
> > > I have been thinking of this dilemma (the one above).  And I have an
> > idea.
> > > I am wondering whether the idea would work well with the REST model
or
> > not.
> > > If it would, I would like to get a group of people together to
formalize
> > it
> > > and get it submitted to the right people.
> > >
> > > What I propose is that web browsers should support a new HTTP header
> > called
> > > "session-id".  This header would conform to the following rules:
> > >
> > > 1) The header works sort of like a session cookie.  When the header
is
> > sent
> > > to the browser, you can specify the domain and path (http
authentication
> > > realm?) and an expiration timestamp.  The timestamp only ensures
that
> > the
> > > header will stop being sent back to the server if the browser is not
> > closed
> > > by that point.  Just like current cookies, setting the timestamp to
the
> > past
> > > will cause the session-id header to become immediately stale.
> > >
> > > 2) THE USER MAY NOT REJECT THE HEADER.  Browsers that allow optional
> > > rejection will be considered NON-STANDARDS-COMPLIANT.  Proxies
SHOULD
> > NOT
> > > REJECT THE HEADER.  I would prefer to make this MAY NOT, but I doubt
it
> > > would stick.  What are proxies allowed to do with the
www-authenticate
> > > header?
> > >
> > > 3) the www-authenticate and session-id headers are mutually
exclusive.
> > In
> > > other words, if a browser receives a session-id header which matches
the
> > > existing realm, the browser dumps the www-authenticate response and
uses
> > > session-id instead.  This allows the http authentication methods to
> > still be
> > > used, but also allows the request headers to be replaced with
something
> > that
> > > is more controllable by the server.
> > >
> > >
> > > Though I know that more thought needs to be put into the idea, I
feel it
> > > would provide the consistency of basic authentication, the
flexibility
> > and
> > > overhead of cookies, and the security of digest authentication.
Note
> > that
> > > it is not even necessary to use HTML forms, since http
authentication
> > could
> > > be used as the first step then replaced as in #3 above.  However, if
one
> > > *really* wants the nice look, they could do that as well.
> > >
> > > So, what do you all think?  Would this interfere with the REST
model?
> > >
> > > ---
> > > Seairth Jacobs
> > > seairth@...
> > >
> > >
> > >
> > >
> > >
> > > To unsubscribe from this group, send an email to:
> > > rest-discuss-unsubscribe@yahoogroups.com
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
> > http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:2229
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-26 19:13:03
Subject:Re: [rest-discuss] Beating my head against the "session management" wall
Message:

I agree with Mark completely.

The main problem is that the current generation of browsers don't
provide sufficient functionality to allow the client-side to maintain
the necessary state required for some operations.  We've talked about
shopping baskets here before; their state should ideally be maintained
at the client, not the server.  But currently there is no means for
handling this on the client.

But you could imagine browsing through a web site, dragging off
products you want and dropping them in a local folder, then at some
point dragging that folder and dropping it onto the "checkout"
symbol within the web page.  No session required.

I wonder how far you could take "file upload" in this direction?  And/or
some Javascript to provide the local containers ...  Hmm.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2230
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-08-26 19:26:13
Subject:Re: [rest-discuss] Beating my head against the "session management" wall
Message:

That's an important distinction that I didn't make (and hadn't fully
appreciated until Mark pointed it out) -
client state in itself isn't bad, it's enshrining it in the protocol
interactions that brings the problems.


----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "Mark Nottingham" <mnot@...>
Cc: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Monday, August 26, 2002 12:13 PM
Subject: Re: [rest-discuss] Beating my head against the "session
management" wall


> I agree with Mark completely.
>
> The main problem is that the current generation of browsers don't
> provide sufficient functionality to allow the client-side to maintain
> the necessary state required for some operations.  We've talked about
> shopping baskets here before; their state should ideally be maintained
> at the client, not the server.  But currently there is no means for
> handling this on the client.
>
> But you could imagine browsing through a web site, dragging off
> products you want and dropping them in a local folder, then at some
> point dragging that folder and dropping it onto the "checkout"
> symbol within the web page.  No session required.
>
> I wonder how far you could take "file upload" in this direction?  And/or
> some Javascript to provide the local containers ...  Hmm.
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:2231
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-08-26 19:34:29
Subject:Re: [rest-discuss] Searching Containers
Message:

inthedarkplace wrote:
> Guys,
> 
> I'm curious; has anybody established any best practices for 
> performing arbitrary searching of collection resources? Eg, say I 
> have the collection /users and I want to find a user with the 
> username 'kd'. What's the most RESTful and elegant way to do this? 

> 2) Have the user do a GET on the users collection, passing the search 
> query in through the query string. eg /users?username='xxx'
> 
> Pros: Intuitive. This is what for the query string is for, I think. 
> It also allows the user to bookmark searches which might be 
> potentially very useful for working with sets of users.
> 
> Cons: Severely limits the expressiveness of queries. Also puts more 
> code in the users code, but this isn't a huge issue.

To me, the above (2) is the most HTTP way of doing it.  I like it 
because it fits the query parameter model.  It's idempotent.  It's also 
very simple.  The value of username can be a string, a regexp, or 
whatever.  Our app uses just values that have to match.  If the 
parameter is "dateLessThan" then the date must be less than.  Of course, 
if that's not expressive enough, the client can get the entire resource 
and perform its own searches.

It may help to think why your client does not know what it is looking 
for.  There may be a better way to model the app such that the client 
has a much clearer path to getting to the object.

Anyhoot, my vote: use query parameters to "whittle down" that particular 
resource.  If the resource is a collection, I don't believe this 
violates any RESTful thinking.

Seth





-----------------------------------------------------------------------------------
Post ID:2232
Sender:Phil Eskelin <philip.eskelin@...>
Post Date/Time:2002-08-26 19:37:33
Subject:RE: [rest-discuss] Beating my head against the "session managemen t" wall
Message:

Just to pipe in a quick comment -- I totally appreciate this viewpoint,
thanks for sharing it.

To me, styles such as client state really represent what REST promises in
terms of a really truly scalable architecture.  Scalability becomes less of
a problem and more of an attribute of the architectural style of your
solution, because session is distributed across all the clients that access
a server's services.

In many existing web applications, sessions take up lots of memory, cause
state management headaches, and make clustering/load balancing more
complicated/expensive than it needs to be.  Perhaps curing these evils will
eventually become a selling point (to distributed programmers, not marketing
types) of the RESTful approach.

-----Original Message-----
From: Mark Nottingham [mailto:mnot@...]
Sent: Monday, August 26, 2002 3:26 PM
To: Mark Baker
Cc: rest-discuss
Subject: Re: [rest-discuss] Beating my head against the "session management"
wall


That's an important distinction that I didn't make (and hadn't fully
appreciated until Mark pointed it out) -
client state in itself isn't bad, it's enshrining it in the protocol
interactions that brings the problems.


----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "Mark Nottingham" <mnot@...>
Cc: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Monday, August 26, 2002 12:13 PM
Subject: Re: [rest-discuss] Beating my head against the "session
management" wall


> I agree with Mark completely.
>
> The main problem is that the current generation of browsers don't
> provide sufficient functionality to allow the client-side to maintain
> the necessary state required for some operations.  We've talked about
> shopping baskets here before; their state should ideally be maintained
> at the client, not the server.  But currently there is no means for
> handling this on the client.
>
> But you could imagine browsing through a web site, dragging off
> products you want and dropping them in a local folder, then at some
> point dragging that folder and dropping it onto the "checkout"
> symbol within the web page.  No session required.
>
> I wonder how far you could take "file upload" in this direction?  And/or
> some Javascript to provide the local containers ...  Hmm.
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>


Yahoo! Groups Sponsor
ADVERTISEMENT



To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 

________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.






-----------------------------------------------------------------------------------
Post ID:2233
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-26 19:39:31
Subject:Another container model, sorta
Message:

Just found this;

http://www.concentric.net/~aleph0/www/interactive/drafts/draft-burchard-www-arch.html

Pretty interesting.  It isn't dated, but I'd guess it's probably from
around 95/96 when Paul was most active in Web stuff.

I think that IDL is the wrong language in which to create this type of
model, but if I had to use it, my model would probably look a whole lot
like that.  The explicit calling out of compound documents is good,
though I think he missed the ball on tying it to the model, since he
seems to be under the impression that there are "presentation
resources".  But the seeds are there anyhow.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2234
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-26 19:50:17
Subject:Re: [rest-discuss] Beating my head against the "session management" wall
Message:

Let's start at the top and describe what problems session management solves
for you.
With that, we can stay concrete in our suggestions on how to maintain a
RESTful design.

From my experience, session management has been a mechanism to achieve
higher performance through servers-side caching of some data.
What does 'session management' mean to you?







-----------------------------------------------------------------------------------
Post ID:2235
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-26 20:07:33
Subject:Re: [rest-discuss] Another container model, sorta
Message:

> The explicit calling out of compound documents is good,
> though I think he missed the ball on tying it to the model, since he
> seems to be under the impression that there are "presentation
> resources".
I think his concept of 'presentation resources' as being named items on the
client is interesting.
For example, in HTML DOM, there are items in the user agent that are named
and referenceable in HTML - e.g. the <a target=""> stuff.

Pushing this to be generalized in that you 'post' to the display area is a
bit much abstraction though.







-----------------------------------------------------------------------------------
Post ID:2236
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-08-26 20:22:19
Subject:Re: [rest-discuss] Beating my head against the "session management" wall
Message:

> Finally --- and I *WISH* that somebody in the server implementation
> world would finally get a clue and realize this --- in e.g. most
> enterprise IT settings the folks that manage server configuration are
> different from the folks that manage application data are different from
> the folks that develop the apps!  It's not the case that these are the
> same people, or that folks in either of the latter two camps even have
> shell access to the machines that the apps run on, much less the ability
> to muck with various configuration files.  If the Apache guys wanted to
> see HTTP authentication used for more than just small-scale Intranet /
> group use, they should create a generic and standard authentication
> framework into which arbitrary authentication schemes could be
> plugged --- and no, I'm not talking about PAM-like stuff that
> authenticates against the typical system / user DBs, I'm talking about
> an API into which any app developer could plug an arbitrary module to
> authenticate against e.g. the application's own user DB.  (It might be
> there already, but if it is I haven't found it. ;-)  Bottom line, HTTP
> authentication doesn't get used on the larger scales because the guys
> building the apps don't own the config, the guys that own the config
> aren't in the business of user management for a given app, and never the
> twain shall meet (today.)

I can't express how much I agree, but I can try. One of the banes of my
existence is the poor support for metadata in Web servers; not just
authentication, but HTTP headers, status codes, etc. in general. It's
absurd that if I want to generate a redirect, I have to go and modify the
server configuration; no wonder so many people use HTML refresh! Same with
caching headers, etc.

This is not a trivial problem, doubly so if it needs to be standardized
across servers. We can try, however (and I'll glady lend my hand if
someone's interested in starting...)


> But
> identifying a sequence of HTTP "transactions" as related by grouping
> them in a session is not by itself a killer for REST.

I generally agree, but it's very easy for developers to over-rely on
sessions.








-----------------------------------------------------------------------------------
Post ID:2237
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-26 20:29:05
Subject:Re: [rest-discuss] Beating my head against the "session management" wall
Message:

On Mon, Aug 26, 2002 at 01:22:19PM -0700, Mark Nottingham wrote:
> I can't express how much I agree, but I can try.

Yah, ditto.

Mark, I recall an old I-D of yours - that I can't track down now - that
talked about the practical problems with Web servers not exposing
enough, or exposing too much info to their users.  It was really
excellent.  Do you have an archive copy around?

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2238
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-08-26 21:03:59
Subject:Re: [rest-discuss] Beating my head against the "session management" wall
Message:

Do you mean:
  http://www.mnot.net/papers/capabilities.pdf

Would be interesting to update that now...




----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "Mark Nottingham" <mnot@...>
Cc: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Monday, August 26, 2002 1:29 PM
Subject: Re: [rest-discuss] Beating my head against the "session
management" wall


> On Mon, Aug 26, 2002 at 01:22:19PM -0700, Mark Nottingham wrote:
> > I can't express how much I agree, but I can try.
>
> Yah, ditto.
>
> Mark, I recall an old I-D of yours - that I can't track down now - that
> talked about the practical problems with Web servers not exposing
> enough, or exposing too much info to their users.  It was really
> excellent.  Do you have an archive copy around?
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
>







-----------------------------------------------------------------------------------
Post ID:2239
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-26 21:37:25
Subject:Re: Beating my head against the "session management" wall
Message:

--- In rest-discuss@y..., Mark Baker <distobj@a...> wrote:
> I agree with Mark completely.
> 
> But you could imagine browsing through a web site, dragging off
> products you want and dropping them in a local folder, then at some
> point dragging that folder and dropping it onto the "checkout"
> symbol within the web page.  No session required.
> 
> I wonder how far you could take "file upload" in this direction?  
And/or
> some Javascript to provide the local containers ...  Hmm.

Personally, I'd advise against forcing the client to maintain state 
and particularly potentially sensitive data like a shopping. It 
restricts what your client can do and it just invites all sorts of 
security breaches.

The way I maintain session in some apps is simply to expose 
a /sessions/ resource. The session of each individual user is stored 
below this, usually just by appending a user-id to the /sessions/ 
resource -- eg /sessions/3423423423/ would be my session. This simple 
architecture has a lot of benefits. Particularly, I can create a 
session on one computer in the red building and then walk over to my 
lab and retrieve my previous session.

The real problem is not necessarily maintaining session, but 
identifying new users and returning users. There really is no clean 
way to do this and it's a big drawback of HTTP. The solutions are:

1) Use HTTP digest authentication. If the user doesn't authenticate 
then they become the generic 'Anonymous User' and no session state 
will be maintained for them.

2) Use cookies. Simple and cheap, and it doesn't require you to 
create accounts for each user, especially for anonymous users. For 
example, it's often the case that you want to maintain state for a 
client without forcing that client to login. Cookies let you do this. 
Cookies do complicate your client code since developers creating non-
browser apps must understand cookies.

3) Create a session ID and embed it in the URI. This is very simple 
but it has a lot of problems. Users can no longer bookmark URLs and 
every URL exposed to the user must be 'sessionified'.

My suggestion:

Just use cookies. I know Fielding says cookies are non-restful, but 
there's really no better way. It's what they're there for.

Note that just because a user has a cookie should not grant that user 
extra permissions. Cookies aren't an authentication mechanism. If a 
user needs to perform some security-sensitive mechansim then you 
should make them login using digest authentication. The great thing 
about http digest authentication (whether Fielding admits it or not) 
is that it's essentially a standardized cookie/session-id. The user 
is required to authenticate themself with every request so you get 
all the benefits of cookie plus security.

- inthedarkplace







-----------------------------------------------------------------------------------
Post ID:2240
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-27 00:38:28
Subject:Re: [rest-discuss] Beating my head against the "session management" wall
Message:

Ooh, cool, hadn't seen that.  But I was thinking of an Internet-Draft.
I'd guess that this table was constructed as part of the same task that
produced the I-D.

MB

On Mon, Aug 26, 2002 at 02:03:59PM -0700, Mark Nottingham wrote:
> Do you mean:
>   http://www.mnot.net/papers/capabilities.pdf
> 
> Would be interesting to update that now...

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2241
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-27 01:12:56
Subject:Shoulda been the "authentication" wall (was Re: Beating my head against the "session management" wall)
Message:

----- Original Message -----
From: "Mark Nottingham" <mnot@...>


> My pop culture references weren't meant to answer your questions; I was
> hoping/assuming that someone more REST enlightened than I would do so.

*whew* While I know I am not understanding this concept as well as I want, I
was worried that those answers were either zen statements meant to shock me
into enlightenment or that the answer was so obvious that nothing more
needed to be said.  :)

> Since noone has, here are my thoughts;
>
> HTTP authentication clearly involves keeping state on the client; as such,
> whenever I try to resource model an application, this is the main means of
> identifying a client in order to tailor information for it. As you
> surmise, cookies are often used in place of HTTP authentication because
> they can be persistent across invocations of the browser (although modern
> browsers address this with a 'password store' mechanism), they can be
> deleted, and because there is more control over the UI. Authentication,
> OTOH, has advantages in that the state can be incorporated into the URI
> (cookies can't), and the mechanism is standardized, allowing for machines
> to present credentials (this could be possible with cookies, but
> practically, it's impossible; they'd have to understand your specific
> authentication scheme).

I'm not sure what you mean by "Authentication [...] can be incorporated into
the URI".  Otherwise, I agree with everything else you said.

> Doing it in the request body (POST) is clearly not RESTful, and doing it
> correctly with the URI query is tricky at best, IMHO.

I absolutely agree.  As a result, I am not even considering these as
options.

> So, when choosing between these mechanisms, I prefer HTTP authentication
> wherever possible; if you investigate modern browsers, you should find
> that Digest has been implemented correctly (I use it opften with IE6,
> Mozilla and Amaya; IIRC it also works on Opera).

Well, this is the first time I have seen mention that IE6 is compatible (IE5
wasn't, appearently).  This is certainly good news.  And yes, Opera does
properly support digest authentication.

> All of this notwithstanding, and most importantly, if you approach your
> application from a model of 'sessions' (which most environments encourage
> you to do), you'll find it very hard to keep it RESTful. Model your
> application as resources which expose state as representations, and the
> issue of sessions will (hopefully) dissolve into the background, for the
> most part.

That is what I have been trying to do.  In fact, part of the purpose of this
project is to gain better understanding and experience with the REST model.
At first, I only focused on the resource model, ignoring authentication
issues.  This allowed me to construct what I believe to be a very clean and
simple model.  This model works quite well when was issuing unauthenticated
GET requests.  However, I then got to the part where people had the ability
to modify and create (well, request creation of) new resources via POST.
For these operations, it is necessary to be authenticated.  Then I also came
across a part of the model that required authenticated GET access.  As I
started workding this part out, all that came to mind was the use of
sessions.  I admit that this was an "easy" conclusion partly because I have
written several other web applications in the past that were heavily
dependent on the session-oriented model.

Then I started learning more abouth HTTP authentication.  I knew that basic
authentication had the fundamental flaw that the user/pwd were submitted
with every request.  This did not seem a very good solution to me
considering the security implications.  I then started learning about digest
authentication, but this too seemed to suffer some drawbacks:

* inconsistant implemenation between MS and non-MS browsers:  As I know now,
this is no longer an issue since now IE6 seems to be compliant.
* it only really added protection to the password: That's fine, really.  The
password was the important part, since their e-mail addresses were going to
be their userId.
* someone could still potentially use replay attacks and man-in-the-middle
attacks (can't remember if there were others):  I know that you could
frequently change the nonce to limit the attacks, but at the cost of
additional server-side application overhead.  I am beginning to think this
is worth the security.  If I needed complete privacy, I would just use SSL
on top of it all.
* and an extreme lack of code demonstrating its use.  This isn't really a
problem with the method.  It's really more of a problem because it's harder
for me to figure out how to properly implement it.

> Architecting applications that don't require client state brings many
> benefits. Witness search engines, translation services, annotation
> services, shared caching, 'this page has changed' bots, etc., etc.

I absolutely agree.

> Requiring client state reduces the effectiveness or even eliminates these
> benefits, and locks your users into exactly one way of seeing the data:
> the way that you lead them through it. While this is attractive to the
> application developer, it isn't to users, and hence ultimately reduces the
> potential benefit of making the application part of the Web.

Again, I agree.  Which is why I want to get this authentication thing right
the first time...


Now that I know that digest authentication works properly in IE6, this is
looking like a much, much more attractive solution than cookies.  Now all I
need to do is find some code to implement it properly in PHP.  Any
suggestions?  I'll take anything I can get at this point.  Resources of this
type for PHP seem to be non-existent.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2242
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-27 01:35:06
Subject:client-side state management (was Re: Beating my head against the "session management" wall)
Message:

(or should this be going to rest-explore?)

----- Original Message -----
From: "Mark Baker" <distobj@...>

>
> The main problem is that the current generation of browsers don't
> provide sufficient functionality to allow the client-side to maintain
> the necessary state required for some operations.  We've talked about
> shopping baskets here before; their state should ideally be maintained
> at the client, not the server.  But currently there is no means for
> handling this on the client.

Why not handle the shopping cart as it's own resource on the server?  In
fact, if done correctly, I could even see having an HTTP server that was
dedicated and optimized to doing nothing but maintaining one or more site's
"shopping cart resource".  I'm not sure how this would work exactly, but I
can vaguely see it working.

As for the client program being capable of maintaining state, I can see
doing that sort of thing now (with a bit of client-side programming, mint
you).  For instance, If you were at Amazon, each of the items you view is
represented by an identifier (it's URL).  Suppose you could right-click on
the page and select the "add to amazon.com cart".  This would cause the
current URL you were at to be stored locally in a "cart" that was specific
to amazon (though I suppose it could be more generic too).  Now, suppose you
have found everything you wanted to buy.  You go up to your brower's menu
(or taskbar or whatever) and bring up the amazon.com shopping cart ( which
basically contains nothing but URLs).  You then click on the "buy" button.
This prompts your browser to submit (via POST) all of the URLs to an
amazon.com location (not sure how that would be know, but let's assume it
is) and amazon would now create the check-out resource that contains the
items you are buying... then it's business as usual.

Now, I know that it would be possible to add this functionality to IE6.
Obviously, it would also require the amazon.com's of the world to provide
their part of the functionality.  But I think it would be possible.
Further, it would be possible to merge this concept with the one above
(dedicated "shopping cart" server), if wanted.  This would potentially allow
someone to access their shopping cart from any browser later on, as well as
some other interesting benefits I can think of (such as the ability to share
shopping carts with friends regardless of where you shop at).

> But you could imagine browsing through a web site, dragging off
> products you want and dropping them in a local folder, then at some
> point dragging that folder and dropping it onto the "checkout"
> symbol within the web page.  No session required.

Oh yeah.  That's what I was saying too.  :)  Shoulda read the whole post
first...

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2243
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-27 01:51:50
Subject:Re: [rest-discuss] Beating my head against the "session management" wall
Message:

----- Original Message -----
From: "S. Mike Dierken" <mdierken@...>
>
> Let's start at the top and describe what problems session management
solves
> for you.
> With that, we can stay concrete in our suggestions on how to maintain a
> RESTful design.

>From the more informative reply from Mark Nottingham, I am more confident in
using digest authentication (assuming I can implement it in PHP).  I have
some questions about how it will work exactly, but I hope to find the
answers as I go...

> From my experience, session management has been a mechanism to achieve
> higher performance through servers-side caching of some data.
> What does 'session management' mean to you?

To me, session management is a two-part device:
1) Persisting authentication (so that a user doesn't have to type in their
password on each request)
2) Persisting data attached to the user for a limited period of time.

In my case, I am really only concerned about the first half.  I have worked
to ensure (so far) that the second half is not a part of my application
model.  Hopefully, it will stay that way.  :)

---
Seairth Jacobs
seairth@...


>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>







-----------------------------------------------------------------------------------
Post ID:2244
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-27 14:47:12
Subject:RE: HTTP and safety
Message:


> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Monday, August 26, 2002 1:03 PM
> To: Mathews, Walden
> Cc: rest-discuss@yahoogroups.com
> Subject: HTTP and safety
> 
> 
> We're creeping into rest-explore territory here.

How so?  My aim is to understand the claims that tunneling RPC
traffic through HTTP POST creates a security problem that doesn't
already exist with compliant uses of POST.  A POST body will
contain a representation of something that is loosely characterized
as 'subordinate' to the referenced resource, which will invoke
some processing of some kind.  That representation may be the
*record* of some desired action, and so will be interpreted on
the server as the action.  The meaning of this exchange will
not be available to a firewall or other intermediary except at
the most general level.  And what it "means" there can be
expressed approximately as "some side effect may occur, but
don't bet on it".

Above I've described what I understand to be RESTful use of
the POST method.  Please tell me how that differs in the security
dimension from the dreaded 'tunneled RPC'.

Note that I'm interested only in the security dimension right
now.  I understand that tunneling GETs through POST diminishes
the capability of the layered system, and I suppose tunneling
DELETE or PUT may diminish something as well.  But in none of these
cases is security diminished.  At least I can't think of a 
reasonable admin policy toward POST that would result in such
a diminishment.

That's why, for the time being, I regard claims about diminished
security to be exaggerations based on overgeneralization.  What
I need to see are some specific cases of firewall configuration
and method abuse to better understand.

> I wouldn't say that it's underspecified at all.  Why do you believe it
> is?

Having just read that part of the spec again, I don't, actually.  But
that pushes me to a different conclusion: that the semantics of POST
are being misrepresented on this mail list to include careful craftings
of remote procedure calls in which the instructions have 'representations'
that pass the 'representational state' test (which is a null test),
and so appear to be 'state transfers' but are not.

I'll give an example

	Request:
	PUT /some/number
	2

	Response:
	201 Created

	Request:
	GET /some/number

	Response:
	200 OK
	2

	Request:
	POST /some/number
	'square'

	Response:
	204 No Content

	Request:
	GET /some/number

	Response:
	200 OK
	4

This example achieves the squaring of 2 in a way that is quite
different from the more obvious interpretations of "state
transfer".  Can we please discuss whether the above is "RESTful"
and if not, what would it take to make it so?  I believe that
by tweaking the example above, we can arrive at one which
illuminates the distinction I see between rest-discuss and
RFC 2616 on the intended semantics of POST.


The specification of POST in RFC 2616 relies on the term 'subordinate'
to characterize the relationship between the POST entity and the
referenced resource.  It then avoids comprehensive definition of
'subordinate' in favor of an enumeration.  It leaves us to infer that
the 'subordinate' relation is the 'part->composite' relation, because
all the enumerated examples are such, but I'd like to hear others'
interpretations on this.  

Then there's the circumstantial stuff, like the fact that otherwise
intelligent human beings typically stumble all over the meanings of
the HTTP methods (and it's all because of POST) on first encounter,
the fact that supplementary models of "resource type" have to be developed
to delineate the possible POST behaviors, the appearance of the word
"intent"
to describe the fleshing out of application semantics for POST, which
seems unnecessary for all of the other HTTP methods, and a
comment by someone who signs his emails with your signature to the
effect that "POST is the catch-all mutator method".

What I think is happening here is that we're still feeling the
growing pains of HTTP/REST as it tries to be more than a document
maintenance pattern and less than a 'protocol prostitute' (sorry,
the alliteration made me do that!).

This is super-long, so thanks in advance to all who made it to the end!

Walden

 






-----------------------------------------------------------------------------------
Post ID:2245
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-08-27 15:12:11
Subject:Re: [rest-discuss] RE: HTTP and safety
Message:

----- Original Message ----- 
From: "Mathews, Walden" <waldenm@...>
To: "'Mark Baker'" <distobj@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Tuesday, August 27, 2002 10:47 AM
Subject: [rest-discuss] RE: HTTP and safety




> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Monday, August 26, 2002 1:03 PM
> To: Mathews, Walden
> Cc: rest-discuss@yahoogroups.com
> Subject: HTTP and safety
> 
> 
> We're creeping into rest-explore territory here.

How so?  My aim is to understand the claims that tunneling RPC
traffic through HTTP POST creates a security problem that doesn't
already exist with compliant uses of POST.  A POST body will
contain a representation of something that is loosely characterized
as 'subordinate' to the referenced resource, which will invoke
some processing of some kind.  That representation may be the
*record* of some desired action, and so will be interpreted on
the server as the action.  The meaning of this exchange will
not be available to a firewall or other intermediary except at
the most general level.  And what it "means" there can be
expressed approximately as "some side effect may occur, but
don't bet on it".

Above I've described what I understand to be RESTful use of
the POST method.  Please tell me how that differs in the security
dimension from the dreaded 'tunneled RPC'.

Note that I'm interested only in the security dimension right
now.  I understand that tunneling GETs through POST diminishes
the capability of the layered system, and I suppose tunneling
DELETE or PUT may diminish something as well.  But in none of these
cases is security diminished.  At least I can't think of a 
reasonable admin policy toward POST that would result in such
a diminishment.

That's why, for the time being, I regard claims about diminished
security to be exaggerations based on overgeneralization.  What
I need to see are some specific cases of firewall configuration
and method abuse to better understand.

> I wouldn't say that it's underspecified at all.  Why do you believe it
> is?


Request:
POST /some/number
'square'

Response:
204 No Content

Request:
GET /some/number

Response:
200 OK
4

This example achieves the squaring of 2 in a way that is quite
different from the more obvious interpretations of "state
transfer".  Can we please discuss whether the above is "RESTful"
and if not, what would it take to make it so?  I believe that
by tweaking the example above, we can arrive at one which
illuminates the distinction I see between rest-discuss and
RFC 2616 on the intended semantics of POST.


The specification of POST in RFC 2616 relies on the term 'subordinate'
to characterize the relationship between the POST entity and the
referenced resource.  It then avoids comprehensive definition of
'subordinate' in favor of an enumeration.  It leaves us to infer that
the 'subordinate' relation is the 'part->composite' relation, because
all the enumerated examples are such, but I'd like to hear others'
interpretations on this.  

Then there's the circumstantial stuff, like the fact that otherwise
intelligent human beings typically stumble all over the meanings of
the HTTP methods (and it's all because of POST) on first encounter,
the fact that supplementary models of "resource type" have to be developed
to delineate the possible POST behaviors, the appearance of the word
"intent"
to describe the fleshing out of application semantics for POST, which
seems unnecessary for all of the other HTTP methods, and a
comment by someone who signs his emails with your signature to the
effect that "POST is the catch-all mutator method".

What I think is happening here is that we're still feeling the
growing pains of HTTP/REST as it tries to be more than a document
maintenance pattern and less than a 'protocol prostitute' (sorry,
the alliteration made me do that!).

This is super-long, so thanks in advance to all who made it to the end!

Walden

 


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 









-----------------------------------------------------------------------------------
Post ID:2246
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-08-27 15:25:08
Subject:Re: [rest-discuss] RE: HTTP and safety
Message:

[I apologize for the previous null-reply!]


>> We're creeping into rest-explore territory here.

> That's why, for the time being, I regard claims about diminished
> security to be exaggerations based on overgeneralization.  What
> I need to see are some specific cases of firewall configuration
> and method abuse to better understand.

I've been suspicious of this myself.  I've heard two different issues
with regards to RPC vs. REST security issues:

1.  That a firewall can be configured to allow only the HTTP methods
that the administrator considers safe for a user (e.g., no POSTs from
certain users etc.)

2.  RPC is more prone to issue like buffer-overrun problems that would
require a more diligent security analysis.  But it seems to me that
similar problems could potentially exist with POSTed data no matter
what style is used.

>> I wouldn't say that it's underspecified at all.  Why do you believe it
>> is?

> Having just read that part of the spec again, I don't, actually.  But
> that pushes me to a different conclusion: that the semantics of POST
> are being misrepresented on this mail list to include careful craftings
> of remote procedure calls in which the instructions have 'representations'
> that pass the 'representational state' test (which is a null test),
> and so appear to be 'state transfers' but are not.

> I'll give an example
>
> Request:
> PUT /some/number
> 2
>
> Response:
> 201 Created
>
> Request:
> GET /some/number
>
> Response:
> 200 OK
> 2

As for the squaring action, one possibility could be:

Request:
POST /squarer
/some/number

Response:
200 OK
4

I think it would be stretching the intended meaning of 'subordinate' to claim
that
the name of an action was a subordinate resource in the original POST.








-----------------------------------------------------------------------------------
Post ID:2247
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-27 17:22:33
Subject:RE: [rest-discuss] RE: HTTP and safety
Message:

> As for the squaring action, one possibility could be:
> 
> Request:
> POST /squarer
> /some/number
> 
> Response:
> 200 OK
> 4
> 
> I think it would be stretching the intended meaning of 
> 'subordinate' to claim
> that
> the name of an action was a subordinate resource in the original POST.
> 

I'm not so much looking for a way to square numbers as I am trying
to illustrate a subtlty in the specification and its interpretations.
I'd say your example suffers from the same weakness because '/some/number'
is also not logically subordinate in the composite sense to a calculator,
('/squarer') while /squarer/complex (a squarer for complex numbers) might
be, but note the totally different meaning of POSTing that.

What I'd like to happen now is instead of folks proposing other
possibly RESTful ways to do integer squaring, have them tell me precicely
what is unRESTful in my example so I can evolve it to that point
of enlightenment.  Or tell me that the example is already RESTful.

Thanks,
Walden






-----------------------------------------------------------------------------------
Post ID:2248
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-08-27 18:16:10
Subject:Re: [rest-discuss] RE: HTTP and safety
Message:

> I'm not so much looking for a way to square numbers as I am trying
> to illustrate a subtlty in the specification and its interpretations.

Sorry, I didn't mean to imply that you were only looking for such a thing...

> I'd say your example suffers from the same weakness because '/some/number'
> is also not logically subordinate in the composite sense to a calculator,

I don't think the subordinate should be thought of strictly in the
compositional
sense.  While RFC2616 does explicitly mention such examples as "the posted
entity
is subordinate to that URI in the same way that a file is subordinate to a
directory
containing it," it also gives the example of using POST for "Providing a block
of data,
such as the result of submitting a form, to a data-handling process." Not all
POSTs will
result in another resource being created, even implicitly.

So I think my example is a better way of doing things since you are POSTing
the state
of a subordinate resource (or a reference to the resource in that particular
case.)

> ('/squarer') while /squarer/complex (a squarer for complex numbers) might
> be, but note the totally different meaning of POSTing that.
> What I'd like to happen now is instead of folks proposing other
> possibly RESTful ways to do integer squaring, have them tell me precicely
> what is unRESTful in my example so I can evolve it to that point
> of enlightenment.

In your original example, you are not posting a representation of a resource,
only
a name of an action.








-----------------------------------------------------------------------------------
Post ID:2249
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-27 18:27:02
Subject:Re: HTTP and safety
Message:

On Tue, Aug 27, 2002 at 10:47:12AM -0400, Mathews, Walden wrote:
> > We're creeping into rest-explore territory here.
> 
> How so?

Just that it's a bit of an advanced topic that REST newbies may not be
interested in.  It's not a bad thing. 8-)

>  My aim is to understand the claims that tunneling RPC
> traffic through HTTP POST creates a security problem that doesn't
> already exist with compliant uses of POST.  A POST body will
> contain a representation of something that is loosely characterized
> as 'subordinate' to the referenced resource, which will invoke
> some processing of some kind.  That representation may be the
> *record* of some desired action, and so will be interpreted on
> the server as the action.  The meaning of this exchange will
> not be available to a firewall or other intermediary except at
> the most general level.  And what it "means" there can be
> expressed approximately as "some side effect may occur, but
> don't bet on it".

Pretty much.

> Above I've described what I understand to be RESTful use of
> the POST method.  Please tell me how that differs in the security
> dimension from the dreaded 'tunneled RPC'.

The key is to focus on the wire.  Think about telnetting to port 80.
At that very instant, a contract is in effect, and that contract and
any messages conforming to it are visibile to all participants; you,
any firewall you might be going through, the server, and any surrogates
it might be using.

If, using that contract, you could trick the system into providing
you a richer contract, i.e. guaranteeing you things that were not
guaranteed at time 0, and do this in a way that is not visible to
intermediaries (i.e. not using HTTP's extension features), then that
is a security problem (as well as a problem to other aspects of the
system that require visibility, e.g. caching).  Designing interfaces
that cannot break themselves is *hard*.  You're working against
entropy.

"Tunneled RPC"'s raison d'etre is to build arbitrary contracts over
existing ones.  So in addition to nullifying any safety in the
existing contract, cheap method-creation is an easy way to guarantee
that most contracts created with it will in turn be unsafe.

> Note that I'm interested only in the security dimension right
> now.  I understand that tunneling GETs through POST diminishes
> the capability of the layered system, and I suppose tunneling
> DELETE or PUT may diminish something as well.  But in none of these
> cases is security diminished.  At least I can't think of a 
> reasonable admin policy toward POST that would result in such
> a diminishment.

If GET - and only GET - were tunneled through POST, I agree about
security probably not being diminished, because the augmented contract
is no more capable than the existing one (though I'd have to verify
that there wasn't any POST-specific race conditions, etc.. there).  But
an intermediary wouldn't know that, so there's still a management issue
that the firewall admins wouldn't be comfortable with, I'm sure.

> That's why, for the time being, I regard claims about diminished
> security to be exaggerations based on overgeneralization.  What
> I need to see are some specific cases of firewall configuration
> and method abuse to better understand.
> 
> > I wouldn't say that it's underspecified at all.  Why do you believe it
> > is?
> 
> Having just read that part of the spec again, I don't, actually.  But
> that pushes me to a different conclusion: that the semantics of POST
> are being misrepresented on this mail list to include careful craftings
> of remote procedure calls in which the instructions have 'representations'
> that pass the 'representational state' test (which is a null test),
> and so appear to be 'state transfers' but are not.
> 
> I'll give an example
> 
> 	Request:
> 	PUT /some/number
> 	2
> 
> 	Response:
> 	201 Created
> 
> 	Request:
> 	GET /some/number
> 
> 	Response:
> 	200 OK
> 	2
> 
> 	Request:
> 	POST /some/number
> 	'square'
> 
> 	Response:
> 	204 No Content
> 
> 	Request:
> 	GET /some/number
> 
> 	Response:
> 	200 OK
> 	4
> 
> This example achieves the squaring of 2 in a way that is quite
> different from the more obvious interpretations of "state
> transfer".  Can we please discuss whether the above is "RESTful"
> and if not, what would it take to make it so?

It's not RESTful, because 'square' is an instruction to be followed, not
data to be submitted.  In addition, this is a poor example because the
client *expects* that squaring is done, which kind of begs the question
as to why it can't do it itself and then PUT the result ... 8-O

>  I believe that
> by tweaking the example above, we can arrive at one which
> illuminates the distinction I see between rest-discuss and
> RFC 2616 on the intended semantics of POST.
> 
> 
> The specification of POST in RFC 2616 relies on the term 'subordinate'
> to characterize the relationship between the POST entity and the
> referenced resource.  It then avoids comprehensive definition of
> 'subordinate' in favor of an enumeration.  It leaves us to infer that
> the 'subordinate' relation is the 'part->composite' relation, because
> all the enumerated examples are such, but I'd like to hear others'
> interpretations on this.  

I think that "Part->Composite" is a tad more specific than HTTP
suggests, but I might be picking nits.  It would seem to exclude the
posting of data to a form processor, for example, since the
composite relationship only exists for the duration of the processing.
It doesn't persist like a StatePreservingContainer.  Pretty close
though, but I prefer "accept as a subordinate" for describing the most
generic form of containment as present in my RestRDF "Container".

> Then there's the circumstantial stuff, like the fact that otherwise
> intelligent human beings typically stumble all over the meanings of
> the HTTP methods (and it's all because of POST) on first encounter,
> the fact that supplementary models of "resource type" have to be developed
> to delineate the possible POST behaviors, the appearance of the word
> "intent"
> to describe the fleshing out of application semantics for POST, which
> seems unnecessary for all of the other HTTP methods, and a
> comment by someone who signs his emails with your signature to the
> effect that "POST is the catch-all mutator method".

8-)

> What I think is happening here is that we're still feeling the
> growing pains of HTTP/REST as it tries to be more than a document
> maintenance pattern and less than a 'protocol prostitute' (sorry,
> the alliteration made me do that!).

No, that's a really good way of explaining the tension, but HTTP/REST
*is* already a fixed thing (at least at any given point in time).  It's
only our view of it that we're adjusting by talking about it.

> This is super-long, so thanks in advance to all who made it to the end!

Phew!

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2250
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-27 19:50:35
Subject:Re: [rest-discuss] client-side state management (was Re: Beating my head against the "session management" wall)
Message:

On Mon, Aug 26, 2002 at 09:35:06PM -0400, Seairth Jacobs wrote:
> Why not handle the shopping cart as it's own resource on the server?  In

How would I transfer representations of what I'm purchasing to it?

> fact, if done correctly, I could even see having an HTTP server that was
> dedicated and optimized to doing nothing but maintaining one or more site's
> "shopping cart resource".  I'm not sure how this would work exactly, but I
> can vaguely see it working.

You'd need some session info to do that.

> As for the client program being capable of maintaining state, I can see
> doing that sort of thing now (with a bit of client-side programming, mint
> you).  For instance, If you were at Amazon, each of the items you view is
> represented by an identifier (it's URL).  Suppose you could right-click on
> the page and select the "add to amazon.com cart".  This would cause the
> current URL you were at to be stored locally in a "cart" that was specific
> to amazon (though I suppose it could be more generic too).

The thing about keeping the URI around, rather than the data, is that
what's "behind" the URI might change.  e.g. the model might be upgraded
between the time you decide you want it just the old model), and the
time you checkout.  You base your purchasing decision on the *data* not
the URI.  So you should keep hold of that.

>  Now, suppose you
> have found everything you wanted to buy.  You go up to your brower's menu
> (or taskbar or whatever) and bring up the amazon.com shopping cart ( which
> basically contains nothing but URLs).  You then click on the "buy" button.
> This prompts your browser to submit (via POST) all of the URLs to an
> amazon.com location (not sure how that would be know, but let's assume it
> is) and amazon would now create the check-out resource that contains the
> items you are buying... then it's business as usual.

Pretty close, except for s/URL/representation

> Now, I know that it would be possible to add this functionality to IE6.
> Obviously, it would also require the amazon.com's of the world to provide
> their part of the functionality.  But I think it would be possible.
> Further, it would be possible to merge this concept with the one above
> (dedicated "shopping cart" server), if wanted.  This would potentially allow
> someone to access their shopping cart from any browser later on, as well as
> some other interesting benefits I can think of (such as the ability to share
> shopping carts with friends regardless of where you shop at).

You can still save your shopping cart either way - just drag and drop on
the "hold cart" (or whatever) button in the page.

> > But you could imagine browsing through a web site, dragging off
> > products you want and dropping them in a local folder, then at some
> > point dragging that folder and dropping it onto the "checkout"
> > symbol within the web page.  No session required.
> 
> Oh yeah.  That's what I was saying too.  :)  Shoulda read the whole post
> first...

Oops, me too. 8-)

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2251
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-27 20:46:39
Subject:RE: HTTP and safety
Message:

> > Above I've described what I understand to be RESTful use of
> > the POST method.  Please tell me how that differs in the security
> > dimension from the dreaded 'tunneled RPC'.
> 
> The key is to focus on the wire.  Think about telnetting to port 80.
> At that very instant, a contract is in effect, and that contract and
> any messages conforming to it are visibile to all participants; you,
> any firewall you might be going through, the server, and any 
> surrogates
> it might be using.
> 
> If, using that contract, you could trick the system into providing
> you a richer contract, i.e. guaranteeing you things that were not
> guaranteed at time 0, and do this in a way that is not visible to
> intermediaries (i.e. not using HTTP's extension features), then that
> is a security problem (as well as a problem to other aspects of the
> system that require visibility, e.g. caching).  Designing interfaces
> that cannot break themselves is *hard*.  You're working against
> entropy.
> 
> "Tunneled RPC"'s raison d'etre is to build arbitrary contracts over
> existing ones.  So in addition to nullifying any safety in the
> existing contract, cheap method-creation is an easy way to guarantee
> that most contracts created with it will in turn be unsafe.

As I see it, there are two problems with these arguments, and both
stem from their generality, and would be cleared up by a real life
story, if anyone can contribute one.

The first problem is distinguishing this breakdown in "safety" from
the common business case in which a sales pitch lures you into making
a bad purchase.  On whom does the responsibility for avoiding that
lie?

The second problem is distinguishing this breakdown in "safety" from
the case in which you use HTTP POST to send an arbitrary "block of data ...
to a handling process".  Or should we say a "block of arguments to a
remote handling procedure"?

[example elided for brevity]

> > This example achieves the squaring of 2 in a way that is quite
> > different from the more obvious interpretations of "state
> > transfer".  Can we please discuss whether the above is "RESTful"
> > and if not, what would it take to make it so?
> 
> It's not RESTful, because 'square' is an instruction to be 
> followed, not
> data to be submitted.  In addition, this is a poor example because the
> client *expects* that squaring is done, which kind of begs 
> the question
> as to why it can't do it itself and then PUT the result ... 8-O

I'm glad to hear it's not RESTful.  That's a start.  (The reason
the client doesn't square is because it doesn't know how to, kind of
like why you don't do your own dental work, assuming you don't, but
none of that is relevant now.)

Okay, can you make it restful by changing the way you think about
it?  For instance, can we call it a *record* of an action, or perhaps
a short 'action document', or a 'delta representation' of future
resource state, or any other 'trick' that gets us beyond this
hitch?  What if we argue that it came straight from an HTTP form
submission?

Please anticipate where I'm going with the above and help me find
the boundary.

> I think that "Part->Composite" is a tad more specific than HTTP
> suggests, but I might be picking nits.  It would seem to exclude the
> posting of data to a form processor, for example, since the
> composite relationship only exists for the duration of the processing.
> It doesn't persist like a StatePreservingContainer.  Pretty close
> though, but I prefer "accept as a subordinate" for describing the most
> generic form of containment as present in my RestRDF "Container".

Well, I went back and read that section yet again (whew!), and while it
does list as a goal the processing of form data, all the examples offered
to clarify 'subordinate' are clearly container (part/assembly) examples.
I'd say it looks inconsistent, with the 'forms' stuff the odd-man-out.

> No, that's a really good way of explaining the tension, but HTTP/REST
> *is* already a fixed thing (at least at any given point in 
> time).  It's
> only our view of it that we're adjusting by talking about it.

I think views can only adjust so far.  To me, POST is broken like
a too-small pelvis trying to give birth to a cranial giant.  (Ouch. 
I've got to stop ending these messages so vividly.)

In gratitude,
Walden







-----------------------------------------------------------------------------------
Post ID:2252
Sender:Phil Eskelin <philip.eskelin@...>
Post Date/Time:2002-08-27 22:34:43
Subject:RE: [rest-discuss] RE: HTTP and safety
Message:

[snip]
> > > This example achieves the squaring of 2 in a way that is quite
> > > different from the more obvious interpretations of "state
> > > transfer".  Can we please discuss whether the above is "RESTful"
> > > and if not, what would it take to make it so?
> > 
> > It's not RESTful, because 'square' is an instruction to be 
> > followed, not data to be submitted.  In addition, this is a poor
> > example because the client *expects* that squaring is done, which
> > kind of begs the question as to why it can't do it itself and then
> > PUT the result ... 8-O
> 
> I'm glad to hear it's not RESTful.  That's a start.  (The reason
> the client doesn't square is because it doesn't know how to, kind of
> like why you don't do your own dental work, assuming you don't, but
> none of that is relevant now.)
> 
> Okay, can you make it restful by changing the way you think about
> it?  For instance, can we call it a *record* of an action, or perhaps
> a short 'action document', or a 'delta representation' of future
> resource state, or any other 'trick' that gets us beyond this
> hitch?  What if we argue that it came straight from an HTTP form
> submission?
> 
> Please anticipate where I'm going with the above and help me find
> the boundary.
[snip]

Ahah...I was wondering if I was missing a very subtle semantic point in your
example, or if I was correct in thinking that you were putting a remote
procedure call into a POST request.  It looks like the later is true,
because no matter how you slice it, you're effectively doing a square(x, y)
across a network, which is good for SOAP-RPC, but goes against the RESTful
style.

What *would* be more RESTful?  An abstract approach might be to transfer a
representation in a POST request that sends a 201 (Created) response
including a 'Location' response-header field that specifies the
subordinate's location.  The recent shopping basket (in the client state
posts) example is a good place to start.

In other words, once you're ready to check out, you might POST the basket
representation to an order taking resource.  This might cause the server to
create a subordinate of a container resource, and hand you a URI in the 201
response that you can then use to do subsequent GET/PUT/POST/DELETE
requests.

Philip

________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.






-----------------------------------------------------------------------------------
Post ID:2253
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-28 02:09:52
Subject:Re: HTTP and safety
Message:

On Tue, Aug 27, 2002 at 04:46:39PM -0400, Mathews, Walden wrote:
> As I see it, there are two problems with these arguments, and both
> stem from their generality, and would be cleared up by a real life
> story, if anyone can contribute one.
> 
> The first problem is distinguishing this breakdown in "safety" from
> the common business case in which a sales pitch lures you into making
> a bad purchase.  On whom does the responsibility for avoiding that
> lie?

That's protecting the client.  I'm talking about protecting the
server.

> The second problem is distinguishing this breakdown in "safety" from
> the case in which you use HTTP POST to send an arbitrary "block of data ...
> to a handling process".  Or should we say a "block of arguments to a
> remote handling procedure"?

Hmm.  I'm not sure that there's any distinguishing to be done in that
case.

> [example elided for brevity]
> 
> > > This example achieves the squaring of 2 in a way that is quite
> > > different from the more obvious interpretations of "state
> > > transfer".  Can we please discuss whether the above is "RESTful"
> > > and if not, what would it take to make it so?
> > 
> > It's not RESTful, because 'square' is an instruction to be 
> > followed, not
> > data to be submitted.  In addition, this is a poor example because the
> > client *expects* that squaring is done, which kind of begs 
> > the question
> > as to why it can't do it itself and then PUT the result ... 8-O
> 
> I'm glad to hear it's not RESTful.  That's a start.  (The reason
> the client doesn't square is because it doesn't know how to, kind of
> like why you don't do your own dental work, assuming you don't, but
> none of that is relevant now.)
> 
> Okay, can you make it restful by changing the way you think about
> it?  For instance, can we call it a *record* of an action, or perhaps
> a short 'action document', or a 'delta representation' of future
> resource state, or any other 'trick' that gets us beyond this
> hitch?  What if we argue that it came straight from an HTTP form
> submission?
> 
> Please anticipate where I'm going with the above and help me find
> the boundary.

I'm not sure where you're going with it, sorry.  But with a clean slate,
I'd implement this using GET to return the squared value to the client,
i.e.

GET http://me.example.org/first-number

which returns something like;

5 <a rel="http://math.example.org/squared"
   href="http://me.example.org/first-number?square=yes>squared</a>

such that following the link identifies that you're traversing from a
number to its square.  Then I'd do a GET on that other URI, and then
PUT the value back to /first-number - I think that's what your example
was doing, I'm too lazy to go back and check. 8-)

> > I think that "Part->Composite" is a tad more specific than HTTP
> > suggests, but I might be picking nits.  It would seem to exclude the
> > posting of data to a form processor, for example, since the
> > composite relationship only exists for the duration of the processing.
> > It doesn't persist like a StatePreservingContainer.  Pretty close
> > though, but I prefer "accept as a subordinate" for describing the most
> > generic form of containment as present in my RestRDF "Container".
> 
> Well, I went back and read that section yet again (whew!), and while it
> does list as a goal the processing of form data, all the examples offered
> to clarify 'subordinate' are clearly container (part/assembly) examples.
> I'd say it looks inconsistent, with the 'forms' stuff the odd-man-out.

Perhaps, but that "block of data" blurb is the most oft referenced
part of the definition of POST that people use to defend tunneling,
ala;

http://www.ics.uci.edu/pub/ietf/http/draft-debry-http-usepost-00.txt

So I think it's useful that the examples are part/assembly, even if
the IPP guys chose to ignore them. 8-)

> I think views can only adjust so far.  To me, POST is broken like
> a too-small pelvis trying to give birth to a cranial giant.  (Ouch. 
> I've got to stop ending these messages so vividly.)

My eyes, me eyes! 8-)

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2254
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-28 02:15:01
Subject:more on authentication
Message:

So as the kids were running around on the playground this evening, a thought
occurred to me concerning the recent discussions on state management and
user authentication.  To start, suppose the following URL:

example.com/doc.php/12345

This is a simple URL that returns a representation of a resource (in this
case a document with a public id of "12345").  Now, as I have mentioned,
this resource can be viewed either anonymously (by anyone) or after being
authenticated.  When it becomes necessary to persist the authentication, we
all agreed (I think) that http authentication was the way to go.  We also
agree (I think) that the following method was a "bad thing",
RESTfully-speaking:

example.com/doc.php/12345?sessionid=67890

However, it occurred to me that the problem with the above URL wasn't the
use of a query string, but what was *in* the query string.  Suppose instead
that I used the following URL once someone has been authenticated:

example.com/doc.php/12345?userid=seairth

Now, the URL matches the representation of the resource being returned!  To
me, this URL is cacheable.  I can throw this thing in my favorites.  I can
even pass it to a friend.  Of course, when the server receives the request,
it is going to look for authentication information a challenge it, but that
is okay!

Now, how is this different from the "sessionid" query string?  I can think
of a couple of things:

1) The returned representation is related to user, not the session.  The
session will change, but the user will not.  However, a different user will
get back a different representation.

2) With the second URL, there is now a direct corollary between the
authentication information and the identifier, which is not the case with a
sessionid.  The sessionid is an added layer of indirection.


So, why use the "userid" concept?  Why not just leave it off altogether
(i.e. just use the first URL above)?  Because you end up with a URL that
returns different representations based on metadata in the http header (the
Authorization header).  For instance, in my system, suppose you were to
compare an anonymous user, an authenticated user, and an authenticated user
that had "reviewer" status.  Here are the different representations
(simplified) you would get back depending on who you were:

Anonymous:
    * You can view document.
    * You can see current vote results, but do not what
      your current vote is.
    * You can see the list of subdocuments that have passed
      peer review.

Authenticated:
    * You can view document.
    * You can see current vote results, as well as what your
      current vote is (if you have voted).
    * You can see the list of subdocuments that have passed
      peer review.

Authenticated with "reviewer" status:
    * You can view document.
    * You can see current vote results, as well as what your
      current vote is (if you have voted).
    * You can see the list of subdocuments that have passed
      peer review, as well as all subdocuments that are
      waiting to be peer reviewed.

Now, with the basic URL, you must rely on the authentication information to
determine which of the above representations to return.  With the URL
containing the userid, the authentication information only verifies that the
request is allowed.  The URL itself actually identifies the representation
to return.

Now, that sounds RESTful to me.

Thoughts?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2255
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-28 02:25:45
Subject:squaring (was Re:HTTP and safety)
Message:

I don't know if this is getting off-topic or not (I'm losing track of what
the thread is about, sorry), but why not just do the following?

Request:
GET /squaring-resource?4

Response:
200 OK

16

The "squaring-resource" above is the (theoretically) open set of all
possible squares.  We are just querying a subset of the resource.


Or is this about avoiding RPC?  Or is this all about how to deal with
containers and such?  I'm just not sure any more.... :~\

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2256
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-28 02:30:51
Subject:Re: [rest-discuss] more on authentication
Message:

On Tue, Aug 27, 2002 at 10:15:01PM -0400, Seairth Jacobs wrote:
> Thoughts?

Pretty good, but consider the following response headers on a GET to
http://example.com/doc.php/12345;

Vary: Authorization
Content-Location: http://example.org/doc.php/12345?userid=seairth

In theory, this allows you to maintain the principle URI for the
document, while not confusing caches about returning somebody else's
authorized representation, and letting the client know where it can get
that exact info later.  In practice, I'm not sure how well it works,
I've never tried it.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2257
Sender:michael@...
Post Date/Time:2002-08-28 02:33:12
Subject:Re: [rest-discuss] Searching Containers
Message:

It seems to me like there's already a 'standard' in place for searching
a URI.  The index.htm and default.htm files are traditionally what are
returned to a browser when a requested URI is not 'fine-grained' enough:

www.somedomain.com/images

If there is no index.htm file there, I get a list of the files in that
directory.  Problem is, if there's 100,000 files there, you're going to
have to wait a while to get a list of them all.

In a RESTful world, with a little more smarts going on behind the
scenes, we should be able to ask a URI what we're allowed to do:

GET / HTTP/1.0

might return

<resources>
    <resource>/users</resource>
    <resource>/groups</resource>
</resources>

Ah, there is a /users, and a /groups resource I am allowed to 'use'.
For more information, I can do

GET /users HTTP/1.0

My intention is to look up a user with a username of 'xxx', but I don't
yet know how to do this.  GETting /users helpfully tells me this:

<allowed-operations>
    <operation name="search">
        <http-method>GET</http-method>
        <required-subcontext>
            <name>username</name>
<subcontext-value-pattern>[a-z][A-Z]</subcontext-value-pattern>
            <subcontext-value-pattern>regexp</subcontext-value-pattern>
        </required-subcontext>
        <use-uri>www.somedomain.com/users/username</use-uri>
    </operation>
    <operation name="new">
        <http-method>PUT</http-method>
        <required-parameter>
            <name>username</name>

<parameter-value-pattern>[a-z][A-Z]</parameter-value-pattern>
        </required-parameter>
        <required-parameter>
            <name>password</name>

<parameter-value-pattern>[a-z][A-Z][0-9][!@%-_.]</parameter-value-patter
n>
        </required-parameter>
    </operation>
</allowed-operations>

Now, both machines and people (with help from an XSLT stylesheet, if
needs be) can see that I can search /users by providing a 'username'
parameter (subcontext), or create a new user by providing a username and
password.  My RESTful application defines the resource associated with
the user in question as /users/username.  I can use a regular expression
for the /username bit to smarten up my queries.  One may envisage even
providing a fill-in-the-blanks SQL string in a
'subcontext-value-pattern' element (all security issues aside).

Essentially, a search is a GET, so we should use it.  However, without
knowing how to perform the right kind of GET on a resource, we're stuck
(how does the client know to use the 'username' parameter in a query
string?).  This, I think, is the difference between a 'document'
resource (ie a user's details), and a 'processor' resource that performs
operations - you don't need to know anything more about a document
except where to get it.  With a processor, you need to know what it
does, so it should tell you when you invoke its base URI.  This
description of a processor's operations is essentially RDF (though I
haven't used the syntax) as I understand it.


- Michael



----- Original Message -----
From: inthedarkplace
To: rest-discuss@yahoogroups.com
Sent: Friday, August 23, 2002 10:39 AM
Subject: [rest-discuss] Searching Containers


Guys,

I'm curious; has anybody established any best practices for
performing arbitrary searching of collection resources? Eg, say I
have the collection /users and I want to find a user with the
username 'kd'. What's the most RESTful and elegant way to do this?

It seems like there's basically three options.

1) Have the user POST an XML-document describing the query to the
collection

Pros: Logically intuitive. If I have a collection, I should ask it to
execute queries.

Cons: Because searching is not a mutator-method (ie it doesn't change
the state of the users collection) it doesn't seem like POST is the
best method. But neither do GET, PUT, or DELETE make much sense
unless  I do a GET with a body which I've been told is in poor taste.
This also makes it very difficult to write the collection code
because now the collection must parse the XML document, figure out
which operation is happening (either user creation or searching) and
then essentially reparse the algorithm.

2) Have the user do a GET on the users collection, passing the search
query in through the query string. eg /users?username='xxx'

Pros: Intuitive. This is what for the query string is for, I think.
It also allows the user to bookmark searches which might be
potentially very useful for working with sets of users.

Cons: Severely limits the expressiveness of queries. Also puts more
code in the users code, but this isn't a huge issue.

3) Create a special query resource located at /users/query. This
query resource can have simply queries passed in through the query
string or more complex queries passed in through a POST.

Pros: This seems to the most elegant. It also makes sense because
POSTing to a query resource can be seen as creating a query.
Potentially, this query could even be assigned a URI. Because queries
can be passed in through GET or POST it allows for arbitrarily
expressive queries.

Cons: Potentially, this could lead to resource explosion because
every container resource now needs an additional 'query' resource.
This might not be such a good thing.

Right now I'm leaning more towards number 3. But I'm curious, what
other solutions have people come up with?

- inthedarkplace






-----------------------------------------------------------------------------------
Post ID:2258
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-28 02:43:13
Subject:Re: [rest-discuss] squaring (was Re:HTTP and safety)
Message:

On Tue, Aug 27, 2002 at 10:25:45PM -0400, Seairth Jacobs wrote:
> I don't know if this is getting off-topic or not (I'm losing track of what
> the thread is about, sorry), but why not just do the following?
> 
> Request:
> GET /squaring-resource?4
> 
> Response:
> 200 OK
> 
> 16
> 
> The "squaring-resource" above is the (theoretically) open set of all
> possible squares.  We are just querying a subset of the resource.

If you squint a little, you'll see that what I just suggested was
almost exactly what you're doing here, only that mine treated the URIs
as opaque by virtue of including the relationship between the two number
resources in the response.

> Or is this about avoiding RPC?  Or is this all about how to deal with
> containers and such?  I'm just not sure any more.... :~\

Yes and yes; generic interfaces, and hypermedia as the engine of
application state.  8-)

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2259
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-08-28 03:32:48
Subject:Re: [rest-discuss] more on authentication
Message:

Hmm...  I think I understand.  I certainly understand the use of the "Vary:
Authorization" bit.  This would keep someone from sitting down at a browser
that had cached a restricted document and bringing it back up from cache
(assuming that the http authentication cache had been cleared).

And I see the value of using "Content-Location" under certain circumstances.
If I understand RFC2616 correctly, this header allows the caching mechanism
to use this URI instead of the request URI.  However, I am thinking that
this would not work for my case.  In my case, a person could point a browser
to

example.com/doc.php/12345

and get back one representation.  However, this person could also view a
different representation for the same resource that is tailored for him
personally.  In order to provide that second representation, the user must
be authenticated.  Using the same URL for both representations, I have not
figured out a clean way to let the server know that the person wants to see
the second representation instead of the first one.  And the server must be
told this somehow so that it can issue the 401 challenge response.  By using
the query string, I can allow a very simple process on the page.  When the
person receives the anonymous representation, there is a textbox in the
upper right-hand corner to receive the person's userid.  When any action is
taken (including "reloading" the page by clicking on the "login"
button/link), this value is used to augment the request-URI (either with
javascript or using a form where method=GET).  In turn, the server
understands the submitted URI as a restricted resource and checks for an
Authorization header (again, to verify the URI only).  Not finding one, it
issues a 401 response.  Once the user has entered the authentication
information and successfuly resubmits the request, the server returns the
new representation.  Now, instead of a textbox in the corner, there would be
a "logout" button/link.  Truthfully though, this button is a fake since all
it really does is takes the user back to the anonymous representation (I
wish there was some way to quietly stop the Authorization header from being
sent as well, but I haven't figured that one out yet).

I hope this all makes sense.  It does in my head, but I don't know if I am
conveying it very well...


Now, the issue of caching is a "whole other ball of wax", as they say.
Ideally, I would like to turn caching off altogether, but I realize that
this puts additional strain on the server.  I think I will start be turning
it off until I understand the usage patterns  better and there is enough
traffic to affect bandwidth/performance (oh, and once I actually understand
how to precisely control caching; any suggested tutorials focusing on
dynamic content?).  Regardless, I think I will include the Vary header "just
in case".  And later, if/when I do allow caching, at least that mechanism
will already be in place.

---
Seairth Jacobs
seairth@...

----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "Seairth Jacobs" <seairth@...>
Cc: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Tuesday, August 27, 2002 10:30 PM
Subject: Re: [rest-discuss] more on authentication


> On Tue, Aug 27, 2002 at 10:15:01PM -0400, Seairth Jacobs wrote:
> > Thoughts?
>
> Pretty good, but consider the following response headers on a GET to
> http://example.com/doc.php/12345;
>
> Vary: Authorization
> Content-Location: http://example.org/doc.php/12345?userid=seairth
>
> In theory, this allows you to maintain the principle URI for the
> document, while not confusing caches about returning somebody else's
> authorized representation, and letting the client know where it can get
> that exact info later.  In practice, I'm not sure how well it works,
> I've never tried it.
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
>







-----------------------------------------------------------------------------------
Post ID:2260
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-28 12:23:00
Subject:Stupid hypertext math tricks
Message:

The only difference between the two solutions is that mine doesn't
provide for starting with some arbitrary number and squaring it; you
bootstrap into it via a hypertext link, not a number.  If that were a
requirement, then I would provide a form on a GET to /square that would
construct the URI given an integer.  That gives you the best of both
worlds; after you've entered "3" and got back "9", you have the choice
of going to the form to enter "9" again, or just clicking on the link
to "81" - or on the "rev" link (or on Google's "backward links" button)
to get back to 3; yes, mine does square roots too. 8-)

Seairth, see;

http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3.1

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2261
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-28 14:39:34
Subject:RE: [rest-discuss] squaring (was Re:HTTP and safety)
Message:

> -----Original Message-----
> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Tuesday, August 27, 2002 10:26 PM
> To: rest-discuss
> Subject: [rest-discuss] squaring (was Re:HTTP and safety)
> 
> 
> I don't know if this is getting off-topic or not (I'm losing 
> track of what
> the thread is about, sorry), but why not just do the following?

It's off topic from my perspective, but if it's useful for you,
then go for it.  I have no primary interest in "stupid math hypertext
tricks", only in constructing minimal models to discriminate the
properties of REST.  My answer to "why not just do the following?"
is because it sheds no light on RESTful use of POST.

> 
> Request:
> GET /squaring-resource?4
> 
> Response:
> 200 OK
> 
> 16
> 
> The "squaring-resource" above is the (theoretically) open set of all
> possible squares.  We are just querying a subset of the resource.

Yes, this is an interesting view of resources that renders them looking
more like state space than processes.  To be more precise, the resource
you have above is the 'square' relation with no constraint on its domain,
and the parameter in the request is the domain constraint for the duration
of the query.

This raises an interesting question for me: Are parameters to be considered
part of the URI proper in all contexts?  Certainly for caching, the "?4" is
an important part of the URI.  But is the requirement of URI opaqueness to
clients, extending even to parameter lists, perhaps too strong? On the one
hand, 'no' because only resources are authoritative as to what are
meaningful
parameters.  On the other hand, 'yes' because in the case where a resource
is in effect a relation (like your example above), it's not unthinkable that
the null set (No Content) be returned when the relation is a partial
function and
there is no mapping for the given parameter.

> Or is this about avoiding RPC?  Or is this all about how to deal with
> containers and such?  I'm just not sure any more.... :~\

Again, in case it's not clear above, it's about *discriminating* RPC from
REST, if indeed they are partitioned (I don't think they are).  If literal
container semantics and only container semantics were allowed for POST,
then I believe I would have no issues.  I also believe, however, that a
bunch
of 'RESTful' implementations would go down in flames, so to speak.

But not to any sort of final RESTing place, alas.

Walden






-----------------------------------------------------------------------------------
Post ID:2262
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-28 15:26:05
Subject:Re: Stupid hypertext math tricks
Message:

On Wed, Aug 28, 2002 at 09:20:56AM -0500, Jeff Bone wrote:
> But is this as useful as simply providing a resource interface and some 
> instructions about how to process it?

I think my revised solution does that ...

>  How does a program (rather than 
> a human) use the form?

I started working on integrating this with RestRDF, but never got it
done.  In the meantime, use WSDL or WRDL.

>  Does the form POST, or...?

GET

>  Can the squares 
> themselves --- resources, certainly --- be obtained by a GET?

Yep.

Let me outline a scenario that starts me wanting to find out the
square of 4.  I'll use new URIs for clarity, plus generalize it a little
to show how it's not specific to squaring;

GET on http://example.org/integers returns a GET form with a single
parameter "number"

I enter "4", hit submit, and get some information on the number four
from the URI http://example.org/integers?number=4, perhaps something
like;

"Four" (4).  See it;
<a rel="http://math.example.org/square" href="/integers?number=16">squared</a>, and
<a rel="http://math.example.org/square-root" href="/integers?number=2">square rooted</a>

This is getting away from Walden's original example, since the URIs
identify the numbers, not some other thing that happens to have the
value.  But I wanted to focus on explaining how links could be used,
and this was the easiest way.

BTW, ignore the square root bit before.  "rev" doesn't work like that.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2263
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-08-28 17:15:50
Subject:RE: [rest-discuss] client-side state management (was Re: Beating my head against the "session management" wall)
Message:


> -----Original Message-----
> From: Mark Baker [mailto:distobj@...] 
>
>  You base 
> your purchasing decision on the *data* not the URI.  So you 
> should keep hold of that.

Mark,

Is that the same as saying you base your purchasing decision on the
representation, not the URI?

regards,
Bill de hra
..
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:2264
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-28 18:13:11
Subject:Re: [rest-discuss] client-side state management (was Re: Beating my head against the "session management" wall)
Message:

On Wed, Aug 28, 2002 at 06:15:50PM +0100, Bill de h�ra wrote:
> Mark,
> 
> Is that the same as saying you base your purchasing decision on the
> representation, not the URI?

Right.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2265
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-08-28 20:27:52
Subject:Re: [rest-discuss] squaring (was Re:HTTP and safety)
Message:

> Again, in case it's not clear above, it's about
> *discriminating*  RPC from REST, if indeed they
> are partitioned (I don't think they are).

It seems to me that the difference breaks down along
the lines of how POST can be used:

1. To request the creation of a subordinate resource.

2. As a logical PUT (or DELETE).  There was a thread
earlier this month about whether or not it is okay to
use POST to perform partial resource updates. I recall that
it was suggested that it is purer (and sometimes necessary)
to update the entire resource using a PUT, but performance
requirements, etc., may preclude doing so.  In this case,
using POST is okay.

3. To request a resource to perform some action upon some
logically subordinate data.

4. To tunnel RPC over HTTP to make arbitrary calls.

So, the question is: is there a meaningful difference
between 3 and 4?

I think there is. RPC generally POSTs to some generic URL;
essentially, the id of the resource being acted upon becomes
the first parameter in the procedure call.  With REST you
have at least moved the first parameter out to a real URL.

Beyond that though, when confronted with an problem where
some RPC-ish approach may be considered, the recourse
model can be refactored to make it more RESTful.

For a simplified example such as squaring numbers, using
the GET/PUT semantics is the way to go, but for a more
general case were some arbitrary level of backend processing
needs to occur, a POST operation would often need to be employed.

This would seem to hold especially when multiple
resources need to be updated in an atomic way.

For example, how do you handle transferring money from
a savings account to a checking account?


Sam Ruby has an article (that I believe someone here had
referenced before) where he makes the statement:

"It is the expression of higher level operations (particularly
ones that perform non-atomic updates) that SOAP's value
proposition becomes apparent.  Sometimes, one truly wants
to have an atomic "transfer funds from savings to checking"
transaction instead of simply a series of discrete GET and PUT's."

[http://radio.weblogs.com/0101679/stories/2002/07/20/restSoap.html]

Surely you can't just GET the account representations, update
the balance in each and then PUT them back one at a time.

I understand the sentiment behind Ruby's statement, but I don't
agree that REST precludes doing atomic operations, so long as
POST semantics are employed.


For example, you could request the creation of a
"transfer" resource

 POST /user/joe/accounts/transfers
 <transfer from-account="savings/1234"
to-account="checking/2345">50</transfer>

on successful transfer:

 201 Created
 Location: /user/joe/accounts/transfers/00001

if insufficient funds:

  400 Bad Request

A GET against /transfers could return a transfer history, etc.



If you did something like POST the to-account number and amount
to the from-acount resource:

 POST /user/joe/savings/transfer
 <transfer to-account="2345">50</transfer>

one could argue that this is RESTful since you are asking the
account resource to work with logically subordinate data, but
using POST in this way does start to "smell" like RPC.


Thanks,
- Jeff







-----------------------------------------------------------------------------------
Post ID:2266
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-08-29 04:04:41
Subject:Re: [rest-discuss] HTTP and safety
Message:

>> The first problem is distinguishing this breakdown in "safety" from
>> the common business case in which a sales pitch lures you into making
>> a bad purchase. On whom does the responsibility for avoiding that
>> lie?

>That's protecting the client. I'm talking about protecting the
>server.

I was too.  So how do you distinguish?

>> The second problem is distinguishing this breakdown in "safety" from
>> the case in which you use HTTP POST to send an arbitrary "block of data
...
>> to a handling process". Or should we say a "block of arguments to a
>> remote handling procedure"?

>Hmm. I'm not sure that there's any distinguishing to be done in that
>case.

Well, I guess I'm arguing that POST is a contract that will have to be
extended in a lot of cases in order to get the job done, and that if
contract
extension is regarded as risky, well then the camel's nose is under the
tent.  I noticed in a previous mail you asserted that POST cannot be
extended in a way that compromises intermediary security policy.  I don't
know much about that, and an example of a contract extension would
be great.  For that matter, any example of compromised security due
to tunneling would be great, but I notice my invitations for stories
going unanswered.  Probably too much effort...

Anyway, one thing I think I've figured out is that while I'm visualizing
a security setup in which the server has a lot of control (arguably enough,
if it chooses to exploit it), you are probably looking at security
as a (textbook) layered concept, and your concern is that an outer layer not
be
dismantled.  Correct me if I'm wrong on that.


>I'm not sure where you're going with it, sorry.

No doubt my fault.  [We were talking about my 'square' example,
in which I send 'square' as a command in a POST body, and you find
to be UnRestful. I was then proposing a number of different strategies
for 'nounifying' the command, in order to try to discover a boundary,
if there exists one, between commands and command surrogates
in the body, such that a Restless example becomes a Restful one.]

In a recent message, Jeff Winters gives an example in which a
<transfer .../> is posted.  The transfer is a document that contains
the parameters for the transfer, but it's also due to become the
record of the action.  How does that rate on your scale?

>Perhaps, but that "block of data" blurb is the most oft referenced
>part of the definition of POST that people use to defend tunneling,
>ala;

>http://www.ics.uci.edu/pub/ietf/http/draft-debry-http-usepost-00.txt

>So I think it's useful that the examples are part/assembly, even if
>the IPP guys chose to ignore them. 8-)

I wonder what the harm would be from removing that bullet from 2616,
and I've often pondered its strange relation to the other bullets, because
it appears to be about a half a layer away in its semantics.  You can
achieve all the other goals by posting form data to a data-consuming
process, can't you.

But as far as tunneling goes, now I'm not so sure that clause is the
tunnel I thought it was before.  As long as what's being posted is 'data'
to the application and not 'control', then visibility is left intact, isn't
it?

If visibility of actions is important, then why is it bad to put an action
in the body of the HTTP message but okay to hide them behind 'processor'
URIs?  Especially when the URIs are going to be opaque in meaning to
all but the server (i.e., intermediaries won't know what they mean either).
Is this okay simply because you can annotate a resource with RDF,
and thereby make the resource's behavior open to inquiring minds?

>My eyes, me eyes! 8-)

Yes, what about URIs?  (-8

Walden








-----------------------------------------------------------------------------------
Post ID:2267
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-29 14:43:13
Subject:Re: [rest-discuss] HTTP and safety
Message:

On Thu, Aug 29, 2002 at 12:04:41AM -0400, Walden Mathews wrote:
> >That's protecting the client. I'm talking about protecting the
> >server.
> 
> I was too.  So how do you distinguish?

Both sides can log all messages that were part of that transaction and
if needed, use them to defend their position in a court of law.  So
there's existing protection from the sort of stuff you're asking about
(fraud, etc..).

The application protocol contract provides a framework to enable the
exchange of those messages to occur in the first place, without a
pre-existing trust relationship.

That didn't exactly answer your question above, but hopefully answers
the previous one.

> >Hmm. I'm not sure that there's any distinguishing to be done in that
> >case.
> 
> Well, I guess I'm arguing that POST is a contract that will have to be
> extended in a lot of cases in order to get the job done, and that if
> contract
> extension is regarded as risky, well then the camel's nose is under the
> tent.  I noticed in a previous mail you asserted that POST cannot be
> extended in a way that compromises intermediary security policy.  I don't
> know much about that, and an example of a contract extension would
> be great.  For that matter, any example of compromised security due
> to tunneling would be great, but I notice my invitations for stories
> going unanswered.  Probably too much effort...

Well, a good example of tunneling would be IPP-over-HTTP.  The
application contract in effect there is IPP, not HTTP, but a firewall
not able to detect tunneling will think that it is HTTP.  IPP is
standardized, which is good - so people have looked at it and thought
hard about ways in which it can be used to break itself.  But the
vast majority of tunnelling has not benefitted from such study.  And
indeed, the use of RPC whose existence is to promote billions of
application protocols, rather than the 10 or so we use now, is just
dangerous.

> Anyway, one thing I think I've figured out is that while I'm visualizing
> a security setup in which the server has a lot of control (arguably enough,
> if it chooses to exploit it), you are probably looking at security
> as a (textbook) layered concept, and your concern is that an outer layer not
> be
> dismantled.  Correct me if I'm wrong on that.

The characterization of my position sounds about right (assuming
"outer" is where I think it is 8-).  But I'm not sure about your
position.

> >I'm not sure where you're going with it, sorry.
> 
> No doubt my fault.  [We were talking about my 'square' example,
> in which I send 'square' as a command in a POST body, and you find
> to be UnRestful. I was then proposing a number of different strategies
> for 'nounifying' the command, in order to try to discover a boundary,
> if there exists one, between commands and command surrogates
> in the body, such that a Restless example becomes a Restful one.]
> 
> In a recent message, Jeff Winters gives an example in which a
> <transfer .../> is posted.  The transfer is a document that contains
> the parameters for the transfer, but it's also due to become the
> record of the action.  How does that rate on your scale?

I don't recall the example, but if its intent is to request specific
behaviour from the server, then it's low on my scale.

> >Perhaps, but that "block of data" blurb is the most oft referenced
> >part of the definition of POST that people use to defend tunneling,
> >ala;
> 
> >http://www.ics.uci.edu/pub/ietf/http/draft-debry-http-usepost-00.txt
> 
> >So I think it's useful that the examples are part/assembly, even if
> >the IPP guys chose to ignore them. 8-)
> 
> I wonder what the harm would be from removing that bullet from 2616,
> and I've often pondered its strange relation to the other bullets, because
> it appears to be about a half a layer away in its semantics.  You can

I suggested a replacement to the HTTP WG, but Roy likes it so it stays.

> achieve all the other goals by posting form data to a data-consuming
> process, can't you.

Roy has a slightly more specific definition of "posting form data" than
I do.  But yes, I see that as the most general description with the
others being special cases.

> But as far as tunneling goes, now I'm not so sure that clause is the
> tunnel I thought it was before.  As long as what's being posted is 'data'
> to the application and not 'control', then visibility is left intact, isn't
> it?

Yes.

> If visibility of actions is important, then why is it bad to put an action
> in the body of the HTTP message but okay to hide them behind 'processor'
> URIs?  Especially when the URIs are going to be opaque in meaning to
> all but the server (i.e., intermediaries won't know what they mean either).

Right, that's the point.  Any action that might be taken is only
understood to be an action by the server.  To the client, it's just an
identifier like any other.

> Is this okay simply because you can annotate a resource with RDF,
> and thereby make the resource's behavior open to inquiring minds?

Hmm, no, I don't think so, if I understand what you mean.  It's just
because the URI is opaque, and therefore invoking GET on it means GET to
the client.  Invoking "buyShoes" over POST means "buyShoes" to the
invoker.

> 
> >My eyes, me eyes! 8-)
> 
> Yes, what about URIs?  (-8

<groan/>

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2268
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-29 15:38:54
Subject:Evidence
Message:

Mark Baker wrote:
> Both sides can log all messages that were part of that transaction 
and
> if needed, use them to defend their position in a court of law.  So
> there's existing protection from the sort of stuff you're asking 
about
> (fraud, etc..).

This is an important point for business.
But are you taking full advantage of REST when you think about it?
Business exchanges are conversations.
If you think of each message as a speech act, 
probably related to other speech acts in the same conversation,
then each speech act is an important resource deserving a URI.

If you combine:
* state-alignment transactions so that each party agrees on each 
important business milestone, e.g. commitment and fulfillment of 
commitment
* business rules that are also published with URIs
* digital signatures 
* canonical representations of the whole ball of wax
- then you got something that you could take into court,
but you probably won't need to.

-Bob Haugen

P.S. I think a lot of the current discussion focuses on "how to do 
RPC in REST" rather than "use cases for which REST is a clear 
advantage".







-----------------------------------------------------------------------------------
Post ID:2269
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-29 15:41:43
Subject:FW: squaring (was Re:HTTP and safety)
Message:

Jeff - I'm forwarding this to rest-discuss.  My message to you last
night was composed in the yahoo form, and I didn't know if it would
automatically cc: it to the group.  It didn't.  8-(  -- Walden

> -----Original Message-----
> From: Jeffrey Winter [mailto:j.winter@...]
> Sent: Thursday, August 29, 2002 11:29 AM
> To: Mathews, Walden
> Subject: Re: squaring (was Re:HTTP and safety)
> 
> 
> > I thought the RPC "smell" came from embedding actions in 
> the request 
> > body.  Do your examples do that?  I guess the answer depends on 
> > whether <transfer> is an action or an artifact, but if the latter 
> > then it's pretty clearly an artifact of an action.
> 
> Because of the context of the issue - that two different resources
> need to be updated in an atomic operation - the operation 
> itself is "meaningful", i.e., has internal structure and possible 
> state, and *could* be given a URL.  If there was no need for the 
> operation to be atomic, you could just do two GETs followed by two 
> PUTs.  So I think this elevates it to being more than just some 
> action or tricky way of dressing up an artifact of the action to 
> hide its otherwise purely operational nature.
> 
> If there is a better way of handling this I'd also be very interested
> in seeing how to do it as it would provide more insight into REST.
> 
> > What if my application really does not care about keeping 
> records of 
> > transfers, so there's no requirement to store transfer records and 
> > therefore no concept of subordinate resource?  In other words, 
> > there's just the act of transferring in real time.  Does 
> that change 
> > the "smell" of the examples above?  Would you change your design of 
> > the application interface in light of that requirement 
> clarification?
> 
> I wouldn't. Again, given the context, I still think my example would 
> make sense, but you don't necessarily need to create an actual 
> resource and give it a URI.
> 
> At the risk of again losing sight of the root issue though the 
> introduction of yet another example, I can see this as analogous 
> to a /bulliten-board resource where you don't necessarily need to 
> provide URLs for each posted document. In that case a posted document 
> is very clearly a subordinate resource, but in this specific 
> context, I see the transaction as being a real resource too.
> 
> > I'm looking for boundary examples for RESTfulness, i.e. 
> hard cases to 
> > judge, if there is such a thing.
> 
> Me too.
> 
> - Jeff
> 
> 
> 
> 






-----------------------------------------------------------------------------------
Post ID:2270
Sender:"Niteo" <j.winter@...>
Post Date/Time:2002-08-30 00:16:20
Subject:Re: [rest-discuss] squaring (was Re:HTTP and safety)
Message:

Terrence,

First off, I agree with you.  I should say that I was 
most definitely *not* trying to offer a new definition 
of POST; I was basically trying to catalogue the 
uses of POST that have been brought up in order to try 
to bring into relief the precise issue that Walden was 
trying to raise.  Which I think boils down to: if RPC 
is bad because it's misusing POST to send, in essence, 
arbitrary data to some URL, in what way is that different 
from using it as what you call a Document Processor - if
I understand what you mean by that term. :)

I tried to spell out what I see as a real and meaningful 
difference.  

I agree with Walden that there are situations that seem
very gray. One that I can think of right away is performing
atomic updates across multiple resources.  The canonical,
"transfer funds between accounts" example seems like a
good use case to examine.

I would be very interested in hearing other's thoughts on 
how to do that in a way that doesn't smack of RPC.

Thanks,

- Jeff








-----------------------------------------------------------------------------------
Post ID:2271
Sender:Terrence Molson <inthedarkplace@...>
Post Date/Time:2002-08-29 18:41:14
Subject:Re: [rest-discuss] squaring (was Re:HTTP and safety)
Message:

Jeff,
Well, after reading and rereading the standard and Fielding's thesis and some other texts on document-centric modelling (which HTTP is heavi;ly based on though Fielding nor TBL ever admit it, GET, PUT, DELETE, POST are directly analagous to READ, WRITE, DELETE, XX) I think the only valid uses of POST are as follows:
1) Resource Creation.
2) Append-To-Document
3) Document Processor
Note that 1,2,3 are all very much alike. For example, if you consider /purchase-orders the collection of purchase orders in the system then POST'ing a new purchase-order to that collection can be seen as using 1 or 2. There are subtle and important differences between them. Still, RPC never enters the picture. You are always passing fully formed documents that could possibly stand alone.
- itdp
 Jeffrey Winter wrote:> Again, in case it's not clear above, it's about
> *discriminating*  RPC from REST, if indeed they
> are partitioned (I don't think they are).

It seems to me that the difference breaks down along
the lines of how POST can be used:

1. To request the creation of a subordinate resource.

2. As a logical PUT (or DELETE).  There was a thread
earlier this month about whether or not it is okay to
use POST to perform partial resource updates. I recall that
it was suggested that it is purer (and sometimes necessary)
to update the entire resource using a PUT, but performance
requirements, etc., may preclude doing so.  In this case,
using POST is okay.

3. To request a resource to perform some action upon some
logically subordinate data.

4. To tunnel RPC over HTTP to make arbitrary calls.

So, the question is: is there a meaningful difference
between 3 and 4?

I think there is. RPC generally POSTs to some generic URL;
essentially, the id of the resource being acted upon becomes
the first parameter in the procedure call.  With REST you
have at least moved the first parameter out to a real URL.

Beyond that though, when confronted with an problem where
some RPC-ish approach may be considered, the recourse
model can be refactored to make it more RESTful.

For a simplified example such as squaring numbers, using
the GET/PUT semantics is the way to go, but for a more
general case were some arbitrary level of backend processing
needs to occur, a POST operation would often need to be employed.

This would seem to hold especially when multiple
resources need to be updated in an atomic way.

For example, how do you handle transferring money from
a savings account to a checking account?


Sam Ruby has an article (that I believe someone here had
referenced before) where he makes the statement:

"It is the expression of higher level operations (particularly
ones that perform non-atomic updates) that SOAP's value
proposition becomes apparent.  Sometimes, one truly wants
to have an atomic "transfer funds from savings to checking"
transaction instead of simply a series of discrete GET and PUT's."

[http://radio.weblogs.com/0101679/stories/2002/07/20/restSoap.html]

Surely you can't just GET the account representations, update
the balance in each and then PUT them back one at a time.

I understand the sentiment behind Ruby's statement, but I don't
agree that REST precludes doing atomic operations, so long as
POST semantics are employed.


For example, you could request the creation of a
"transfer" resource

POST /user/joe/accounts/transfers
<transfer from-account="savings/1234"
to-account="checking/2345">50</transfer>

on successful transfer:

201 Created
Location: /user/joe/accounts/transfers/00001

if insufficient funds:

  400 Bad Request

A GET against /transfers could return a transfer history, etc.



If you did something like POST the to-account number and amount
to the from-acount resource:

POST /user/joe/savings/transfer
<transfer to-account="2345">50</transfer>

one could argue that this is RESTful since you are asking the
account resource to work with logically subordinate data, but
using POST in this way does start to "smell" like RPC.


Thanks,
- Jeff


Yahoo! Groups SponsorADVERTISEMENT

To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 



---------------------------------
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes





-----------------------------------------------------------------------------------
Post ID:2272
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-29 16:24:01
Subject:Re: [rest-discuss] Evidence
Message:

On Thu, Aug 29, 2002 at 03:38:54PM -0000, bhaugen32 wrote:
> Mark Baker wrote:
> > Both sides can log all messages that were part of that transaction 
> and
> > if needed, use them to defend their position in a court of law.  So
> > there's existing protection from the sort of stuff you're asking 
> about
> > (fraud, etc..).
> 
> This is an important point for business.
> But are you taking full advantage of REST when you think about it?

I think so.

> Business exchanges are conversations.

Right, but REST based business interactions are stateless.  Those two
things are not at odds, if that's what you're suggesting.

> If you think of each message as a speech act, 
> probably related to other speech acts in the same conversation,
> then each speech act is an important resource deserving a URI.

Hmm, I'm not so sure.

Consider this "conversation";

"Hi Bob"
- "Hi Mark"
"How's the wife?"
- "Good"

That conversation is stateful.  The last "Good" message doesn't say
what is good.  You need the context of at least part of the conversation
in order to understand what it means.  A stateless version of that
conversation would be;

"Hi Bob"
- "Hi Mark"
"How is Bob's wife?"
- "Bob's wife is good"

It sounds a bit odd, but that's how I'd do RESTful conversations.

> If you combine:
> * state-alignment transactions so that each party agrees on each 
> important business milestone, e.g. commitment and fulfillment of 
> commitment
> * business rules that are also published with URIs
> * digital signatures 
> * canonical representations of the whole ball of wax
> - then you got something that you could take into court,
> but you probably won't need to.

In the stateless case, you could just take the offending message to
court and leave everything else behind, because its meaning is
independant of any conversation it may have been sent in.

> -Bob Haugen
> 
> P.S. I think a lot of the current discussion focuses on "how to do 
> RPC in REST" rather than "use cases for which REST is a clear 
> advantage".

Yep.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2273
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-08-30 02:44:39
Subject:Re: [rest-discuss] Evidence
Message:

> > P.S. I think a lot of the current discussion focuses on "how to do 
> > RPC in REST" rather than "use cases for which REST is a clear 
> > advantage".
> 
> Yep.

I agree, and as an enthusiastic REST newbie, it's the cases where REST has
a clear advantage that I would like to hear about.


Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.goose-works.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2274
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-30 03:54:34
Subject:squaring (was Re:HTTP and safety)
Message:

See
http://mail.python.org/pipermail/xml-sig/2002-February/007160.html:

The point is to think of documents. This is a subtle but crucial 
distinction. Don't think of a document processor as a procedure that 
takes parameters; think of it as a folder into which you insert 
documents. Eventually something happens to those documents but the 
truth is, you don't really care. 

If you're asking about the advantages over using the POST/Document 
Processor approach versus RPC then from experience I can tell you:

1) EXTENSIBILITY & MAINTAINABILITY - I can't stress this enough. The 
fundamental problem with all RPC-mechanisms is that they are 
inherently not loosely coupled. Think of a method in Java. This 
method defines a contract and semantics. If you change this method -- 
by removing or adding a parameter or changing parameters etc -- then 
you break all clients which depend on that method. Now think of an 
html document. It's a document whose meaning and semantics are fully 
self-contained in the document. A browser, which processes html 
documents, isn't broken when you add elements or even when you remove 
elements. Think about event based processing. 

The fundamental idea is that in a highly distributed system two 
parties should know as little about each other as possible. In 
REST/document/event-based systems, all the parties have to know is 
essentially a URL to which they send documents/events. In an RPC/SOAP 
world, they have to know a lot more. This is one of the primary 
reasons my group began reworking all webservices to be REST based. I 
saw the time and effor that went into managing RPC services and 
coordinating interfaces and decided it was unacceptable.

2) SCALABILITY - See mprescod and fielding for how a document-
centric, highly asynchronous approach will always scale better than 
the basic rpc approach.

3) FLEXIBILITY - I don't really have time to explain it in full 
detail, but there are many, many bad things that can happen when you 
use POST as an RPC-mechanism or use RPC in general. You can end up in 
situations where a competitor has 'locked' you in because he controls 
the api on his side and if you want access to his info well you get 
the idea. (This is why I call the WS-* standards one api to rule them 
all). But there are many good things that happen when you think in 
terms of business documents particularly in terms of reuse. It's been 
my experience that integerating REST systems is trivial and building 
web-frontends is even easier. Not many people see it, but there's a 
huge difference between exposing business logic -- which consists of 
documents like purchase orders -- and exposing application logic -- 
which consists of methods and behavior and state and all that good 
stuff.

As for your transfer funds use case, I've designed something pretty 
similar. The way I did it, I created a document which described the 
transaction itself and POSTED that to a transaction processor 
resource. I then repeatedly performed GETs on a transaction monitor 
resource to know what was up. This trick of turning methods into 
documents/events works well.

- itdp

--- In rest-discuss@y..., "Niteo" <j.winter@n...> wrote:
> Terrence,
> 
> First off, I agree with you.  I should say that I was 
> most definitely *not* trying to offer a new definition 
> of POST; I was basically trying to catalogue the 
> uses of POST that have been brought up in order to try 
> to bring into relief the precise issue that Walden was 
> trying to raise.  Which I think boils down to: if RPC 
> is bad because it's misusing POST to send, in essence, 
> arbitrary data to some URL, in what way is that different 
> from using it as what you call a Document Processor - if
> I understand what you mean by that term. :)
> 
> I tried to spell out what I see as a real and meaningful 
> difference.  
> 
> I agree with Walden that there are situations that seem
> very gray. One that I can think of right away is performing
> atomic updates across multiple resources.  The canonical,
> "transfer funds between accounts" example seems like a
> good use case to examine.
> 
> I would be very interested in hearing other's thoughts on 
> how to do that in a way that doesn't smack of RPC.
> 
> Thanks,
> 
> - Jeff







-----------------------------------------------------------------------------------
Post ID:2275
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-30 05:42:50
Subject:Re: [rest-discuss] Evidence
Message:

>
> In the stateless case, you could just take the offending message to
> court and leave everything else behind, because its meaning is
> independant of any conversation it may have been sent in.
Including any previous commitments to buy at a certain price (like a
catalog)?






-----------------------------------------------------------------------------------
Post ID:2276
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-08-30 07:25:12
Subject:Re: [rest-discuss] Evidence
Message:

Mark Baker wrote,
> A stateless version of that conversation would be;
>
> "Hi Bob"
> - "Hi Mark"
> "How is Bob's wife?"
> - "Bob's wife is good"
>
> It sounds a bit odd, but that's how I'd do RESTful conversations.

Is it always possible to eliminate context this way? How would you deal 
with,

 "Hi Bob"
 - "Hi Mark"
 "Nice weather today"
 - "Sorry, missed that. What did you say?"
 "Nice weather today"

The relationship with reliable messaging protocols should be obvious.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2277
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-08-30 11:15:59
Subject:RE: [rest-discuss] Evidence
Message:


> From: Miles Sabin [mailto:miles@...] 
>
>  "Hi Bob"
>  - "Hi Mark"
>  "Nice weather today"
>  - "Sorry, missed that. What did you say?"
>  "Nice weather today"
> 
> The relationship with reliable messaging protocols should be obvious.

or:

 "Hi Bob"
 - "Hi Mark"
 "two guinness please"
 "two guinness please"

The relationship with the browser's back button should also be obvious.

regards,
Bill de hra
..
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:2278
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-30 11:40:49
Subject:Re: Evidence
Message:

Mark Baker wrote:
> > Business exchanges are conversations.
> 
> Right, but REST based business interactions are stateless.  Those 
two
> things are not at odds, if that's what you're suggesting.

No, I wasn't suggesting it, but your response suggests that there may 
be conflicts depending on how it's done.  More below...
 
> > If you think of each message as a speech act, 
> > probably related to other speech acts in the same conversation,
> > then each speech act is an important resource deserving a URI.
> 
> Hmm, I'm not so sure.

> > If you combine:
> > * state-alignment transactions so that each party agrees on each 
> > important business milestone, e.g. commitment and fulfillment of 
> > commitment
> > * business rules that are also published with URIs
> > * digital signatures 
> > * canonical representations of the whole ball of wax
> > - then you got something that you could take into court,
> > but you probably won't need to.
> 
> In the stateless case, you could just take the offending message to
> court and leave everything else behind, because its meaning is
> independant of any conversation it may have been sent in.

Depending on what you mean, that gets tricky.  
Simple case:  shipment notification is dependent on order line which 
it purports to fulfill.  Claims of non-fulfillment would need both 
the shipment notification and the order line.

More complex case:  non-fulfillment is covered by a long term 
contract which provides penalties.  So now the long-term contract 
clause must be stated as well.

In a business conversation, each speech act will refer to any other 
statements required for its meaning.  But it will usually not repeat 
all the relevant elements.  

In URI-land, the most natural representation would be for statement B 
to contain a hyperlink to statement A, but not to transclude a full 
representation of statement A.

However, for evidence and for "what to digitally sign", one could 
create a combined canonical representation of the related statements 
and sign that.  Then you do have one document to take to to court.

Are these ideas relevant to the issue raise?

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2279
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-30 11:49:19
Subject:Re: transfers and dining philosophers (was Re:squaring)
Message:

"Jeffrey Winter" wrote:
> ... when multiple
> resources need to be updated in an atomic way.
> 
> For example, how do you handle transferring money from
> a savings account to a checking account?
[...]
> For example, you could request the creation of a
> "transfer" resource
> 
>  POST /user/joe/accounts/transfers
>  <transfer from-account="savings/1234"
> to-account="checking/2345">50</transfer>
> 
> on successful transfer:
> 
>  201 Created
>  Location: /user/joe/accounts/transfers/00001
> 
> if insufficient funds:
> 
>   400 Bad Request
> 
> A GET against /transfers could return a transfer history, etc.

In my opinion, you got it.

Read also Jeff Bone's "Dining Philosophers in REST":
http://www.xent.com/pipermail/fork/2001-August/002923.html

<excerpt>
Clay [Shirky] posed race conditions as a challenge that perhaps 
cannot be
overcome with the REST design practice of using HTTP's generic
interfaces and resource modeling, due to a perceived need to
atomically perform a series of HTTP methods.  The claim is that an
RPC interface, by allowing the encapsulation of the desired
operations into one specialized interface that can be tunneled
through and atomically performed in the context of a single POST.

The latter strategy --- take care of all the necessaries in a single
POST --- is correct, but it doesn't require the introduction of
specialized method interfaces, just the appropriate decomposition
into resources.  I'd already been working on a short but hopefully
enlightening example --- the venerable Dining Philosophers,
serendipity! --- to demonstrate how resource modeling can handle a
similar problem.  

[...]

Assume that the problem space --- tables, forks, what have you --- is
implemented as a Web Service using the REST style.  The philosophers
themselves are the client applications which consume the Web
Service. 

[...]

Imagine that we have introduced to the problem space two waiters;
they act on behalf of the philosophers, who have been instructed not
to pick up or put down the forks directly themselves.  (In fact they
cannot because we don't model the forks directly.)  The desired
atomic behavior is encapsulated in and between the waiters.  One
waiter is tasked with observing the table and, at a philosopher's
request and if possible, taking from the philosopher their ticket,
removing the two adjacent forks from the table and handing them to
the philosopher.  The other waiter performs the reverse function,
exchanging forks for the corresponding ticket and placing them on the
table.

[...]
The critical sections which are usually protected by mutexes are
implemented in the waiters, and each is engaged through a single HTTP
transaction.

[...]

So:  REST can do Dining Philosophers; the trick is just to
encapsulate the critical sections into local objects and reify them
as resources.  The notion that you need some kind of transactional
control at the protocol level is, in fact, a boondoggle;
transactions are always a higher-level abstraction, and any
lower-level but complete abstraction --- INVOKE, GET / PUT / POST,
READ / WRITE / TAKE, etc. are all sufficient;  transactions can be
provided either locally or as higher-level semantics layered atop but
conforming to the semantics of the substrate.

More generally, this should at least suggest that the primary
difference between REST and procedure calling is in modeling the
problem domain as a set of resources --- nouns --- each of which can
be potentially active but which responds to a generic interface.
This as opposed to the RPC approach of specialized interfaces. 

[...]

The problem is one of modeling, not one of the richness and 
expressivity of either approach.

[...]

it's always a bad idea to manage transactions (i.e., attempt to 
guarantee atomicity of a sequence of actions, *even if this is made 
possible by the underlying communication model*) non-locally. 
Whenever possible --- and it's always possible --- atomic sequences 
of interactions should be managed by intermediate objects local to 
the resources being locked and manipulated; it's trivial to 
encapsulate transactions into a single atomic exchange, and exposing 
those encapsulations as first class entities is generally a pretty 
good idea. And it certainly fits with the REST model of the world. 
</excerpt>







-----------------------------------------------------------------------------------
Post ID:2280
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-30 15:18:41
Subject:Re: [rest-discuss] Evidence
Message:

On Fri, Aug 30, 2002 at 08:25:12AM +0100, Miles Sabin wrote:
> Is it always possible to eliminate context this way?

I suspect and believe so, but I don't know for sure.

> How would you deal 
> with,
> 
>  "Hi Bob"
>  - "Hi Mark"
>  "Nice weather today"
>  - "Sorry, missed that. What did you say?"

Assuming that was necessary because of a corrupt message, it would be a
400 response message whose correlation to "nice weather today" is
implicit in the connection (at least for HTTP).  So more accurately, to
list all the messages, including response messages, a stateless
conversation over a connection oriented protocol would be;

"Hi Bob" - "ok"
 - "Hi Mark" - "ok"
"Nice weather today" - "sorry, missed that"
"Nice weather today" - "ok"

> The relationship with reliable messaging protocols should be obvious.

Definitely.  Roy touches on this when talking about statelessness;

 "This constraint induces the properties of visibility, reliability, and scalability. [...]Reliability is improved because it eases the task of recovering from partial failures[...]"
 -- http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2281
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-30 15:30:09
Subject:Re: Evidence
Message:

I tried to post a slightly different version of this message earlier, 
but it looked like Yahoo Groups timed out.  Sorry if two appear later.

"S. Mike Dierken" wrote:
> >
> > In the stateless case, you could just take the offending message 
to
> > court and leave everything else behind, because its meaning is
> > independant of any conversation it may have been sent in.

> Including any previous commitments to buy at a certain price (like a
> catalog)?

Exactimento!  Business conversations consist of a buildup of 
conditions, commitments, fulfillments of commitments, claims for 
payment, claims that commitments were not fulfilled correctly, etc. 
etc. Almost every statement beyond "Hello" is dependent on some 
previous statements, and even "Hello" assumes authentication.

There are very few, almost no independent statements.

Two possible ways to deal:
1. Embed a representation of every possible dependency in a canonical 
representation of every dependent statement.
2. Follow hyperlinks to chains of dependencies.

Each of those ways could be appropriate for some situation or other.

I'm still trying to work out all the implications.  If there are 
other ways to deal, I'm all ears.

But it will not work to avoid the dependencies.  In business, 
everything is dependencies.  In software development, it's much the 
same.  To me, hyperlinks *are* dependencies.

-Bob Haugen

P.S. I believe canonical representations of evidence of electronic 
business deals will be "standardized" probably by more than 
one "standards" org.  That's where I think URIs for all evidence will 
be a clear advantage for REST vs burying the evidence in proprietary 
systems.







-----------------------------------------------------------------------------------
Post ID:2282
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-08-30 15:53:22
Subject:Re: [rest-discuss] squaring (was Re:HTTP and safety)
Message:

That's a good summarization, but I don't think we're 
disagreeing in any way.  

There is no inherent advantage to using RPC; it was 
more of a issue of trying to identify use cases 
where an RPC style approach might be appealed to 
and seeing if a RESTful approach could be identified
that isn't itself just RPC in disguise.

Thanks again,

- Jeff








-----------------------------------------------------------------------------------
Post ID:2283
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-08-30 15:55:58
Subject:Re: [rest-discuss] Evidence
Message:

> > P.S. I think a lot of the current discussion focuses on "how to do 
> > RPC in REST" rather than "use cases for which REST is a clear 
> > advantage".
> 
> Yep.

I think this mischaracterisizes the original discussion a 
bit.  The underlying issue was more along the lines of how 
to *avoid doing* RPC in REST.

If there are "use cases for which REST is a clear advantage," this 
would imply that there are cases where it isn't.  What are those
cases?

Understanding what those boundaries are (and I can't think of any) 
would be very illuminating.







-----------------------------------------------------------------------------------
Post ID:2284
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-30 16:26:44
Subject:Re: [rest-discuss] Evidence
Message:

Mark Baker wrote:
> 
>...
> 
> In the stateless case, you could just take the offending message to
> court and leave everything else behind, because its meaning is
> independant of any conversation it may have been sent in.

You need the message plus all resources pointed to by the message. If
the messages is "Yes I agree to the contract at http://..../" then you
need http://.../ and you need it as it was at the time the message was
sent (a good argument for signed, immutable resources in contractual
contexts).
-- 
 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2285
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-30 16:36:45
Subject:Re: Evidence
Message:

Paul Prescod wrote:
> Mark Baker wrote:
> > 
> >...
> > 
> > In the stateless case, you could just take the offending message 
to
> > court and leave everything else behind, because its meaning is
> > independant of any conversation it may have been sent in.
> 
> You need the message plus all resources pointed to by the message. 
If
> the messages is "Yes I agree to the contract at http://..../" then 
you
> need http://.../ and you need it as it was at the time the message 
was
> sent (a good argument for signed, immutable resources in contractual
> contexts).

Yes yes yes! Yes! and Yes again! Thank you!

I've been thinking signed canonical representations, because I didn't 
know how to specify immutable resources.  Do you?

(Although wouldn't either work?)








-----------------------------------------------------------------------------------
Post ID:2286
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-30 16:53:43
Subject:Re: [rest-discuss] squaring (was Re:HTTP and safety)
Message:

Niteo wrote:
> 
>...
> 
> I agree with Walden that there are situations that seem
> very gray. One that I can think of right away is performing
> atomic updates across multiple resources.  The canonical,
> "transfer funds between accounts" example seems like a
> good use case to examine.

I don't know yet whether RPC and REST are on two sides of a fence or two
ends of a spectrum. Is submitting a "transfer order" an RPC (because the
meaning is embedded in the message)? Well let's just say we can move it
pretty far to the REST side of the spectrum if we:

 * make the order addressable so that it can be referred to by anyone,
anytime
 * describe the transfer order in an XML or RDF schema, in as rich a way
as possible
 * make the URI for "submit transfer order for this account" a hyperlink
from the account object
 * separate the URI for "submit transfer order" from the URIs for "pay
bills from this account" and "get information about this account" and
"withdraw money from this account"
 * if transfer orders can be removed, updated or read, use standard HTTP
methods to do so
 * make a GET on the URI for "submit transfer order" return something
that lists the current orders and perhaps describes what will happen
when new orders are submitted (prose or machine readable?)

Hopefully these will help someone.

Here's a way of thinking about it: consider an intermediary or third
party shown a single message. The more they know without understanding
the domain, the better. With GET, PUT and DELETE you know a bunch
without knowing much about either the resource types or the
representations. With POST, you usually need to know more about resource
types but if you don't need to know data format then you are still
making progress. A POST to a transfer order submission URI is going to
create a money transfer document -- the exact representation is only
needed if you care who is receiving the money and how much money is
being received. If you need to know both the resource type and the data
format to know anything interesting about what's going on then you're
doing RPC. e.g. if you have a "submit something" resource and what
happens is entirely dependent on what you submit.

Another random thought: Moving data between accounts is not in general
an atomic operation. One bank has to debit the money and the other
credit it. When they are the same bank they can present the illusion of
atomicity but more generally the operation involves a perhaps unreliable
third party. That suggests to me that using resources rather than
stateful messages is a better way to keep everyone aligned and in
agreement about what's going on. When we start to involve various
independently controlled parties we have to relax our requirements of
atomicity and figure out how to get work done without it.

So basically I think that doing a POST of a "money transfer order" is a
better model than doing an RPC and therefore I disagree with Sam Ruby
that this example exposes a limitation of the REST model.
-- 
 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2287
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-08-30 16:56:44
Subject:[rest-discuss] When REST should and should not be used Was: Evidence
Message:

On Fri, 30 Aug 2002, Jeffrey Winter wrote:

> > > P.S. I think a lot of the current discussion focuses on "how to do 
> > > RPC in REST" rather than "use cases for which REST is a clear 
> > > advantage".
> > 
> > Yep.
> 
> I think this mischaracterisizes the original discussion a 
> bit.  The underlying issue was more along the lines of how 
> to *avoid doing* RPC in REST.
> 
> If there are "use cases for which REST is a clear advantage," this 
> would imply that there are cases where it isn't.  What are those
> cases?

Well? What are some use cases where REST should not be used? Since I'm
advocating a RESTful implementation of Linda tuple spaces, I'd like to
know if my use cases falls into this category!

> Understanding what those boundaries are (and I can't think of any) 
> would be very illuminating.

Hmmm... No cases where REST should not be used? This sounds like religious
enthusiasm to me....

Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.goose-works.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2288
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-30 16:59:56
Subject:Re: [rest-discuss] Evidence
Message:

Sam Hunting wrote:
> 
> > > P.S. I think a lot of the current discussion focuses on "how to do
> > > RPC in REST" rather than "use cases for which REST is a clear
> > > advantage".
> >
> > Yep.
> 
> I agree, and as an enthusiastic REST newbie, it's the cases where REST has
> a clear advantage that I would like to hear about.

No matter what side of the debate they are on, almost everyone agrees
that REST is better for read-only or read-mostly applications. RPC and
"messaging" people sometime to argue that REST is *limited* to these
applications  but I think it is more accurate to say that it takes more
imagination and skill to understand how REST is also better for
read-write applications. ;)

I've also never heard anyone dispute that REST is better for
applications that depend upon address-keyed metadata like RSS, RDF or
Topic Maps (to play to your biases).

REST is pretty obviously better for content-management style
applications.

REST has clear advantages when the human implementors of systems are not
coordinated. i.e. when you can't upgrade the participants all at the
same time.
-- 
 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2289
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-08-30 17:06:54
Subject:Re: [rest-discuss] Evidence
Message:

I'll respond to all the other messages here ...

On Fri, Aug 30, 2002 at 09:26:44AM -0700, Paul Prescod wrote:
> > In the stateless case, you could just take the offending message to
> > court and leave everything else behind, because its meaning is
> > independant of any conversation it may have been sent in.
> 
> You need the message plus all resources pointed to by the message. If
> the messages is "Yes I agree to the contract at http://..../" then you
> need http://.../ and you need it as it was at the time the message was
> sent (a good argument for signed, immutable resources in contractual
> contexts).

No, I don't think you need representations of all the referenced
resources, at least if you've done it right.  Using that example, it
would be a mistake to agree to a contract by reference, because the
contract may change by the time the message is processed.

The rule is, if the meaning of the message depends upon the result of
dereferencing a URI, then this is stateful and a bad thing.

So while it would be fine to, say, send a list of contracts by URI
for the simple purpose of enumerating them, it would not for the
purpose of agreeing to them.  That's because in the former case, only
their *identity* contributes to "meaning", whereas in the latter, their
*state* contributes to it.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2290
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-08-30 17:15:33
Subject:Re: [rest-discuss] Evidence
Message:

> > As  an enthusiastic REST newbie, it's the cases where REST has
> > a clear advantage that I would like to hear about.
> 
> 
> REST has clear advantages when the human implementors of systems are not
> coordinated. i.e. when you can't upgrade the participants all at the
> same time.

For any reasonably sized size of human communication (say, a
topic-map-enabled conversational space) this would almost always be the
case. Can you elaborate on the clear advantages in this context? (I'm
joining the conversation late, I know)



Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.goose-works.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2291
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-30 17:20:25
Subject:RE: [rest-discuss] Evidence
Message:

This is addressed to all who have contributed to the thread, not
just Mark.  Are these ideas based on experience in some judicial
system or another?  Or are they systems analysts views of where the
authoritative data in a transaction *ought to* be found?

My own opinion, based on judges and arbitrators I have faced in
contract matters, is that they want a context from which to judge
what constitutes the contract in question, and they don't like
other people constraining them in their judgment of how wide or
narrow that context should be.

I think that judges and juries for that matter are interested in
conversational state, not just in discrete 'stable states' of a
negotiation.

But I've never been to court over an electronic transaction, so my
view may be totally uninformed.

Walden

> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Friday, August 30, 2002 1:07 PM
> To: Paul Prescod
> Cc: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Evidence
> 
> 
> I'll respond to all the other messages here ...
> 
> On Fri, Aug 30, 2002 at 09:26:44AM -0700, Paul Prescod wrote:
> > > In the stateless case, you could just take the offending 
> message to
> > > court and leave everything else behind, because its meaning is
> > > independant of any conversation it may have been sent in.
> > 
> > You need the message plus all resources pointed to by the 
> message. If
> > the messages is "Yes I agree to the contract at 
> http://..../" then you
> > need http://.../ and you need it as it was at the time the 
> message was
> > sent (a good argument for signed, immutable resources in contractual
> > contexts).
> 
> No, I don't think you need representations of all the referenced
> resources, at least if you've done it right.  Using that example, it
> would be a mistake to agree to a contract by reference, because the
> contract may change by the time the message is processed.
> 
> The rule is, if the meaning of the message depends upon the result of
> dereferencing a URI, then this is stateful and a bad thing.
> 
> So while it would be fine to, say, send a list of contracts by URI
> for the simple purpose of enumerating them, it would not for the
> purpose of agreeing to them.  That's because in the former case, only
> their *identity* contributes to "meaning", whereas in the 
> latter, their
> *state* contributes to it.
> 
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2292
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-30 17:27:00
Subject:Re: [rest-discuss] Evidence
Message:

Mark Baker wrote:
> 
> I'll respond to all the other messages here ...
> 
>...
> 
> No, I don't think you need representations of all the referenced
> resources, at least if you've done it right.  Using that example, it
> would be a mistake to agree to a contract by reference, because the
> contract may change by the time the message is processed.

I'm not convinced that it is always practical to "inline" all relevant
state. But I'll let Bob "I know contracts" Haugen come up with a counter
example. Real-world contracts (and laws) do sometimes refer to each
other and we handle that by keeping historical copies of them around.

> The rule is, if the meaning of the message depends upon the result of
> dereferencing a URI, then this is stateful and a bad thing.

Okay, you have a stronger definition of stateful than I do. I agree that
where your model is practical it is better because it is easier to log,
more visible for intermediaries etc. But it feels like there are cases
where you would end up inlining a huge web of historical documents.
Nevertheless, your distinction of referencing identity versus
referencing state points out that EVERY link does not have to be
inlined. I'll have to think about some examples more.
-- 
 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2293
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-30 17:37:25
Subject:Re: [rest-discuss] When REST should and should not be used Was: Evidence
Message:

Sam Hunting wrote:
> 
>...
> 
> Well? What are some use cases where REST should not be used? Since I'm
> advocating a RESTful implementation of Linda tuple spaces, I'd like to
> know if my use cases falls into this category!

To be honest, probably not. ;) ;(

Here's why I say that: REST has its own kind of interaction model, just
as tuple spaces do. I think that putting one on top of the other will
degrade the benefits of both. It is a little like putting objects in a
relational databases or relations in an object database etc.

> > Understanding what those boundaries are (and I can't think of any)
> > would be very illuminating.
> 
> Hmmm... No cases where REST should not be used? This sounds like religious
> enthusiasm to me....

I believe that REST is not appropriate for first person shooters (as an
example). Performance would be a huge problem in trying to maintain
REST's statelessness. Realtime 3D video games cannot even afford to be
"stateless enough" to meet their own security requirements (that's why
the send extra information before it is needed and that informatio is
used by cheater software).
-- 
 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2294
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-30 17:45:14
Subject:Re: When REST should and should not be used Was: Evidence
Message:

Sam,

What is the difference between REST and tuple spaces? The APIs look 
suspiciously alike.

- itdp

--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
> Sam Hunting wrote:
> > 
> >...
> > 
> > Well? What are some use cases where REST should not be used? 
Since I'm
> > advocating a RESTful implementation of Linda tuple spaces, I'd 
like to
> > know if my use cases falls into this category!
> 
> To be honest, probably not. ;) ;(
> 
> Here's why I say that: REST has its own kind of interaction model, 
just
> as tuple spaces do. I think that putting one on top of the other 
will
> degrade the benefits of both. It is a little like putting objects 
in a
> relational databases or relations in an object database etc.
> 
> > > Understanding what those boundaries are (and I can't think of 
any)
> > > would be very illuminating.
> > 
> > Hmmm... No cases where REST should not be used? This sounds like 
religious
> > enthusiasm to me....
> 
> I believe that REST is not appropriate for first person shooters 
(as an
> example). Performance would be a huge problem in trying to maintain
> REST's statelessness. Realtime 3D video games cannot even afford to 
be
> "stateless enough" to meet their own security requirements (that's 
why
> the send extra information before it is needed and that informatio 
is
> used by cheater software).
> -- 
>  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2295
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-30 17:48:19
Subject:Re: Evidence
Message:

"Mathews, Walden" wrote:
> This is addressed to all who have contributed to the thread, not
> just Mark.  Are these ideas based on experience in some judicial
> system or another?  Or are they systems analysts views of where the
> authoritative data in a transaction *ought to* be found?
> 
> My own opinion, based on judges and arbitrators I have faced in
> contract matters, is that they want a context from which to judge
> what constitutes the contract in question, and they don't like
> other people constraining them in their judgment of how wide or
> narrow that context should be.
> 
> I think that judges and juries for that matter are interested in
> conversational state, not just in discrete 'stable states' of a
> negotiation.
> 
> But I've never been to court over an electronic transaction, so my
> view may be totally uninformed.

I posted some references to legal standards on 
http://internet.conveyor.com/RESTwiki/moin.cgi/PurchasingBusinessRequi
rements

Everything I know about this stuff came from working on ebXML, where 
we had several experts in legal aspects of electronic transations, 
including the chair of the ABA eCommerce committee.

One of the principles that I quoted on the Rest Wiki page advocated:
'Replicable and computable transaction state closure. In the 
foregoing context, "suitable proof" of the offer and acceptance 
events, means that determinable computation of the 
transaction's "success" or "failure" state must be replicable by both 
trading partners at run time, as well as third parties (such as a 
court) after the fact, using only artifacts transmitted within 
messages associated with the transaction.'

That's still a little ambiguous re the current discussion, and IANAL, 
and so will refrain from interpreting it further.

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:2296
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-30 17:49:36
Subject:RE: [rest-discuss] When REST should and should not be used Was: E vidence
Message:

REST was designated as an architecture, but there's an implied
development method akin to object design methods that we seem to be
applying in the name of REST.  Resource orientation might be the
name of that method.

Jackson problem frames are useful for selecting a method based
on the type of problem.  For those not familiar, the Information
Frame is about content-management, the Static Information Frame
is about read-only resources.  REST and resource orientation seem
well fitted to both.

The Control Frame is about making
something meet its specification, and I interpret Roy to say in
the dissertation that REST is less applicable to control problems
than information problems.  I think REST is also quite applicable
to Workpieces Frame problems, in which we are attempting to build
an electronic artifact such as a specification or a contract or
an order or a piece of electronic art.

Walden

> -----Original Message-----
> From: Sam Hunting [mailto:shunting@...]
> Sent: Friday, August 30, 2002 12:57 PM
> To: Jeffrey Winter
> Cc: Mark Baker; bhaugen32; rest-discuss@yahoogroups.com
> Subject: [rest-discuss] When REST should and should not be used Was:
> Evidence
> 
> 
> On Fri, 30 Aug 2002, Jeffrey Winter wrote:
> 
> > > > P.S. I think a lot of the current discussion focuses on 
> "how to do 
> > > > RPC in REST" rather than "use cases for which REST is a clear 
> > > > advantage".
> > > 
> > > Yep.
> > 
> > I think this mischaracterisizes the original discussion a 
> > bit.  The underlying issue was more along the lines of how 
> > to *avoid doing* RPC in REST.
> > 
> > If there are "use cases for which REST is a clear advantage," this 
> > would imply that there are cases where it isn't.  What are those
> > cases?
> 
> Well? What are some use cases where REST should not be used? Since I'm
> advocating a RESTful implementation of Linda tuple spaces, I'd like to
> know if my use cases falls into this category!
> 
> > Understanding what those boundaries are (and I can't think of any) 
> > would be very illuminating.
> 
> Hmmm... No cases where REST should not be used? This sounds 
> like religious
> enthusiasm to me....
> 
> Sam Hunting
> eTopicality, Inc.
> 
> --------------------------------------------------------------
> -------------
> "Turn your searching experience into a finding experience."(tm)
> 
> Topic map consulting and training: www.etopicality.com
> Free open source topic map tools:  www.goose-works.org
> 
> XML Topic Maps: Creating and Using Topic Maps for the Web.
> Addison-Wesley, ISBN 0-201-74960-2.
> --------------------------------------------------------------
> -------------
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2297
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-08-30 18:04:53
Subject:Re: [rest-discuss] Re: When REST should and should not be used Was: Evidence
Message:

> Sam,
> 
> What is the difference between REST and tuple spaces? The APIs look 
> suspiciously alike.

I would say the semantics of the tuples, I would say. I am not sure where
along the "stateful" "not stateful" constinuum tuples fall, though. Could
one make sense of a tuple, all on its own? I don't think that's
necessarily the case. Could one design a tuple format that was
self-describing (ie, not stateful)? I think so.

S.




> - itdp
> 
> --- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
> > Sam Hunting wrote:
> > > 
> > >...
> > > 
> > > Well? What are some use cases where REST should not be used? 
> Since I'm
> > > advocating a RESTful implementation of Linda tuple spaces, I'd 
> like to
> > > know if my use cases falls into this category!
> > 
> > To be honest, probably not. ;) ;(
> > 
> > Here's why I say that: REST has its own kind of interaction model, 
> just
> > as tuple spaces do. I think that putting one on top of the other 
> will
> > degrade the benefits of both. It is a little like putting objects 
> in a
> > relational databases or relations in an object database etc.
> > 
> > > > Understanding what those boundaries are (and I can't think of 
> any)
> > > > would be very illuminating.
> > > 
> > > Hmmm... No cases where REST should not be used? This sounds like 
> religious
> > > enthusiasm to me....
> > 
> > I believe that REST is not appropriate for first person shooters 
> (as an
> > example). Performance would be a huge problem in trying to maintain
> > REST's statelessness. Realtime 3D video games cannot even afford to 
> be
> > "stateless enough" to meet their own security requirements (that's 
> why
> > the send extra information before it is needed and that informatio 
> is
> > used by cheater software).
> > -- 
> >  Paul Prescod
> 
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.goose-works.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2298
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-30 18:06:05
Subject:Re: [rest-discuss] Evidence
Message:

"Mathews, Walden" wrote:
> 
> This is addressed to all who have contributed to the thread, not
> just Mark.  Are these ideas based on experience in some judicial
> system or another?  Or are they systems analysts views of where the
> authoritative data in a transaction *ought to* be found?

No, I have no experience with electronic legal contracts other than
simple B2C credit card transactions.

> My own opinion, based on judges and arbitrators I have faced in
> contract matters, is that they want a context from which to judge
> what constitutes the contract in question, and they don't like
> other people constraining them in their judgment of how wide or
> narrow that context should be.

The question is whether the system is designed so that their job is 

 a) doable
 b) relatively easy

Statelessness helps with both of these. If I can print out a single,
URI-addressble signed XML resource that describes a contract versus a
hundred RPC messages from a log, then I think they will prefer that. If
they also want to look at my HTTP logs and other probably irrelevant
resources then that's up to them.

> I think that judges and juries for that matter are interested in
> conversational state, not just in discrete 'stable states' of a
> negotiation.

In general I would expect them to focus on the final contract rather
than (for example) the hundreds of iterations that pass around during
negotiation. This will be even more the case when the "negotiators" are
computers and where the negotiations cannot be used as hints towards
human intent. Computers will also tend to use predefined contracts
because they aren't smart enough to write their own. Therefore the most
relevant question will often be: "Did you really agree to this
predefined contract or not?"
-- 
 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2299
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-30 18:10:28
Subject:Re: Evidence
Message:

Paul Prescod wrote:
> I'll let Bob "I know contracts" Haugen come up with a counter
> example. 

Oh no, I hope I'm not pretending to knowledge I don't have.
I am very interested in electronic contracts.
I worked with a couple of masters of the subject in ebXML.
I tried to learn everything I could, but am still a grasshopper.
I'm working on a project proposal which will try to use RESTified 
contracts if it goes through.

> Real-world contracts (and laws) do sometimes refer to each
> other and we handle that by keeping historical copies of them 
around.
> 
> > The rule is, if the meaning of the message depends upon the 
result of
> > dereferencing a URI, then this is stateful and a bad thing.
> 
> Okay, you have a stronger definition of stateful than I do. I agree 
that
> where your model is practical it is better because it is easier to 
log,
> more visible for intermediaries etc. But it feels like there are 
cases
> where you would end up inlining a huge web of historical documents.
> Nevertheless, your distinction of referencing identity versus
> referencing state points out that EVERY link does not have to be
> inlined. I'll have to think about some examples more.

I am still thinking about the alternatives, too.
But I think there is a distinction between "the meaning of the 
message" in the sense of its value as a speech act, that is, the 
values of its elements, and the "residual effect" of the message on 
the whole business conversation.

In other words, if I offer to buy your Porsche for $100, the meaning 
of my message is clear, but in context, it's absurd.

Likewise if the contract says "you will deliver 100 pairs of shoes at 
noon next Monday", and you send a Shipment Notification saying you're 
sending 50 pair on Tuesday, the meaning of the notification is clear, 
but it does not fulfill the contractual commitment.

So should the Shipment Notification contain the signed representation 
of the commitment? Or just refer to it?  If it refers to it, if the 
buyer changed it unilaterally from Tuesday to Monday and from 50 to 
100, how does the seller prove it?

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2300
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-08-30 18:15:42
Subject:Re: [rest-discuss] When REST should and should not be used Was: Evidence
Message:

> > Well? What are some use cases where REST should not be used? Since I'm
> > advocating a RESTful implementation of Linda tuple spaces, I'd like to
> > know if my use cases falls into this category!
> 
> To be honest, probably not. ;) ;(
> 
> Here's why I say that: REST has its own kind of interaction model, just
> as tuple spaces do. I think that putting one on top of the other will
> degrade the benefits of both. It is a little like putting objects in a
> relational databases or relations in an object database etc.

Hmmm... It may be that I am confusing a networked implementation using
typical networking protocols with a REST architecture (and its interaction
model). On the other hand, http GET looks a lot like Linda OUT. Couldn't
the Linda space be just another client? What benefits do you think will be
lost (to Linda and to REST) with this approach? (I am after massive
scaleability, I don't care about network latency) within reason.))

> > > Understanding what those boundaries are (and I can't think of any)
> > > would be very illuminating.
> > 
> > Hmmm... No cases where REST should not be used? This sounds like religious
> > enthusiasm to me....
> 
> I believe that REST is not appropriate for first person shooters (as an
> example). Performance would be a huge problem in trying to maintain
> REST's statelessness. Realtime 3D video games cannot even afford to be
> "stateless enough" to meet their own security requirements (that's why
> the send extra information before it is needed and that informatio is
> used by cheater software).

So it isn't network latency but the cost of expressing stateless messages
(if that is the right word) that is at issue. (Sounds like one wouldn't
write an authoring system with versioing RESTfully either, since it would
be simpler to send the diffs around rather than a complete document? If
that example isn't too crude....) 

Not sure about this notion of "messages" (?) being stateless (ie, being
context free? Or having their entire context with them??) It sounds a lot
like the old SGML issue of self-describing tag names ... Well, yes, they
were self-describing ... Up to a point determined by context (operational
definition: "that which I have to talk to a lot of people about but can
never pin down.")


Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.goose-works.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------








-----------------------------------------------------------------------------------
Post ID:2301
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-30 18:13:46
Subject:Re: [rest-discuss] Re: Evidence
Message:

bhaugen32 wrote:
> 
>...
> 
> Oh no, I hope I'm not pretending to knowledge I don't have.
> I am very interested in electronic contracts.
> I worked with a couple of masters of the subject in ebXML.
> I tried to learn everything I could, but am still a grasshopper.
> I'm working on a project proposal which will try to use RESTified
> contracts if it goes through.

There are very few people who have spent much time with electronic
contracts in open systems so you are still way ahead of most of us.
>...
> Likewise if the contract says "you will deliver 100 pairs of shoes at
> noon next Monday", and you send a Shipment Notification saying you're
> sending 50 pair on Tuesday, the meaning of the notification is clear,
> but it does not fulfill the contractual commitment.
> 
> So should the Shipment Notification contain the signed representation
> of the commitment? Or just refer to it?  If it refers to it, if the
> buyer changed it unilaterally from Tuesday to Monday and from 50 to
> 100, how does the seller prove it?

Here's how I would do it:

<ShipmentNotification>
  <Commitment uri="http://..../" signature="digital_hash"/>

  <dsig>...</dsig>
</ShipmentNotification>

If the hash doesn't match the resource then the resource has a different
state than when I agreed to it. It is not mathematically feasible to
change the state without breaking the hash.
-- 
 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2302
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-30 18:17:59
Subject:Re: Evidence
Message:

Paul Prescod wrote:
> > I think that judges and juries for that matter are interested in
> > conversational state, not just in discrete 'stable states' of a
> > negotiation.
> 
> In general I would expect them to focus on the final contract rather
> than (for example) the hundreds of iterations that pass around 
during
> negotiation. 

I agree with you about the final contract.

But the interesting issues in this present thread are not about the 
final contract, but the fulfillment of contractual commitments.

In other words, in the contract you committed to some future 
behavior. When you send a message concerning that future behavior, it 
will be governed by the contractual commitment.

So the message that is governed by the contractual commitment may be 
clear in its own contents, but it is not independent of the 
commitment in its business effect.

Therefore should it reference the commitment, or include it inline?

(Or something else?)

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:2303
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-08-30 18:26:10
Subject:Re: Evidence
Message:

Paul Prescod wrote:
> > So should the Shipment Notification contain the signed 
representation
> > of the commitment? Or just refer to it?  If it refers to it, if 
the
> > buyer changed it unilaterally from Tuesday to Monday and from 50 
to
> > 100, how does the seller prove it?
> 
> Here's how I would do it:
> 
> <ShipmentNotification>
>   <Commitment uri="http://..../" signature="digital_hash"/>
> 
>   <dsig>...</dsig>
> </ShipmentNotification>
> 
> If the hash doesn't match the resource then the resource has a 
different
> state than when I agreed to it. It is not mathematically feasible to
> change the state without breaking the hash.

Thanks! Why didn't I think of that?

But just to be picky, you can only hash a representation, right?
So you still have the requirement for a canonical representation to 
which to match the hash?










-----------------------------------------------------------------------------------
Post ID:2304
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-08-30 18:31:37
Subject:RE: [rest-discuss] When REST should and should not be used Was: Evidence
Message:

I think you hit upon a key point here. "Resource Orientation" is a great
phrase for what you need to do to work with Rest.  I think that's one of
the key reasons many developers (myself included) have such a hard time
getting their heads wrapped around REST.  We're used to Object-Oriented
Development, so SOAP/RPC is just a natural extension of that.  We try to
use REST and suddenly we are faced with a completely different paradigm,
Resource-Oriented Development.

Like it or not, I think that's one advantage SOAP/RPC will have over
REST.  Forcing Java/C++/C# developers to use one paradigm for their
regular development, and switch to another for their network-based
development is not very appealing. 

So, one "When REST should not be used" guideline could be: When you
don't want to force your developers to learn a new paradigm.

Toivo Lainevool

-----Original Message-----
From: Mathews, Walden [mailto:waldenm@...] 
Sent: Friday, August 30, 2002 10:50 AM
To: 'Sam Hunting'; Jeffrey Winter
Cc: Mark Baker; bhaugen32; rest-discuss@yahoogroups.com
Subject: RE: [rest-discuss] When REST should and should not be used Was:
Evidence

REST was designated as an architecture, but there's an implied
development method akin to object design methods that we seem to be
applying in the name of REST.  Resource orientation might be the
name of that method.










-----------------------------------------------------------------------------------
Post ID:2305
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-30 19:34:26
Subject:RE: [rest-discuss] Evidence
Message:

> > I think that judges and juries for that matter are interested in
> > conversational state, not just in discrete 'stable states' of a
> > negotiation.
> 
> In general I would expect them to focus on the final contract rather
> than (for example) the hundreds of iterations that pass around during
> negotiation. This will be even more the case when the 
> "negotiators" are
> computers and where the negotiations cannot be used as hints towards
> human intent. Computers will also tend to use predefined contracts
> because they aren't smart enough to write their own. 
> Therefore the most
> relevant question will often be: "Did you really agree to this
> predefined contract or not?"

We're not disagreeing here.  What I meant is that the harder part of
their job is deciding what constitutes the contract, and determining
that requires context outside the contract document itself, including
a certain amount of conversation.  But I agree that the focus is on
the final contract, i.e. what in their judgment constitutes that.  That
"did you really agree?" stuff may depend on what was said before the
signing.

Walden






-----------------------------------------------------------------------------------
Post ID:2306
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-08-30 19:47:02
Subject:RE: [rest-discuss] squaring (was Re:HTTP and safety)
Message:

> I don't know yet whether RPC and REST are on two sides of a 
> fence or two
> ends of a spectrum. Is submitting a "transfer order" an RPC 
> (because the
> meaning is embedded in the message)? Well let's just say we 
> can move it
> pretty far to the REST side of the spectrum if we:
> 
>  * make the order addressable so that it can be referred to by anyone,
> anytime
>  * describe the transfer order in an XML or RDF schema, in as 
> rich a way
> as possible
>  * make the URI for "submit transfer order for this account" 
> a hyperlink
> from the account object
>  * separate the URI for "submit transfer order" from the URIs for "pay
> bills from this account" and "get information about this account" and
> "withdraw money from this account"
>  * if transfer orders can be removed, updated or read, use 
> standard HTTP
> methods to do so
>  * make a GET on the URI for "submit transfer order" return something
> that lists the current orders and perhaps describes what will happen
> when new orders are submitted (prose or machine readable?)
> 
> Hopefully these will help someone.

One of the (beneficial?) side effects of approaching a Control Frame
problem from the perspective of an Information Frame is that the
control process inherits the property of self-annotation.  I think of it
this way.  If you use Quicken to record your bank transactions after
they've gone through, you are just building an information system.  If you
use Quicken to record your bank transactions *before* they go through
instead of after, you're still dealing with the same information, but
you're using it both to effect the work and to record it.  An augmented
information system serves as a control system.  The examples that look
the most unabashedly like RPC are the ones in which we don't care if
records are kept of the actions or not.

Walden






-----------------------------------------------------------------------------------
Post ID:2307
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-30 21:19:08
Subject:Re: [rest-discuss] When REST should and should not be used Was: Evidence
Message:

Toivo \"Deutsch\" Lainevool wrote:
> 
> I think you hit upon a key point here. "Resource Orientation" is a great
> phrase for what you need to do to work with Rest.  I think that's one of
> the key reasons many developers (myself included) have such a hard time
> getting their heads wrapped around REST.  We're used to Object-Oriented
> Development, so SOAP/RPC is just a natural extension of that.  We try to
> use REST and suddenly we are faced with a completely different paradigm,
> Resource-Oriented Development.

Jeff Bone: "It's a *really attractive*
proposition to the OOP / IT guys to think of taking an existing object
model and, with no or minimal Web-specific "glue", simply exporting
those interfaces to the Web."

http://www.xent.com/pipermail/fork/2001-August/002801.html

(it's been an interesting year for REST)

Anyhow, if people can succeed at doing standard OO over the network,
more power to them. Why learn REST if you don't have to. But most of us
believe that just exporting the OO local style to the Web will not work. 

 * http://www.javatech.dk/javatech2/slides/Jini/img8.html

 * http://research.sun.com/techrep/1994/abstract-29.html

Interestingly, there are roughly three main camps in the web services
world, RPC, "messaging" (I use scare quotes because the term doesn't
seem to be very well defined) and REST. Standard OO (with addressable
object interfaces and type-specific interfaces) isn't really represented
at all. Procedural, single-endpoint RPC may "seem like" the closest
pattern but its limitations are also the most obvious and severe.
-- 
 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2308
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-30 21:29:31
Subject:Re: When REST should and should not be used Was: Evidence
Message:

This seems like the wrong tack to take. On close analaysis, Resource 
Oriented Programming is far more object oriented than SOAP/RPC. In 
fact there's a strong case to be made that ROP is a degenerate case 
of OOP, simplified and constrained in order to meet the scalability 
requirements of internet class applications. 


-itdp


--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
> Toivo \"Deutsch\" Lainevool wrote:
> > 
> > I think you hit upon a key point here. "Resource Orientation" is 
a great
> > phrase for what you need to do to work with Rest.  I think that's 
one of
> > the key reasons many developers (myself included) have such a 
hard time
> > getting their heads wrapped around REST.  We're used to Object-
Oriented
> > Development, so SOAP/RPC is just a natural extension of that.  We 
try to
> > use REST and suddenly we are faced with a completely different 
paradigm,
> > Resource-Oriented Development.
> 
> Jeff Bone: "It's a *really attractive*
> proposition to the OOP / IT guys to think of taking an existing 
object
> model and, with no or minimal Web-specific "glue", simply exporting
> those interfaces to the Web."
> 
> http://www.xent.com/pipermail/fork/2001-August/002801.html
> 
> (it's been an interesting year for REST)
> 
> Anyhow, if people can succeed at doing standard OO over the network,
> more power to them. Why learn REST if you don't have to. But most 
of us
> believe that just exporting the OO local style to the Web will not 
work. 
> 
>  * http://www.javatech.dk/javatech2/slides/Jini/img8.html
> 
>  * http://research.sun.com/techrep/1994/abstract-29.html
> 
> Interestingly, there are roughly three main camps in the web 
services
> world, RPC, "messaging" (I use scare quotes because the term doesn't
> seem to be very well defined) and REST. Standard OO (with 
addressable
> object interfaces and type-specific interfaces) isn't really 
represented
> at all. Procedural, single-endpoint RPC may "seem like" the closest
> pattern but its limitations are also the most obvious and severe.
> -- 
>  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2309
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-08-30 21:51:14
Subject:RE: [rest-discuss] When REST should and should not be used Was: Evidence
Message:

Like most issues in software development this isn't a black or white
issue.  I don't think its right to say that "REST is better than RPC" or
"RPC is better than REST".  It really depends on context.  Sometimes one
makes sense, sometimes the other does.  If you're integrating a bunch of
legacy apps, SOAP/RPC probably makes more sense than REST.  If you're
publishing a widely available, general interest service on the Web, REST
probably makes sense.

I don't consider myself a strong advocate of either view.  Being in one
"camp" seems like a religious war that can never be won.  I think the
proper way to proceed is to clearly enumerate the strengths and
weaknesses of all approaches and then provide guidelines on when to use
which architectural style.  Sounds like it might be a good article :)

Toivo Lainevool

> -----Original Message-----
> From: Paul Prescod [mailto:paul@...]
 
> Interestingly, there are roughly three main camps in the web services
> world, RPC, "messaging" (I use scare quotes because the term doesn't
> seem to be very well defined) and REST. Standard OO (with addressable
> object interfaces and type-specific interfaces) isn't really
represented
> at all. Procedural, single-endpoint RPC may "seem like" the closest
> pattern but its limitations are also the most obvious and severe.
> --
>  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2310
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-08-30 21:54:33
Subject:RE: [rest-discuss] Re: When REST should and should not be used Was: Evidence
Message:

I would disagree.  ROP degenerates OOP so much that it ceases to be OOP.
The whole idea behind OOP is that you have objects, and you create
methods(verbs) on the objects. In ROP, you have only four verbs
(methods).  You lose the whole intent of OOP when you do this.  If you
tell a developer "OK, use Java but every object is only allowed to have
four methods: Get, Put, Post and Delete" what you would end up with
isn't anything like a good OO design.

SOAP/RPC is much more closely aligned with OO.  It comes out of
"Component Based" architectures like CORBA and DCOM.  It's easy for
developers to make the jump from objects/methods to Web
services/operations.  There are lots of tools that automatically do the
mapping between OOPLs and SOAP/RPC.  I have yet to see a tool that does
this for REST.

With REST you can't just take any Java/C++/C# Object and turn it into an
easily used network accessible "thing".

An analogy might help here.  Saying ROP is like a degenerate case of OOP
is like saying Structured Programming is a degenerate case of OOP.  Sure
you can use C++ or Java and do structured programming, but then you're
not doing OOP.  Structured Programming and OOP are different paradigms.

I maintain that OO and RO are different development paradigms.  I would
love to be wrong though, it would make things a whole lot easier.

Toivo

> -----Original Message-----
> From: inthedarkplace
> 
> 
> This seems like the wrong tack to take. On close analaysis, Resource
> Oriented Programming is far more object oriented than SOAP/RPC. In
> fact there's a strong case to be made that ROP is a degenerate case
> of OOP, simplified and constrained in order to meet the scalability
> requirements of internet class applications.
> 
> 
> -itdp
> 
> 








-----------------------------------------------------------------------------------
Post ID:2311
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-08-31 03:26:38
Subject:Re: [rest-discuss] Re: When REST should and should not be used Was: Evidence
Message:

----- Original Message -----
>
> With REST you can't just take any Java/C++/C# Object and turn it into an
> easily used network accessible "thing".

With RPC, you can't just take any file system/database/directory service and
turn it into an easily used, interoperable network accessible 'thing'.








-----------------------------------------------------------------------------------
Post ID:2312
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-08-31 03:45:42
Subject:Re: When REST should and should not be used Was: Evidence
Message:

--- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote:
> 
> ----- Original Message -----
> >
> > With REST you can't just take any Java/C++/C# Object and turn it 
into an
> > easily used network accessible "thing".

Actually you can and I do it all the time. I have automated tools 
which can automagically generate the REST code given an object's 
class. Also note that SOAP services are stateless. By definition they 
are not objects. Resources have states and they expose methods 
(DoGet, DoPut, DoDelete, DoPost, DoTrace, DoOptions) which constitute 
behavior. After having done a lot of SOAP and REST hacking it's 
evident to me and my team that REST is far more object oriented than 
SOAP. In REST you work with real objects, in SOAP you're essentially 
working with a class that defines arbitrary static methods.

> With RPC, you can't just take any file system/database/directory 
service and
> turn it into an easily used, interoperable network 
accessible 'thing'.







-----------------------------------------------------------------------------------
Post ID:2313
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-08-31 21:59:58
Subject:Re: [rest-discuss] Re: When REST should and should not be used Was: Evidence
Message:

"S. Mike Dierken" wrote:
> 
> ----- Original Message -----
> >
> > With REST you can't just take any Java/C++/C# Object and turn it into an
> > easily used network accessible "thing".
> 
> With RPC, you can't just take any file system/database/directory service and
> turn it into an easily used, interoperable network accessible 'thing'.

These terms are pretty vaguely defined so let's be concrete: using
Visual Studio.NET and most other RPC-oriented Web services toolkits, you
can take an object and turn it into a service automatically ONLY IF the
object has only static methods -- in other words if it uses a
procedural, not object oriented, model.
-- 
 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2314
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-01 03:13:46
Subject:Re: [rest-discuss] Re: Evidence
Message:

On Fri, Aug 30, 2002 at 06:17:59PM -0000, bhaugen32 wrote:
> But the interesting issues in this present thread are not about the 
> final contract, but the fulfillment of contractual commitments.
> 
> In other words, in the contract you committed to some future 
> behavior. When you send a message concerning that future behavior, it 
> will be governed by the contractual commitment.
> 
> So the message that is governed by the contractual commitment may be 
> clear in its own contents, but it is not independent of the 
> commitment in its business effect.
> 
> Therefore should it reference the commitment, or include it inline?

I'd say the reference.

I just talked to my wife (a lawyer) about this, and what we discussed
pretty much jives with what I've said in this thread.  Basically, if one
contract depends on some detail of another, then either a) reference it
if the referencing system can guarantee that dereferencing it will
always produce the identical contract, or b) include the other contract
as an attachment.  She said it's easier to include as an attachment than
to try to cut and paste chunks out of it, because some context may get
lost in doing so.

The difference there from my previous statements, is that it's safe to
use a reference in the case where the details of the other contract
matter, iff it can be guaranteed to always refer to exactly that
contract.

Maybe some examples would help ...

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2315
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-09-01 03:39:01
Subject:Re: [rest-discuss] Re: When REST should and should not be used Was: Evidence
Message:

Still in my enthusiastic newbie mode:

IO note that W3C's Technical Architecture group seems to have blessed RST
big-time in "Architectural Principles of the World Wide Web" at:

   http://www.w3.org/TR/2002/WD-webarch-20020830/ 
   
<quote>
As mentioned in the introduction, the Web is designed to create the
large-scale effect of a shared information space that scales well and
behaves predictably. The architectural style known as Representational
State Transfer [REST] encapsulates this notion of a shared information
space.
</quote>

But I keep searching for implementations of RESTful web service --
preferably in Python. Could someone elaborate on REST's relation to the
"Simple Web Services API" at:

    http://aspn.activestate.com/ASPN/WebServices/SWSAPI/spec

And point some other examples than (SOAPy) Amazon and Google? I'm my own
boss, so I won't fire me if I don't use SOAP.

Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.goose-works.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2316
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-01 03:59:15
Subject:Re: [rest-discuss] Re: Evidence
Message:

Oops, missed this.  On to the examples ...

> > In the stateless case, you could just take the offending message to
> > court and leave everything else behind, because its meaning is
> > independant of any conversation it may have been sent in.
> 
> Depending on what you mean, that gets tricky.  
> Simple case:  shipment notification is dependent on order line which 
> it purports to fulfill.  Claims of non-fulfillment would need both 
> the shipment notification and the order line.

Ok, I see what you're getting it.  It's not any profound issue, it's
just a misinterpretation of what I was saying about only needing to
take one message to court.

In fact, you always need to take two things to court; the contract,
and proof of breach.  My point, which was obviously poorly stated, is
that proof of breach can be demonstrated with a single message (the
shipment notification, as I understand what one is).  Of course, proof
of a entering into a contract should also be able to be demonstrated
with a single message too.

> More complex case:  non-fulfillment is covered by a long term 
> contract which provides penalties.  So now the long-term contract 
> clause must be stated as well.

Ok, but the messages that establish expectation of fulfillment, and
notify about fulfillment both mean the same thing independant of the
details of any contract that exists.  But its meaning *does* depend
upon the existence of such a contract, so you'd want to reference it.
Presumably any standard format for this info would have a way to
reference one or more non-fullfillment contracts - is that the
case?

> Are these ideas relevant to the issue raise?

Yep.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2317
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-09-01 16:00:21
Subject:Re: Evidence
Message:

Mark Baker 
> I just talked to my wife (a lawyer) about this, and what we 
discussed
> pretty much jives with what I've said in this thread.  

Please pass on thanks to your wife.

> Basically, if one
> contract depends on some detail of another, then either a) 
reference it
> if the referencing system can guarantee that dereferencing it will
> always produce the identical contract, or b) include the other 
contract
> as an attachment.  She said it's easier to include as an attachment 
than
> to try to cut and paste chunks out of it, because some context may 
get
> lost in doing so.

That's different from the situation I thought we were discussing.
(Although some of the same principles would apply.)

The two situations:
1. One contract refers to another contract (as above).
2. Messages about contract fulfillment events (e.g. deliveries of 
goods and services or payments) refer to governing contract clauses 
(as I thought we were discussing).

The usual practice with deliveries is to refer to the governing 
contract (e.g. purchase order) by order ID (maybe + line number), not 
to attach the whole PO.  I expect the same would work for REST.

> The difference there from my previous statements, is that it's safe 
to
> use a reference in the case where the details of the other contract
> matter, iff it can be guaranteed to always refer to exactly that
> contract.

Yes, and don't you think something like Paul's reference format (URI 
+ hash) is the way to do it?

> Maybe some examples would help ...

Coming up...

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:2318
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-09-01 16:20:30
Subject:Re: Evidence
Message:

Mark Baker wrote:
> In fact, you always need to take two things to court; the contract,
> and proof of breach.  My point, which was obviously poorly stated, 
is
> that proof of breach can be demonstrated with a single message (the
> shipment notification, as I understand what one is).  Of course, 
proof
> of a entering into a contract should also be able to be demonstrated
> with a single message too.

A. "Proof" is too strong a word; "evidence" is as good as you get.
B. A contract is an agreement between at least two parties.
Evidence of binding a contract using an electronic offer-acceptance 
protocol might require at least two messages:  
one with the offer, signed by the offerer; 
another with the acceptance, referring to the offer (with URI + 
hash), signed by the acceptor.
If the acceptance message contained the whole canonical 
representation of the offer plus the hash plus the acceptance element 
plus the acceptor's digital signature, then maybe one message would 
do. 
But there are reasons not to do that:  for example, the timing of 
messages, rules for contract formation, receipt acknowledgments, etc. 
may also be important depending on how formal it's worth being.

Likewise the evidence of performance of committed events is also 
stronger if both parties agree that the event was performed as 
notified.  (Which again requires at least two messages.)

For example, it's much easier to send a shipment notification than to 
actually deliver the goods in good shape and time. The business 
protocol needs to allow for receiving discrepancies.

All of the above are reasons why business deals are conversations 
where almost every statement refers to previous statements.  And 
requires the previous statements for complete interpretation of its 
meaning-in-context.

It's like there's at least two levels of meaning:  
1. the content of the message - the values of its elements, and
2. its residual effect on the business deal in which it is embedded.

I have always taken the REST "stateless" rule in sense #1.
In other words, put all the element values plainly inline the message.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2319
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-01 17:40:51
Subject:Re: [rest-discuss] Re: When REST should and should not be used Was:Evidence
Message:

Sam Hunting wrote:
> 
> ...
> 
> But I keep searching for implementations of RESTful web service --
> preferably in Python. Could someone elaborate on REST's relation to the
> "Simple Web Services API" at:
> 
>     http://aspn.activestate.com/ASPN/WebServices/SWSAPI/spec

No relationship. That was a project I did for a customer unrelated to
REST and before I understood much REST.

> And point some other examples than (SOAPy) Amazon and Google? I'm my own
> boss, so I won't fire me if I don't use SOAP.

Roughly speaking, systems which make good use of HTTP and URIs are REST
systems. So for instance your favorite travel site probably uses REST to
an extent. Or your favorite discussion group. For various practical
reasons many sites fall short of REST perfection but that's true with
any paradigm. Reality does intervene so sometimes otherwise REST-ful
services will abuse URIs or cookies etc.

In terms of combinations of REST and XML, most of them are read-only.
Public examples include:

 * the Xoomle variant of the Google API (which is basically a
realization of [1]).
 * the entire RSS subset of the Web (which constitutes a sophisticated
information system in its own right)
 * the Amazon REST (not SOAP) API
 * the SOAPBuilders test reporting API

[1] http://www.xml.com/pub/a/2002/04/24/google.html
-- 
 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2320
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-09-01 19:48:02
Subject:Re: [rest-discuss] Re: When REST should and should not be used Was:Evidence
Message:

Paul Prescod wrote:
>>And point some other examples than (SOAPy) Amazon and Google? I'm my own
>>boss, so I won't fire me if I don't use SOAP.

well, i think groups.yahoo.com is quite RESTful, in a read-only way.  as
was egroups before it.  an example of the 'reality' paul mentioned would
be the way it sticks ads in when you're viewing posts.

also look at http://nntp.x.perl.org/ .  that's a nice interface to an
archive of all perl mailing lists.  i think it's RESTful as well, in a
read-only way.







-----------------------------------------------------------------------------------
Post ID:2321
Sender:"Yannick Loiseau" <yloiseau@...>
Post Date/Time:2002-09-01 22:49:12
Subject:Hierarchical resources
Message:

hie all,
I know that this subject has already been discussed, but to summarize:
How to represent hierarchical resources restfully?
Here is the structure:

/root
  +-- group 1
  |      +-- attribute 1.a
  |      |
  |      +-- element 1.1
  |      |      +-- attribute 1.1.a
  |      |      |
  |      |      +-- attribute 1.1.b
  |      |
  |      +-- element 1.2
  |      |      +-- ....
  |      +-- ...
  |
  +-- group 2
  |      |
  |      + element 2.1
  |      |
  |      +-- ...
  |
  +-- ...

 This could be an ldap directory (e.g address book) for example, or an 'ls
-R' of an FTP server. The root url will be : http://my.server.com/root
 I think there is some points to consider:
    * What this url should return: some information about the resource, or a
listing of its contents (groups). If a listing is allowed, this raise the
recursive issue. Is recursively restful. I thought about these solutions:
            1.  <root>
                    some information
                    <group1 xlink:href="url/to/group.1" />
                    <group2 xlink:href="url/to/group.2" />
                    ...
                </root>

            2.a <root>
                    <group1>
                        <attribute1a>value</attribute1a>
                        <element11 xlink:href="url/to/element.1.1"/>
                        ...
                    <group2>...</group2>
                    ...
                </root>
            2.b <root>
                    <group1 attribute1a="value">
                        <element11 xlink:href="url/to/element.1.1"/>
                        ...
                    <group2>...</group2>
                    ...
                </root>

            3   <root>
                    <group1>
                        <attribute1a>value</attribute1a>
                        <element11>
                            <attribute11a>value</attribute11a>
                        </element11>
                        ...
                    <group2>...</group2>
                    ...
                </root>

    Note that they could be 3.b with attribute values as ``real" xml
attributes, but this difference (between 2.a and 2.b is an other debate). I
think the first solution is the more restful one. But I'd like to be able to
save the resources for a local access, and to avoid to have to save
multiples files, making links relatives, etc. This explain the 3rd solution
(the 2nd one is just un hybrid, which is not very useful :) The question is:
is it correct to make the 3rd solution available at
http://my.server.com/root?recursive=true or
http://my.server.com/root?recursive=2 where recursive=0 is the 1rst solution
and recursive=1 the second one.

    * The other issue is: what should be the url to groups and elements (and
possibly attributes).
        1. http://my.server.com/root/group1/element11
        2. http://my.server.com/root?group=1&element=11
        3. without the hierarchy http://my.server.com/root?attribute=11a
directly

    and is an hybrid solution possible (e.g
http://my.server.com/root/group1?element=11, or
http://my.server.com/root/group1/element11?attribute=11a)

    I think that the path form (1) is better for access, since the query one
(3) is better for search queries.

    To be more concrete, suppose that groups are contacts 'groups (which
attribute is a description), elements are contacts and attributes are mail
address, phone number, name and description. The goal is to allow the access
to coordinates, groups or contacts (e.g a ldap gateway) and to save them to
a single file (see first point) to local access.









-----------------------------------------------------------------------------------
Post ID:2322
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-02 03:56:46
Subject:Re: [rest-discuss] Hierarchical resources
Message:

Separate the addressing from the XML representation.

The difference between <group1 attribute1a="value"> and
<group1><attribute1a>value</attribute1a></group1> is a personal preference -
unless you are conforming to someone else's schema/structure.

If the goal is 'to allow the access to coordinates, groups or contacts (e.g
a ldap gateway) and to save them to a single file (see first point) to local
access' then your addressing doesn't have to directly mimic the storage
structure - the addressing will reflect the needs of getting a lot or small
amount of information and preserving links to other information.
That is where your recursive=2 comes from (I'd use 'depth=2' as a name by
the way, just for fun and DAV mimicry).

>     * The other issue is: what should be the url to groups and elements
(and possibly attributes).
You might try using local references (uri references, or 'fragments') via
the '#' url character. If generating a representation of an attribute is
moderately expensive, it may be better to return the whole element and allow
addressing into this representation.
http://my.server.com/root?group=1&element=11#attribute11a
This returns a represenation of http://my.server.com/root?group=1&element=11
and the local application needs to find the #attribute11a.





----- Original Message -----
From: "Yannick Loiseau" <yloiseau@...>
To: <rest-discuss@yahoogroups.com>
Sent: Sunday, September 01, 2002 3:49 PM
Subject: [rest-discuss] Hierarchical resources


> hie all,
> I know that this subject has already been discussed, but to summarize:
> How to represent hierarchical resources restfully?
> Here is the structure:
>
> /root
>   +-- group 1
>   |      +-- attribute 1.a
>   |      |
>   |      +-- element 1.1
>   |      |      +-- attribute 1.1.a
>   |      |      |
>   |      |      +-- attribute 1.1.b
>   |      |
>   |      +-- element 1.2
>   |      |      +-- ....
>   |      +-- ...
>   |
>   +-- group 2
>   |      |
>   |      + element 2.1
>   |      |
>   |      +-- ...
>   |
>   +-- ...
>
>  This could be an ldap directory (e.g address book) for example, or an 'ls
> -R' of an FTP server. The root url will be : http://my.server.com/root
>  I think there is some points to consider:
>     * What this url should return: some information about the resource, or
a
> listing of its contents (groups). If a listing is allowed, this raise the
> recursive issue. Is recursively restful. I thought about these solutions:
>             1.  <root>
>                     some information
>                     <group1 xlink:href="url/to/group.1" />
>                     <group2 xlink:href="url/to/group.2" />
>                     ...
>                 </root>
>
>             2.a <root>
>                     <group1>
>                         <attribute1a>value</attribute1a>
>                         <element11 xlink:href="url/to/element.1.1"/>
>                         ...
>                     <group2>...</group2>
>                     ...
>                 </root>
>             2.b <root>
>                     <group1 attribute1a="value">
>                         <element11 xlink:href="url/to/element.1.1"/>
>                         ...
>                     <group2>...</group2>
>                     ...
>                 </root>
>
>             3   <root>
>                     <group1>
>                         <attribute1a>value</attribute1a>
>                         <element11>
>                             <attribute11a>value</attribute11a>
>                         </element11>
>                         ...
>                     <group2>...</group2>
>                     ...
>                 </root>
>
>     Note that they could be 3.b with attribute values as ``real" xml
> attributes, but this difference (between 2.a and 2.b is an other debate).
I
> think the first solution is the more restful one. But I'd like to be able
to
> save the resources for a local access, and to avoid to have to save
> multiples files, making links relatives, etc. This explain the 3rd
solution
> (the 2nd one is just un hybrid, which is not very useful :) The question
is:
> is it correct to make the 3rd solution available at
> http://my.server.com/root?recursive=true or
> http://my.server.com/root?recursive=2 where recursive=0 is the 1rst
solution
> and recursive=1 the second one.
>
>     * The other issue is: what should be the url to groups and elements
(and
> possibly attributes).
>         1. http://my.server.com/root/group1/element11
>         2. http://my.server.com/root?group=1&element=11
>         3. without the hierarchy http://my.server.com/root?attribute=11a
> directly
>
>     and is an hybrid solution possible (e.g
> http://my.server.com/root/group1?element=11, or
> http://my.server.com/root/group1/element11?attribute=11a)
>
>     I think that the path form (1) is better for access, since the query
one
> (3) is better for search queries.
>
>     To be more concrete, suppose that groups are contacts 'groups (which
> attribute is a description), elements are contacts and attributes are mail
> address, phone number, name and description. The goal is to allow the
access
> to coordinates, groups or contacts (e.g a ldap gateway) and to save them
to
> a single file (see first point) to local access.
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>






-----------------------------------------------------------------------------------
Post ID:2323
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-09-02 20:15:07
Subject:TrackBack
Message:

Has anybody played with and/or analyzed Moveable Type's TrackBack 
feature?
http://www.movabletype.org/docs/mtmanual_trackback.html

It appears to support URI-based conversations.

It claims to use REST:
"TrackBack uses a REST model for its pings in order to ensure that 
each TrackBack item has a unique URL (by the numeric ID of the 
TrackBack item)."

"Sending a ping
A request is made through HTTP GET to the ping URL..."

But then appears to use GET for a side effect:
"When a ping is sent to a TrackBack item on your site, in addition to 
saving the ping in the Movable Type database, the system updates an 
RSS feed for the TrackBack item."

Did I misunderstand?









-----------------------------------------------------------------------------------
Post ID:2324
Sender:"jmay" <jmay@...>
Post Date/Time:2002-09-02 23:34:15
Subject:Re: Hierarchical resources
Message:

I don't believe that the REST style makes any recommendation regarding
how resources should be represented as URIs.  There is no "correct"
answer, or even a "best" answer.  It all depends on your application.

Doctrine says: URIs should be considered as opaque.  A URI like
http://my.server.com/x742q/32ij5 might refer to "sub-element foo of
sub-element bar of element xyzzy".  Or not.

Certainly I don't recommend explicit opaqueness as the Right approach
in all cases.  Embedding meaning in URIs can often be helpful, and
improve application performance by avoiding the need for extra lookups
in your code.  But this is outside of the scope of REST.

Appropriate punctuation (/ and ? and &) may be driven by your
application as well.  Is the structure pre-defined, or does it grow
and change over time?  Is the concept of searching even relevant, and
can searches be made over sub-trees as well as the whole hierarchy? 
Are attributes defined from a fixed set, or are these variable as well?

There's no right answer here.

-Jason



--- In rest-discuss@y..., "Yannick Loiseau" <yloiseau@f...> wrote:
> How to represent hierarchical resources restfully?
> [lengthy post snipped]








-----------------------------------------------------------------------------------
Post ID:2325
Sender:"qchong" <qkc509@...>
Post Date/Time:2002-09-01 22:17:41
Subject:REST + web services composition
Message:

Hello, 
I would like to know if anyone has considered how multiple web 
services could be composed and coordinated together under the REST 
architecture.  Specifically:

1. What form would the representation of service composition take?
2. How to handle dynamic binding of multiple services within a 
session, given that REST is a stateless and asynchronous model?
3. How to automate service discovery, invocation (possibly using 
ontology-aware agents?), and execution completion notification, with 
provision for graceful recovery from a failed composite service 
execution?

In a simple composition model, a client (or possibly a coordinator 
service) would be responsible for obtaining URLs of the service 
providers, invoking them in some order, and converting responses from 
one provider into a parameter that would go into the request message 
to the other providers.  Some way of specifiying  how to tranform 
between representations would be necessary.  Also, this means that 
the client (or coordinator) would be responsible for monitoring the 
state of the service composition process.   

What are the kinds of compositions that would work best under REST? 








-----------------------------------------------------------------------------------
Post ID:2326
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-09-03 00:44:08
Subject:Re: [rest-discuss] Re: Hierarchical resources
Message:

On Monday, September 2, 2002, at 06:34  PM, jmay wrote:

> Certainly I don't recommend explicit opaqueness as the Right approach
> in all cases.  Embedding meaning in URIs can often be helpful, and
> improve application performance by avoiding the need for extra lookups
> in your code.  But this is outside of the scope of REST.

By definition.  But definitions are created by people, and people are 
fallible.

Opaqueness is dogma, but it's not necessarily good engineering.  I 
don't want to start another philosophical debate, but suffice to say 
that there are times when embedding information in URI is the path of 
least resistance (at worst) or perhaps even the best solution to the 
problem.

Dogma evolves, and is (hopefully) eventually replaced by engineering 
and best practices.

jb








-----------------------------------------------------------------------------------
Post ID:2327
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-09-03 01:31:15
Subject:RE: [rest-discuss] Re: When REST should and should not be used Was: Evidence
Message:

Where do you get the idea that SOAP services are stateless?  I don't
think there is any mention of state or statelessness in the SOAP spec.
I think a SOAP service can be just as statefull as a REST resource.  Am
I missing something here?

I'm also not sure what you mean by "By definition [SOAP Services] are no
objects".  I don't want to get argument about what an object is or
isn't, but SOAP services are something you can use for doing object
oriented decomposition of a problem, whether or not its stateless.

Toivo

> -----Original Message-----
> From: inthedarkplace [mailto:inthedarkplace@...]
> > >
> > > With REST you can't just take any Java/C++/C# Object and turn it
> into an
> > > easily used network accessible "thing".
> 
> Actually you can and I do it all the time. I have automated tools
> which can automagically generate the REST code given an object's
> class. Also note that SOAP services are stateless. By definition they
> are not objects. Resources have states and they expose methods
> (DoGet, DoPut, DoDelete, DoPost, DoTrace, DoOptions) which constitute
> behavior. After having done a lot of SOAP and REST hacking it's
> evident to me and my team that REST is far more object oriented than
> SOAP. In REST you work with real objects, in SOAP you're essentially
> working with a class that defines arbitrary static methods.








-----------------------------------------------------------------------------------
Post ID:2328
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-03 02:53:35
Subject:Re: [rest-discuss] Re: When REST should and should not be used Was: Evidence
Message:

Toivo \"Deutsch\" Lainevool wrote:
> 
> Where do you get the idea that SOAP services are stateless?  I don't
> think there is any mention of state or statelessness in the SOAP spec.

The SOAP specification is almost completely descriptive, not
prescriptive.

In other words, it doesn't provide enough guidance to actually build
applications that interoperate. Therefore we have to look into the tools
for the true definition of "what is SOAP". 

 * http://www.prescod.net/rest/rest_vs_soap_overview/#section_4.4

> I'm also not sure what you mean by "By definition [SOAP Services] are no
> objects".  I don't want to get argument about what an object is or
> isn't, but SOAP services are something you can use for doing object
> oriented decomposition of a problem, whether or not its stateless.

But are there SOAP clients and server toolkits that make it practical to
do object oriented decomposition, including the creation and destruction
of objects and the referencing of one object from another?
-- 
 Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2329
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-09-03 02:43:13
Subject:Re: [rest-discuss] REST + web services composition
Message:

On Sunday, September 1, 2002, at 05:17  PM, qchong wrote:

> In a simple composition model, a client (or possibly a coordinator
> service) would be responsible for obtaining URLs of the service
> providers, invoking them in some order,

There's the rub --- appropriate order to method invocation implies a 
stateful model.  My suspicion --- though I haven't been able to prove 
it in a generic and formal way --- is that every stateful composition 
can be remodeled as a series of generic operations on a larger number 
of resources, mostly eliminating the compositional complexity.  Think 
UNIX pipes / dataflow composition instead of OOP...

jb








-----------------------------------------------------------------------------------
Post ID:2330
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-09-03 04:01:20
Subject:ROP vs RPC vs OOP pt 1
Message:

Toivo,

I'm sorry Toivo, I understand your confusion I think. It stems from 
the way the words 'state' and 'stateful' have been so hopelessly 
overloaded.

In REST it is very clear what state means. You have resources located 
at URIs and performing a GET on these resources retrieves a 
representation of their state. There is no analogy to SOAP. 

As Paul hinted earlier, a SOAP service is nothing but a bunch of 
static methods being called through XML over HTTP. There is no 
fundamental notion of state. SOAP can maintain state through cookies 
and similar mechanisms but this is a poor substitute.

Why is this important?

This debate was originally about which methodology was more object 
oriented. I was trying to demonstrate that REST is far more object 
oriented than SOAP ever will be.

Here are my thoughts on REST and Resource Oriented Programming. This 
email is very long so don't read it if you're in a hurry :)

1) Resources are objects. They expose methods (DoGet, DoPut, 
DoDelete, DoPost, DoOptions, and DoTrace) which define a behavior and 
they possess a well-defined and meaningful state.

2) Because all resources expose the same five methods polymorphism is 
implicit. If you define a type of user and I want to retrieve 
information about your type of user I call GET url($User). If I want 
to update the representation of that user I call PUT url($User). If 
later, Idecide to take your user resource type and extend it by 
adding fields then the API does not change. To read the new user 
subclass you call GET. To update it, you call PUT.

3) The five methods (discounting HEAD) exposed by HTTP can 
collectively describe any given set of traditional OO methods. The 
transformation from OO methods to HTTP methods can be automated to a 
large extent. Here is the general algorithm I use:
    3.1) Retrieve all accessor methods from the object which are of 
the form 'getXXX()'. The set of all accessor methods can be described 
by the single HTTP GET method.
    3.2) Retrieve all mutator methods from the object which are of 
the form 'setXXX()'. The set of all mutator methods can be described 
by the single HTTP PUT method.
    3.3) If the object is a collection, search for all methods of the 
form 'Add(Object o)'. Based on the result of 3.1 wrt to 'o' for each 
add method, then each method of the form Add(Object) can be described 
by the single HTTP POST method.
    3.4) Repeat step 3.3, but instead searching for Remove(Object) 
methods which will be mapped to corresponding HTTP DELETE methods.
    3.5) All methods which ask a question about the state of the 
object can be safely ignored. Eg methods of the form IsXXX. Instead, 
clients can simply retrieve the state of the object and perform 
queries directly. Similarly, all methods which perform calculations 
based on the state of the object (eg Circle.CalculateArea()) can be 
safely ignored. Let the client perform calculations directly against 
the state representation.
    3.6) Examine all remaining methods. Any method which expresses 
behavior must be decomposed into a resource transfer problem. The 
classic example (that I continually encounter in my adventures in 
REST) is the ShoppingCart. In OOP-land, it is common to have a 
ShoppingCart class which exposes a CheckOut method. In ROP-land, you 
cannot expose such a method. (You could using HTTP POST but you 
shouldn't). Instead, the behavior of the CheckOut method must be 
expressed by creating a new Order resource and referring to the 
existing ShoppingCart resource. Thus the ShoppingCart.CheckOut method 
is replaced by POSTing an OrderCollection resource to create a new 
OrderResource. This is just an example.

This last step, step 3.6, cannot be automated and it's what makes 
designing RESTful services so difficult IMO. Many developers do not 
wish to take the time to perform the decompisition of behavioral 
methods so they simply expose them directly. This often leads to many 
problems. But this is the crux of REST: decomposing an API into a 
resource manipulation problem and while I can't prove it, it's my 
belief that all APIs can be completely decomposed into a resource 
manipulation problem.

(BTW, consider the SOAP equivalent to checking out a shopping cart. 
Because there is no real object model, the client usually ends up 
calling a method CheckOut and passing a UUID of some sort or a simple 
struct. This is hardly OOP--at best it is akin to "object-based" C 
programming).

You wrote: 'With REST you can't just take any Java/C++/C# Object and 
turn it into an easily used network accessible "thing".'

In fact, this is exactly what I do. Given a User class I can generate 
a UserResource class. Given a UserCollection class I can generate a 
UserCollectionResource. Eg...

User extends BusinessObject  ---> UserResource extends HttpResource
 get/set Username                  void DoGet()
 get/set Email                     void DoPut()
 get/set Realname                  void DoDelete()
                                   void DoOptions()

The tools exist if you're willing to write them.

4) When constructing a restful webservice it is necessary to clearly 
define what types of resources will exist and what operations may be 
performed upon these resources. This is done by examining the nouns 
in your problem domain and constructing resources that correspond to 
your nouns. This is the process of object discovery--it is the same 
process performed when constructing traditional object oriented 
solutions. This suggests there is indeed a strong relationship 
between resource oriented programming and object oriented 
programming. 

5) Now this is just a theory of mine and I need to explore it more, 
but I suspect that what you call Resource Oriented Programming is 
akin to the logical completion of what has been traditionally called 
Object Oriented Programming. The "goal" of OOP is to encapsulate data 
and behavior into a single logical component. Components then 
interact by passing messages back and forth. Encapsulation works 
because it allows complexity to be hidden (encapsulation is also 
known as information hiding) and so clients only need to know about 
the messages that go into and come out of a component and the state 
of that component. So this is the ***fundamental value proposition of 
encapsulation and OOP**: the amount of information a component A 
needs to know about a component B is reduced to the set of B's 
operations (the verb's that can be carried out against B) and B's 
state. 

Now let's return to ROP.

The "essence" of Resource Oriented Programming is to reduce the 
number of verbs in a system to a constant N (where N = 5 for HTTP) by 
introducing many nouns. Agents in an ROP system interact by applying 
these N verbs to this matrix of nouns. This is the **fundamental 
value propisition of REST**: the amount of information a component A 
needs to know about a component A has been reduced to B's state (and 
the XML vocabulary used to describe that state).

It is a well known fact that loose coupling is the holy grail of 
extremely complex (distributed) apps. The less two components know 
about one another the better. Therefore I'd like to say that ROP 
supercedes OOP because it has significantly reduced the amount of 
information two components must know about one another by placing a 
limit on the verbs a components can expose and requiring all 
components to expose the same verbs. Therefore ROP-systems 
**increase** loose-coupling and encapsulation. I'd even go so far as 
to say that a well-defined ROP-system can be more "object-oriented" 
than the analagous OOP-system.

Anybody who's ever built a large distributed app based on RPC and RMI 
should be able to immediately appeaciate the super-encapsulation 
achieved by ROP. Remember the three most common problems with RPC/RMI:

     1) Interface Fragility. Component A needs to add or remove a 
parameter to a method. When this happens, all components which depend 
on Component A's interface must be updated to obtain its new 
interface.

     2) Inconsistency. (Unbounded Complexity). In RPC/RMI systems the 
same logical operation can go by many different names. For example, 
Component A might expose a Destroy() operation, Component B might 
expose a Finalize() operation, and Component C might expose a Delete
() operation. This makes it very difficult for these components to be 
tied together into a coherent solution by a virgin third party 
because the virgin third party must take time to understand and 
handle the slightly different interfaces of each. This should be 
pretty clear: as the number of components grow the number of verbs in 
the system approach infinity and so it becomes impossible for 
newcomers to understand all the verbs exposed by the system and 
therefore understand what the system can do. This completely destroys 
what Sam Ruby calls "Manufactured Serendipity."
 
    (I really can't stress the phenomenon of Manufactured Serendipity 
enough. This is, I believe, the --point-- of the web. When you hide 
information behind SOAP endpoints that information might as well not 
be there. When you assign URLs to information it becomes possible for 
virgin thirdparties to use the system in ways you never dreamed of 
for example Google can now index that information (since it has URL) 
and others can use tools like XInclude, XSLT, etc to manipulate that 
information).

    3) Dynamic discovery. No matter what Microsoft et. al. may tell 
you, true dynamic discovery is impossible with  RPC because every RPC 
service exposes its own set of methods and it is impossible to know 
what these methods mean. There's no way a machine can look 
at 'RetrievePurchaseOrder(Long poID)' and havy any clue what that --
means--.

    That's just off the top of my head but those are three main flaws 
I can think of when it comes to RPC/RMI system. Now look at each one 
and apply ROP. 1 and 2 disappears because you no longer have 
specialized interfaces -- all components expose the same verbs. 3 
kind of disappears because these universal verbs have a well-defined 
meaning. If a machine knows that the resource located at 
http://host/purchase-orders/3424242 is a type of purchase order then 
it can infer that executing the GET method against that URL will 
retrieve a representation of that purchase order. In this case it's 
clear that the data backup problem becomes trivial to solve in 
RESTful services.

Toivo, hopefully at this point I've convinced you somewhat why I 
think ROP is far more object oriented than RPC and in fact may be 
more object oriented than OOP (as if that makes any sense). Also I 
can honestly say that it's been my experience that, given a well-
defined object model to a business app, it's easier for me to devise 
a RESTful webservice than a SOAP webservice which exposes that object 
model.

(continued in ROP vs RPC vs OOP pt 2)
- itdp

--- In rest-discuss@y..., "Toivo \"Deutsch\" Lainevool" 
<tlainevool@n...> wrote:
> Where do you get the idea that SOAP services are stateless?  I don't
> think there is any mention of state or statelessness in the SOAP 
spec.
> I think a SOAP service can be just as statefull as a REST 
resource.  Am
> I missing something here?
> 
> I'm also not sure what you mean by "By definition [SOAP Services] 
are no
> objects".  I don't want to get argument about what an object is or
> isn't, but SOAP services are something you can use for doing object
> oriented decomposition of a problem, whether or not its stateless.
> 
> Toivo
> 
> > -----Original Message-----
> > From: inthedarkplace [mailto:inthedarkplace@y...]
> > > >
> > > > With REST you can't just take any Java/C++/C# Object and turn 
it
> > into an
> > > > easily used network accessible "thing".
> > 
> > Actually you can and I do it all the time. I have automated tools
> > which can automagically generate the REST code given an object's
> > class. Also note that SOAP services are stateless. By definition 
they
> > are not objects. Resources have states and they expose methods
> > (DoGet, DoPut, DoDelete, DoPost, DoTrace, DoOptions) which 
constitute
> > behavior. After having done a lot of SOAP and REST hacking it's
> > evident to me and my team that REST is far more object oriented 
than
> > SOAP. In REST you work with real objects, in SOAP you're 
essentially
> > working with a class that defines arbitrary static methods.







-----------------------------------------------------------------------------------
Post ID:2331
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-09-03 05:50:38
Subject:Documenting RESTful Web Services
Message:

Hi, all--

I'm wondering what people are thinking about the best ways to describe
RESTful Web Services to clients and/or people, and how to access those
descriptions. Shortly after I joined this list there was a good deal of 
discussion of Paul's WRDL effort ... and as I recall, there was some 
sense that perhaps we should be trying to improve WSDL instead of
reinventing the wheel ... and then the whole topic seems to have been
abandoned.

Of course, I realize that there have been a variety of threads that
touched on the description/documentation issue, but there has been no
concerted effort to tackle it head-on for quite a while. I'm not sure
whether that means everyone thinks it's too early to try to reach
consensus, or people just aren't terribly concerned about it, or what.
Yet it seems to me that being able to say "this is how you get
information about resources" will help REST gain credibility (okay, 
the critics love it already, but will it play in Peoria?), while 
providing some valuable guidance for implementors.

I'm not about to suggest that we immediately lurch into a WSDL-like
standards-making effort. But might it not be a good idea to have a
semi-coherent collection of best practices for service description?

Or have I missed something?

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:2332
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-09-03 09:46:18
Subject:Re: Documenting RESTful Web Services
Message:

Matt, 

I've developed to very simple XML applications I use to describe my 
RESTful webservices. RWS-RMS (Resource Model Space) describes what 
resources a webservice exposes and RWS-IL (Interface Language). You 
can have many webservices each with their own RWS-RMS document 
(explaining where their resources are located) but sharing the same 
RWS-IL document explaining what you can do to thos resources.

I've spent the last 2 weeks tackling this problem of describing 
webservices and I don't think it's a problem that should be solved 
completely just yet. Reasons:

1) There's still no elegant way to describe an XML document's 
structure. I consider XML-Schema unusable and there's zero tool 
support for RELAX-NG. I've been investigating schematron which looks 
somewhat simpler but convoluted.

2) There are several issues with auto-proxy generation and REST, 
particularly: should it be done at all? I've been thinking a lot 
about it this. PaulPrescod has mentioned part of the value of REST is 
that it forces developers to acknowledge the network and deal with 
the kind-of-low-level-stuff like response codes. I think he may be 
right to an extent but I'm not sure.

Between 1 and 2 it's hard to make much progress. For now, I'd agree 
with Roger: the best way to describe your webservice in a truly 
meaningful manner that will be accessible to the greatest number of 
people is to use HTML and document it.

- itdp

--- In rest-discuss@y..., Matt Gushee <mgushee@h...> wrote:
> Hi, all--
> 
> I'm wondering what people are thinking about the best ways to 
describe
> RESTful Web Services to clients and/or people, and how to access 
those
> descriptions. Shortly after I joined this list there was a good 
deal of 
> discussion of Paul's WRDL effort ... and as I recall, there was 
some 
> sense that perhaps we should be trying to improve WSDL instead of
> reinventing the wheel ... and then the whole topic seems to have 
been
> abandoned.
> 
> Of course, I realize that there have been a variety of threads that
> touched on the description/documentation issue, but there has been 
no
> concerted effort to tackle it head-on for quite a while. I'm not 
sure
> whether that means everyone thinks it's too early to try to reach
> consensus, or people just aren't terribly concerned about it, or 
what.
> Yet it seems to me that being able to say "this is how you get
> information about resources" will help REST gain credibility (okay, 
> the critics love it already, but will it play in Peoria?), while 
> providing some valuable guidance for implementors.
> 
> I'm not about to suggest that we immediately lurch into a WSDL-like
> standards-making effort. But might it not be a good idea to have a
> semi-coherent collection of best practices for service description?
> 
> Or have I missed something?
> 
> -- 
> Matt Gushee
> Englewood, Colorado, USA
> mgushee@h...
> http://www.havenrock.com/







-----------------------------------------------------------------------------------
Post ID:2333
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-03 14:35:12
Subject:GET: Shades of Grey (was: TrackBack)
Message:

> But then appears to use GET for a side effect:

At first glance, I'd say this is probably okay, but
I don't know all the circumstances. See below...

Coincidentally enough, over the weekend Sam Ruby put up a
rather contentious post on his weblog about that very subject here:

  http://www.intertwingly.net/blog/?entry=784

He says he phrased it that way to stir debate. :)

Some cursory searching returns such remarks from Roy 
Fielding as:

"Idempotence of methods is specifically not identical to idempotence
of mathematical operations, as is explained in the spec.  We did not
attempt to make it more formal because the goal was to have the 
specification describe the interface as it was intended, not define 
it in such a way that only static resources could be implemented." [1]

"The requirement is that "the GET and HEAD methods SHOULD NOT have 
the significance of taking an action other than retrieval."  It does 
not require that no side-effects occur, nor even that the side-effects 
not be visible within the representation of the resource provided in 
the response." [2] 

This debate has come up numerous times, but I couldn't find a 
RESTWiki [3] entry that directly addresses this issue.  Is there one? 

[1] http://www.xent.com/pipermail/fork/2001-July/001946.html
[2] http://www.xent.com/pipermail/fork/2001-July/001974.html
[3] http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage







-----------------------------------------------------------------------------------
Post ID:2334
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-03 16:20:27
Subject:Re: [rest-discuss] GET: Shades of Grey (was: TrackBack)
Message:

Jeffrey Winter wrote,
> Coincidentally enough, over the weekend Sam Ruby put up a
> rather contentious post on his weblog about that very subject here:
>
>   http://www.intertwingly.net/blog/?entry=784
>
> He says he phrased it that way to stir debate. :)

Interesting ...

IMO RFC 2616 9.1 is very confusing. It talks about side-effects, but 
doesn't clearly indicate whether those effects are effects on the 
server or effects on the client.

I'm reasonably sure that the primary intention was only to refer to 
side-effects on the server (if nothing else this would be consistent 
with the way "idempotent" is used in the context of ONC RPC), and that 
the client-visible results of a GET and any client-side side-effects 
are irrelevant.

However, this is somewhat confused by the discussion of "idempotent 
sequences of methods",

  However, it is possible that a sequence of several requests is non-
  idempotent, even if all of the methods executed in that sequence are
  idempotent. (A sequence is idempotent if a single execution of the
  entire sequence always yields a result that is not changed by a
  reexecution of all, or part, of that sequence.) For example, a
  sequence is non-idempotent if its result depends on a value that is
  later modified in the same sequence.

where "yields a result" seems to be refering to effects on the client. 
That can't be right tho', because if it were, DELETE wouldn't be 
idempotent: even tho' the effect of multiple DELETEs of the same 
resource is the same as just one on the server, it's likely that the 
client-visible result would differ: a 200 for the first invocation and 
404s subsequently.

On the server-side-relevant-only interpretation, a GET can return  
different results on every invocation so long as no server-side state 
is mutated by the GETs themselves. There are quite a few ways that 
could happen: if there are multiple clients, one might POST 
concurrently with another GETing; or there might be out of band content 
updates; or the result of the GETs might be generated by some process 
which is not itself affected by the GET, eg. a clock or a random number 
generator. Clearly in these kinds of case care has to be taken with 
Expires: and Cache-Control:, but that shouldn't be a problem.

For all that this is reasonably coherent and consistent, I've never yet 
been able to square it with the elaboration in the last sentence quoted 
above,

  For example, a sequence is non-idempotent if its result depends on a
  value that is later modified in the same sequence.

For example, here's a sequence of methods which are each individually 
idempotent,

  GET /foo
  PUT /foo

Intuitively this is the kind of case that the clause is intended to 
exclude: a sequence which is non-idempotent even tho' it's constituents 
are. If we reexecute the sequence, the result of the second GET will 
have been affected by the first PUT ...

... but hang on a minute: that's _only_ true with respect to client- 
visible results. If we're only paying attention to the effects of the 
sequence on the server, then this sequence is perfectly idempotent, and 
any number of reexecutions will have exactly the same effect as the 
first.

In truth, paying attention only to server-side effects of idempotent 
methods, I've not been able to come up with a single example of a 
non-idempotent sequence. I'd be interested to know if anyone else can. 
If not, does that mean that client-visible results _do_ play a role in 
idempotency? In which case, whither PUT, DELETE and GETs which return 
non-constant results?

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2335
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-09-03 16:30:17
Subject:Re: [rest-discuss] Re: Documenting RESTful Web Services
Message:

On Tue, Sep 03, 2002 at 09:46:18AM -0000, inthedarkplace wrote:
> 
> I've developed to very simple XML applications I use to describe my 
> RESTful webservices. RWS-RMS (Resource Model Space) describes what 
> resources a webservice exposes and RWS-IL (Interface Language). You 
> can have many webservices each with their own RWS-RMS document 
> (explaining where their resources are located) but sharing the same 
> RWS-IL document explaining what you can do to thos resources.

Interesting. How do I find out more about this?

> I've spent the last 2 weeks tackling this problem of describing 
> webservices and I don't think it's a problem that should be solved 
> completely just yet. Reasons:
> 
> 1) There's still no elegant way to describe an XML document's 
> structure. I consider XML-Schema unusable and there's zero tool 
> support for RELAX-NG. I've been investigating schematron which looks 
> somewhat simpler but convoluted.

Zero tool support for RELAX-NG? I guess it depends on what you mean by a
tool.

> 2) There are several issues with auto-proxy generation and REST, 
> particularly: should it be done at all? I've been thinking a lot 
> about it this. PaulPrescod has mentioned part of the value of REST is 
> that it forces developers to acknowledge the network and deal with 
> the kind-of-low-level-stuff like response codes. I think he may be 
> right to an extent but I'm not sure.
> 
> Between 1 and 2 it's hard to make much progress. For now, I'd agree 
> with Roger: the best way to describe your webservice in a truly 
> meaningful manner that will be accessible to the greatest number of 
> people is to use HTML and document it.

I agree with the bulk of your argument, but not entirely with the
conclusion. Certainly, human-readable documentation is currently the
only sound basis for client-side development--and I would go even
farther than you, to say that there will probably *always* be a need for
it: maybe it's just my liberal-arts background talking, but as far as
I'm concerned, the notion of 'intelligent agents' crawling the web, and
finding and processing the right resources without human intervention is
science fiction (which means it has a 27.3% chance of coming true :-).

Even setting that dubious vision aside, there are those who would argue 
that resources can/should be self-describing. To which I would answer 
that 'self-description' is always relative to some context, and the
meanings expressed in any given information resource are more
context-dependent than most people realize. And even though users are
welcome to use resources as they see fit (that's the nature of the web,
after all), many people will find a prose description of the author's
ideas about the data to be valuable.

So, yes, we need to document our services in human-readable form, now
and in the foreseeable future. But I think 'use HTML and document it'
glosses over some important questions that are, if not resolvable, at
least discussable here and now. One in particular that concerns me--
and I think would be of value to many prospective RESTful developers
--is how to access the documentation for a web service. Since REST is
not a programming language, maybe it's inappropriate to compare it to
one, but I can't help thinking about the documentation conventions used
in, say, Java and Python. Developers know how to extract documentation
from any library they want to use, and even if the developer of that
library has completely neglected to describe anything, they can still
obtain the bare essentials of the API.

So suppose we had conventions for structuring the documentation for web
resources, and a conventional way of querying resources to obtain their
documentation? Wouldn't that be a good thing?

  [ I've actually made a stab in the direction of developing such 
    conventions: in a demo I put together for a presentation back
    in February, I wrote resource descriptions using Dublin Core
    with embedded XHTML elements (e.g. <xhtml:p> inside
    <dc:Description>), and to obtain the description you would use
    the resource URI with a trailing '?' ... yes, it was a nasty hack.
    Oh well ... ]

What are the obstacles to developing such conventions?

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:2336
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-03 16:45:48
Subject:RE: [rest-discuss] GET: Shades of Grey (was: TrackBack)
Message:


> -----Original Message-----
> From: Miles Sabin [mailto:miles@...]
> Sent: Tuesday, September 03, 2002 12:20 PM
> To: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] GET: Shades of Grey (was: TrackBack)
> 
> In truth, paying attention only to server-side effects of idempotent 
> methods, I've not been able to come up with a single example of a 
> non-idempotent sequence. I'd be interested to know if anyone 
> else can. 
> If not, does that mean that client-visible results _do_ play 
> a role in 
> idempotency? In which case, whither PUT, DELETE and GETs which return 
> non-constant results?

I have half a notion of how this problem (composition of idempotent
methods is/isnot idempotent?) can be modeled in Alloy, and if
no one comes up with a counter-example from experience, then perhaps
I'll tackle it formally.

Walden






-----------------------------------------------------------------------------------
Post ID:2337
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-03 17:08:25
Subject:Idempotent sequences
Message:

On Tue, Sep 03, 2002 at 05:20:27PM +0100, Miles Sabin wrote:
> For all that this is reasonably coherent and consistent, I've never yet 
> been able to square it with the elaboration in the last sentence quoted 
> above,
> 
>   For example, a sequence is non-idempotent if its result depends on a
>   value that is later modified in the same sequence.
> 
> For example, here's a sequence of methods which are each individually 
> idempotent,
> 
>   GET /foo
>   PUT /foo
> 
> Intuitively this is the kind of case that the clause is intended to 
> exclude: a sequence which is non-idempotent even tho' it's constituents 
> are. If we reexecute the sequence, the result of the second GET will 
> have been affected by the first PUT ...
> 
> ... but hang on a minute: that's _only_ true with respect to client- 
> visible results. If we're only paying attention to the effects of the 
> sequence on the server, then this sequence is perfectly idempotent, and 
> any number of reexecutions will have exactly the same effect as the 
> first.

Well, an important difference between a sequence and an individual
invocation that I don't think you're taking into account, is that
application state is held by the client.  So between "GET /foo" and "PUT
/foo", the data being transferred may change.  For example, the client
may be incrementing a counter.  Certainly, from both a client and
server perspective, that's non-idempotent.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2338
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-03 17:03:20
Subject:Re: [rest-discuss] GET: Shades of Grey (was: TrackBack)
Message:

----- Original Message -----
From: "Jeffrey Winter" <j.winter@...>
>
> This debate has come up numerous times, but I couldn't find a
> RESTWiki [3] entry that directly addresses this issue.  Is there one?
>
> [1] http://www.xent.com/pipermail/fork/2001-July/001946.html
> [2] http://www.xent.com/pipermail/fork/2001-July/001974.html
> [3] http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage
>
>
There is now.
http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq#line171
What about those pesky hit counters?
REST systems have a safe and idempotent 'get' operation. So does HTTP.
'Safe' generally means it isn't intended to modify the resource (the sender
isn't responsible for any problems), and 'idempotent' means repeating the
operation ends up with the resource in the same state (it doesn't mean all
the responses are always identical).

This is a confusing point because a 'hit counter' accumulates the number of
time an idempotent operation has occured - and often is visible within the
representation of that resource - things change just by doing a GET!
Horrors!

There is of course no way to prevent this from mere architectural
descriptions of the system. It is up to the server author to understand what
will happen and what this implies. The REST approach guides designers away
from this approach as a foundation to build functionality. It is still
doable - but it has costs and problems that it should be avoided as a
general approach.







-----------------------------------------------------------------------------------
Post ID:2339
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-03 17:19:27
Subject:Re: [rest-discuss] Idempotent sequences
Message:

Mark Baker wrote,
> Well, an important difference between a sequence and an individual
> invocation that I don't think you're taking into account, is that
> application state is held by the client.  So between "GET /foo" and
> "PUT /foo", the data being transferred may change.  For example, the
> client may be incrementing a counter.  Certainly, from both a client
> and server perspective, that's non-idempotent.

I see that.

But suppose there's no state update on the client. There's an initial 
resource /foo on the server, and a fixed resource which the client 
PUTs. In that case, is,

  GET /foo
  PUT /foo

an idempotent sequence or not?

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2340
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-03 17:21:50
Subject:RE: [rest-discuss] Idempotent sequences
Message:

I'm not sure, but I think that if the entity of the PUT is
allowed to change as you repeat the sequence, then you are not
testing idempotence.  Doesn't 'repeat the operation' imply
using the same arguments?

Walden

> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Tuesday, September 03, 2002 1:08 PM
> To: Miles Sabin
> Cc: rest-discuss@yahoogroups.com
> Subject: [rest-discuss] Idempotent sequences
> 
> 
> On Tue, Sep 03, 2002 at 05:20:27PM +0100, Miles Sabin wrote:
> > For all that this is reasonably coherent and consistent, 
> I've never yet 
> > been able to square it with the elaboration in the last 
> sentence quoted 
> > above,
> > 
> >   For example, a sequence is non-idempotent if its result 
> depends on a
> >   value that is later modified in the same sequence.
> > 
> > For example, here's a sequence of methods which are each 
> individually 
> > idempotent,
> > 
> >   GET /foo
> >   PUT /foo
> > 
> > Intuitively this is the kind of case that the clause is intended to 
> > exclude: a sequence which is non-idempotent even tho' it's 
> constituents 
> > are. If we reexecute the sequence, the result of the second 
> GET will 
> > have been affected by the first PUT ...
> > 
> > ... but hang on a minute: that's _only_ true with respect 
> to client- 
> > visible results. If we're only paying attention to the 
> effects of the 
> > sequence on the server, then this sequence is perfectly 
> idempotent, and 
> > any number of reexecutions will have exactly the same effect as the 
> > first.
> 
> Well, an important difference between a sequence and an individual
> invocation that I don't think you're taking into account, is that
> application state is held by the client.  So between "GET 
> /foo" and "PUT
> /foo", the data being transferred may change.  For example, the client
> may be incrementing a counter.  Certainly, from both a client and
> server perspective, that's non-idempotent.
> 
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2341
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-03 17:27:35
Subject:Re: [rest-discuss] Idempotent sequences
Message:

Mathews, Walden wrote,
> I'm not sure, but I think that if the entity of the PUT is
> allowed to change as you repeat the sequence, then you are not
> testing idempotence.  Doesn't 'repeat the operation' imply
> using the same arguments?

That would be the usual reading of "idempotent", certainly.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2342
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-03 17:41:01
Subject:Re: [rest-discuss] Idempotent sequences
Message:

On Tue, Sep 03, 2002 at 06:19:27PM +0100, Miles Sabin wrote:
> I see that.
> 
> But suppose there's no state update on the client. There's an initial 
> resource /foo on the server, and a fixed resource which the client 
> PUTs. In that case, is,
> 
>   GET /foo
>   PUT /foo
> 
> an idempotent sequence or not?

Sure, you can always construct a GET-followed-by-PUT (of the same URI)
example that is idempotent, but that's not the point.

The point is, as 2616 says;

"However, it is possible that a sequence of several requests is non-
idempotent, even if all of the methods executed in that sequence are
idempotent."

And I showed an example where that was the case.  It is clearly *not*
the case for all sequenced uses of GET and PUT on the same URI, but
that's ok, it doesn't need to be to make that statement in 2616 correct.

I agree that RFC 2616 could be clearer here, but to me it seems pretty
clear what it's intent is in talking about this stuff.  For example,
instead of "sequence of methods" in 8.1.2.2 it should say "sequence of
requests".

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2343
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-03 17:49:44
Subject:Re: [rest-discuss] Idempotent sequences
Message:

Actually, let me take that back. 8-)

Let's say the example was;

"2" <= GET /foo
PUT "1" /foo

i.e. GET returns "2", PUT sets value to "1".  Obviously in the steady
state, this sequence is idempotent, but it isn't on the first go round.

Please ignore my other rants.  I'm sick and my head hurts. 8-(

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2344
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-03 17:57:53
Subject:RE: [rest-discuss] Idempotent sequences
Message:

According to mydictionary, idempotence is a property of homogeneous
functions (D -> D), such that f(x) = f(f(x)) => 'f' is idempotent.
We have to be careful about extending that model to fit the request/
response paradigm of REST.  If anything, D is the domain from which
representations are drawn and (D -> D) represents the mapping of a
pre-state for a given resource to its post-state, and in that sense,
the 'return' value of the function we're interested in means that
the function is defined as a pair

	(PUT | POST | DELETE) /foo <representation>
	GET /foo

So that the final get represents the function's value (i.e., the second
'D' in the mapping from D -> D).

Other definitions of 'idempotent' refer to things like recursive inclusion
of C header files; not very enlightening.

Walden

> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Tuesday, September 03, 2002 1:50 PM
> To: Mark Baker
> Cc: Miles Sabin; rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Idempotent sequences
> 
> 
> Actually, let me take that back. 8-)
> 
> Let's say the example was;
> 
> "2" <= GET /foo
> PUT "1" /foo
> 
> i.e. GET returns "2", PUT sets value to "1".  Obviously in the steady
> state, this sequence is idempotent, but it isn't on the first 
> go round.
> 
> Please ignore my other rants.  I'm sick and my head hurts. 8-(
> 
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 








-----------------------------------------------------------------------------------
Post ID:2345
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-03 17:58:12
Subject:Re: [rest-discuss] Idempotent sequences
Message:

Mark Baker wrote,
> On Tue, Sep 03, 2002 at 06:19:27PM +0100, Miles Sabin wrote:
> > I see that.
> >
> > But suppose there's no state update on the client. There's an
> > initial resource /foo on the server, and a fixed resource which the
> > client PUTs. In that case, is,
> >
> >   GET /foo
> >   PUT /foo
> >
> > an idempotent sequence or not?
>
> Sure, you can always construct a GET-followed-by-PUT (of the same
> URI) example that is idempotent, but that's not the point.

So that sequence is idempotent? Even tho' the client-visible result will 
differ on a reexecution? OK, that's how I understand idempotent as it 
applies to individual methods. It's what I called the server-side- 
relevant-only interpretation, and I think it's the only one which is 
consistent with PUT and DELETE being idempotent.

> The point is, as 2616 says;
>
> "However, it is possible that a sequence of several requests is non-
> idempotent, even if all of the methods executed in that sequence are
> idempotent."
>
> And I showed an example where that was the case.  It is clearly *not*
> the case for all sequenced uses of GET and PUT on the same URI, but
> that's ok, it doesn't need to be to make that statement in 2616
> correct.

No, that wasn't an example. You allowed the PUT entity to change between 
executions of the sequence. That means that the PUT isn't being used in 
an idempotent way, so a fortiori the sequence isn't idempotent.

For the clauses about idempotent sequences to make any sense we'd need 
an example of a non-idempotent sequence of idempotent requests where 
any PUT entities stay the same from execution to execution. Like I 
said, I haven't been able to think of a single example. Can anyone else 
come up with one?

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2346
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-03 18:05:34
Subject:Re: [rest-discuss] Idempotent sequences
Message:

Mark Baker wrote,
> Actually, let me take that back. 8-)
>
> Let's say the example was;
>
> "2" <= GET /foo
> PUT "1" /foo
>
> i.e. GET returns "2", PUT sets value to "1".  Obviously in the steady
> state, this sequence is idempotent, but it isn't on the first go
> round.

Err ... but if we're only paying attention to the state on the 
server-side, then this isn't a problem. The effect on the server of 
multiple executions of that sequence is exactly the same as the 
execution of just one.

The effect on the client changes from execution to execution, sure, but 
that had better *not* make the sequence non-idempotent, otherwise,

  DELETE /foo   (200 OK)
  DELETE /foo   (404 Not Found)

would imply that DELETE is non-idempotent.

> Please ignore my other rants.  I'm sick and my head hurts. 8-(

Is that an effect of tying to make sense of 9.1 or something else? ;-)

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2347
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-03 18:36:30
Subject:Re: [rest-discuss] Idempotent sequences
Message:

Mathews, Walden wrote,
> According to mydictionary, idempotence is a property of homogeneous
> functions (D -> D), such that f(x) = f(f(x)) => 'f' is idempotent.
> We have to be careful about extending that model to fit the request/
> response paradigm of REST.  If anything, D is the domain from which
> representations are drawn and (D -> D) represents the mapping of a
> pre-state for a given resource to its post-state, and in that sense,
> the 'return' value of the function we're interested in means that
> the function is defined as a pair
>
> 	(PUT | POST | DELETE) /foo <representation>
> 	GET /foo
>
> So that the final get represents the function's value (i.e., the
> second 'D' in the mapping from D -> D).
>
> Other definitions of 'idempotent' refer to things like recursive
> inclusion of C header files; not very enlightening.

I think the first definition is just fine. The function here is the 
request, and the domain and range are states of the server (feel free 
to replace "server" with "resource" throughout if you'd prefer, it 
shouldn't make any difference).

Let's write s, s' for states of the server, g(s) and p(s) for,

  GET /foo

and,

  PUT /foo    (with a fixed PUT entity)

respectiverly, applied to the server in state s. The 9.1 definitions 
imply that,

  g(s) = s

hence,

  g(g(s)) = g(s)

because GET is both safe and idempotent. OTOH, the imply that,

  p(s) = s'   (where typically s' != s)

because PUT isn't safe, but,

  p(s') = s'   

because PUT is idempotent, and hence,

  p(p(s)) = p(s)

DELETE will be similar to PUT.

One thing to note here is that what the client sees isn't mentioned at 
all: all the above is defined in terms of server states and functions 
mapping server states to server states.

Hmm ... spelt out this way, there's a trivial proof that all sequences 
of idempotent requests are idempotent sequences. That means that either 
there's something wrong with spelling things out this way (in which 
case, what?), or there's something not quite right with 9.1

Thoughts?

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2348
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-03 18:53:54
Subject:RE: [rest-discuss] Idempotent sequences
Message:

We're on the same wavelength.  The only thing I wasn't sure
about was whether everyone agreed on what the 'function' relates.
My explicit GET was intended to mean exactly what you have
explained, namely that the function is from resource pre-state to
post-state, and the latter always visible to client.  In my
two-method model of function, I should have included no-op in
the list of alternates for mutators, so that *nothing* followed by
a GET is also a 'function'.

What's the trivial proof?  I also sense that it's easy, but if
it's that easy, then Alloy won't help.

Walden

> -----Original Message-----
> From: Miles Sabin [mailto:miles@...]
> Sent: Tuesday, September 03, 2002 2:37 PM
> To: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Idempotent sequences
> 
> 
> Mathews, Walden wrote,
> > According to mydictionary, idempotence is a property of homogeneous
> > functions (D -> D), such that f(x) = f(f(x)) => 'f' is idempotent.
> > We have to be careful about extending that model to fit the request/
> > response paradigm of REST.  If anything, D is the domain from which
> > representations are drawn and (D -> D) represents the mapping of a
> > pre-state for a given resource to its post-state, and in that sense,
> > the 'return' value of the function we're interested in means that
> > the function is defined as a pair
> >
> > 	(PUT | POST | DELETE) /foo <representation>
> > 	GET /foo
> >
> > So that the final get represents the function's value (i.e., the
> > second 'D' in the mapping from D -> D).
> >
> > Other definitions of 'idempotent' refer to things like recursive
> > inclusion of C header files; not very enlightening.
> 
> I think the first definition is just fine. The function here is the 
> request, and the domain and range are states of the server (feel free 
> to replace "server" with "resource" throughout if you'd prefer, it 
> shouldn't make any difference).
> 
> Let's write s, s' for states of the server, g(s) and p(s) for,
> 
>   GET /foo
> 
> and,
> 
>   PUT /foo    (with a fixed PUT entity)
> 
> respectiverly, applied to the server in state s. The 9.1 definitions 
> imply that,
> 
>   g(s) = s
> 
> hence,
> 
>   g(g(s)) = g(s)
> 
> because GET is both safe and idempotent. OTOH, the imply that,
> 
>   p(s) = s'   (where typically s' != s)
> 
> because PUT isn't safe, but,
> 
>   p(s') = s'   
> 
> because PUT is idempotent, and hence,
> 
>   p(p(s)) = p(s)
> 
> DELETE will be similar to PUT.
> 
> One thing to note here is that what the client sees isn't 
> mentioned at 
> all: all the above is defined in terms of server states and functions 
> mapping server states to server states.
> 
> Hmm ... spelt out this way, there's a trivial proof that all 
> sequences 
> of idempotent requests are idempotent sequences. That means 
> that either 
> there's something wrong with spelling things out this way (in which 
> case, what?), or there's something not quite right with 9.1
> 
> Thoughts?
> 
> Cheers,
> 
> 
> Miles
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
> 






-----------------------------------------------------------------------------------
Post ID:2349
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-03 19:49:30
Subject:Re: [rest-discuss] Idempotent sequences
Message:

Mathews, Walden wrote,
> What's the trivial proof?  I also sense that it's easy, but if
> it's that easy, then Alloy won't help.

Hmm ... OK, this is a bit rough and ready, but let's see ...

By definition GET, PUT and DELETE are idempotent, so, using the notation 
from my previous mail,

  g(g(s)) = g(s)   ie. g.g = g
  p(p(s)) = p(s)       p.p = p
  d(d(s)) = d(s)       d.d = d

where PUT entities are constant and the request URI is common to g, p 
and d (I'll remove this last assumption later).

First off, g is the identity function. That might sound odd, but 
remember, we're only interested in the state of the server, so if 
follows from the safeness of GET.

It follows that every sequence of g, p, d can be simplified to just g, 
or an alternation of p and d, because the g's can be eliminated and 
runs of p's and d's can be collapsed to a single p or d. That means 
that every sequence is equivalent to one of,

1.  g
2.  p.d ... p.d
3.  p.d ... d.p
4.  d.p ... p.d
5.  d.p ... d.p

Now, a PUT of /foo followed by a DELETE of /foo is equivalent to just a 
DELETE, so,

  d(p(s)) = d(s)   ie. d.p = d

and a DELETE of /foo followed by a PUT of /foo is equivalent to just a 
PUT, so,

  p(d(s)) = p(s)   ie. p.d = p

So we can now reduce the sequences above to,

1. g
2. p
3. p
4. d
5. d

ie. any sequence of g, p, and d is equivalent to the most recent 
non-GET, or to just GET if there are no PUTs or DELETEs involved. But 
those three are all idempotent, so the original sequence must be 
idempotent too.

OK, now all we have to do is generalize to the case where the sequence 
includes GETs, PUTs and DELETEs wrt different request URIs. On the 
assumption that a PUT or DELETE of /foo only affect /foo and not any 
other resource we can decompose a mixed URI sequence into distinct 
subsequences, one for each distinct URI. For example,

  GET /foo                   GET /foo
  PUT /bar                                          PUT /bar
  DELETE /foo                DELETE /foo
  GET /bar                                          GET /bar
  PUT /foo                   PUT /foo
  DELETE /bar                                       DELETE /bar

Because these subsequences are relative to distinct URIs they can't have 
any interdependencies, hence the mixed URI sequence is idempotent if 
each of the homogenous URI sequences is.

But we've already seen that the homogenous URI sequences are idempotent, 
so all sequences are.

QED ;-)

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2350
Sender:"borkazoid" <beau@...>
Post Date/Time:2002-09-04 08:09:00
Subject:New version of XooMLe available
Message:

Hi All,
just thought you might be interested that a new version of XooMLe 
(XML interface to the Google API) has been uploaded to the live 
server now. You can get more information from 
http://www.dentedreality.com.au/xoomle/ or jump straight to the 
documentation at http://www.dentedreality.com.au/xoomle/docs/

Basically, the modifications are;

 - proper support for directories
 - added a "relatedInformation" element if there is any available
 - added an xlink attribute to relatedInformation and cachedVersion
 - bugfixes (especially on looping and maxResults > 10)
 - ability to specify an XSLT stylesheet using the "xsl" querystring 
variable, which allows you to do on-the-fly formatting

Also, if you are interested, XooMLe will feature in an upcoming 
O'Reilly book which is still being written. At this stage, I think it 
is called "Google Hacks", it's about the things that people have done 
with the Google API since it was released, and should be a pretty 
good read :)

Cheers, and thanks to everyone for their suggestions and feedback on 
XooMLe, please kep it coming if you have any more ideas for making it 
more RESTful (or just more useful!)

Beau
(from DentedReality)







-----------------------------------------------------------------------------------
Post ID:2351
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-09-04 09:58:16
Subject:Re: New version of XooMLe available
Message:

Beau,

Dude, Xoomle is looking pretty sweet! I'd like to make the following 
suggestions which will make Xoomle more RESTful and easier to use and 
integrate with existing code.

1) Actually, I was going to say you might want to expose an RMS 
document but nevermind. In the future though, you might want to 
consider that there's a difference between the Google service (a 
search mechanism using the PageRank algorithm) and a Google service 
provider (a URL that exposes the Xoomle API). If people have a Google 
appliance for their internal LAN or their desktop then you can have 
many service providers providing the same service. You might also 
have people exposing Google-like services on top custom data stores, 
eg a database. For this reason, I would suggest modularizing your XML 
format so Google-like services could add/remove search metadata and 
semantics. 

2) Please don't use XML-based errors. It's very annoying to go 
through all the trouble of parsing an XML document just to discover 
it contains no useful information. HTTP has a rich set of built in 
response codes you should use. Particularly, I would suggest the 
following:
    
    2.1) If a search or spelling suggest does not return any results 
then the Xoomle service should return the "HTTP 204 No Content" 
status code. If you want to specify the type of error, include an URL 
in the 'Location' header which the client can use to determine the 
basic type 
eg 'www.dentedreality.com.au/xoomle/types/errors/NoKeySpecified'. 
Only if the error contains rich information do you need to provide an 
XML document describing the error. (Most of errors I think, don't 
contain rich information they're of the sort like 'Phrase not 
specified' so this should save you and me both some work). Similarly, 
HTTP defines error codes like 'HTTP 503 Service Unavailable' for 
example to indicate that Xoomle can't contact Google. Really, 90% of 
the time I don't care what type of error happened, I just need to 
know that there was an error.

    2.2) Similarly, the behavior you expose tends to be made 
redundant by HTTP. For example, your method doGetCachedPage simply 
returns the HTML of the cached page straight from google. Rather than 
doing this, I'd suggest issuing an HTTP Redirect to the client so 
they can retrieve the cached page themselves.


3) This is trivial but I don't really see the need for the top-level 
XML element 'doGoogleSearchResponse' since that's a bit verb-like. 
Having 'GoogleSearchResult' as the root seems cleaner to me. Also, 
since XML is case-sensitive and since ppl will be writing xslts to 
handle Xoomle responses I'd suggest being consistent with your naming 
convention. Since you're using camel-casing it seems 
like 'GoogleSearchResult' should be 'googleSearchResult'.

Also I have a few questions:

1) How do I pass the 'site:' restriction to Xoomle? Is this just 
something the Google SOAP api forbids?

2) Is there any way to expose the directories offered by the Google 
Directory?

3) Can you explain more about how max results work? 

4) What do the plain-text spelling suggestions response look like? 
Are you sure you don't want to return an XML document instead?


All in all, this is a great service and looks like it could be very 
useful to develop apps on top of Google. Keep up the good work!

- itdp

--- In rest-discuss@y..., "borkazoid" <beau@d...> wrote:
> Hi All,
> just thought you might be interested that a new version of XooMLe 
> (XML interface to the Google API) has been uploaded to the live 
> server now. You can get more information from 
> http://www.dentedreality.com.au/xoomle/ or jump straight to the 
> documentation at http://www.dentedreality.com.au/xoomle/docs/
> 
> Basically, the modifications are;
> 
>  - proper support for directories
>  - added a "relatedInformation" element if there is any available
>  - added an xlink attribute to relatedInformation and cachedVersion
>  - bugfixes (especially on looping and maxResults > 10)
>  - ability to specify an XSLT stylesheet using the "xsl" 
querystring 
> variable, which allows you to do on-the-fly formatting
> 
> Also, if you are interested, XooMLe will feature in an upcoming 
> O'Reilly book which is still being written. At this stage, I think 
it 
> is called "Google Hacks", it's about the things that people have 
done 
> with the Google API since it was released, and should be a pretty 
> good read :)
> 
> Cheers, and thanks to everyone for their suggestions and feedback 
on 
> XooMLe, please kep it coming if you have any more ideas for making 
it 
> more RESTful (or just more useful!)
> 
> Beau
> (from DentedReality)







-----------------------------------------------------------------------------------
Post ID:2352
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-04 13:15:45
Subject:[rest-discuss] GET: Shades of Grey
Message:

Mark I wanted to make some comments about your blog post replying
to Sam Ruby's Google GET issue:

http://markbaker.blogspot.com/2002_09_01_markbaker_archive.html#81091743

I would agree with this analysis, except to me the presence 
of the Developer's Key changes how this issue needs to be 
approached.  IMO, the Developer's Key has an explicit impact 
on how the idea of a "safe method" should be interpreted.

Interpreting safety this strictly, in this context, would seem to 
render an entire class of Web Services essentially un-GETable.  
It would seem to reinforce the perception that REST is only good 
for mostly public data.

Given your comments, do you see Xoomle as broken?  

How is this really any different from any web site that 
does session time-outs?  In that case, is the fact that
the session time-out clock is reset when following a link
considered an action of "unexpected significance?"  This 
is almost a mirror image of the Google hit counter: in one 
case following a link has the implicit effect of keeping 
the session alive; in the other, it is slowly eating it away.  
But in both cases the user "did not request the side-effects" 
explicitly.

It seems to me that Google is demonstrating the beginnings of
a Pay-per-Use business model, that other public Web Services 
may need to adopt in order to generate income.  I expect that 
in the future, Google will be selling Keys, say $100 per billion 
queries (or something like that) :)








-----------------------------------------------------------------------------------
Post ID:2353
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-04 13:43:21
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

On Wed, Sep 04, 2002 at 09:15:45AM -0400, Jeffrey Winter wrote:
> Mark I wanted to make some comments about your blog post replying
> to Sam Ruby's Google GET issue:
> 
> http://markbaker.blogspot.com/2002_09_01_markbaker_archive.html#81091743
> 
> I would agree with this analysis, except to me the presence 
> of the Developer's Key changes how this issue needs to be 
> approached.  IMO, the Developer's Key has an explicit impact 
> on how the idea of a "safe method" should be interpreted.

I don't see it as any different than the authorization info as part of
an HTTP authentication transaction - it authenticates the user.  I
don't see how it changes anything.

> Interpreting safety this strictly, in this context, would seem to 
> render an entire class of Web Services essentially un-GETable.  
> It would seem to reinforce the perception that REST is only good 
> for mostly public data.

I don't see it that way.  Would you argue that a GET that bumped up a
counter was safe?

> Given your comments, do you see Xoomle as broken?  

"Broken" is too strong.  "Sub-optimal", yes.

> How is this really any different from any web site that 
> does session time-outs?  In that case, is the fact that
> the session time-out clock is reset when following a link
> considered an action of "unexpected significance?"  This 
> is almost a mirror image of the Google hit counter: in one 
> case following a link has the implicit effect of keeping 
> the session alive; in the other, it is slowly eating it away.  
> But in both cases the user "did not request the side-effects" 
> explicitly.
> 
> It seems to me that Google is demonstrating the beginnings of
> a Pay-per-Use business model, that other public Web Services 
> may need to adopt in order to generate income.  I expect that 
> in the future, Google will be selling Keys, say $100 per billion 
> queries (or something like that) :)

I think my statements may have been taken out of context.  I was just
answering Sam's question; I wouldn't use GET to perform a query that
was unsafe.  What I didn't say, but would still try to do, is to
identify the results of each query by a URI, so that I could re-GET
them over and over without those being counted as a hit against my 1000
(unless Google doesn't want to let you - a distinct possibility, sigh).

Anyhow, this is a bizarre case, because Google's business model on this
service is completely screwed.  They'd be much better off opening up
http://www.google.com/xml and saying "not for commercial use without
agreement".  So as an example to set precedence, you can pretty much
completely ignore Google.  Not that others won't try and copy them, but
they won't last either.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2354
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-04 15:11:24
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

>> I would agree with this analysis, except to me the presence 
>> of the Developer's Key changes how this issue needs to be 
>> approached.  IMO, the Developer's Key has an explicit impact 
>> on how the idea of a "safe method" should be interpreted.

> I don't see it as any different than the authorization info as part of
> an HTTP authentication transaction - it authenticates the user.  I
> don't see how it changes anything.

This is exactly the way I see it also, which is why I drew the 
analogy to the session timeout issue.  It seems to me that if 
you are calling this putative Google query unsafe, then you'd 
have to call anything that resets a session time-out clock  
unsafe too.  Do you?

From my perspective, while the user "did not request the side-effects" 
explicitly, in this context, the action isn't of "unexpected significance" 
either.

>> Interpreting safety this strictly, in this context, would seem to 
>> render an entire class of Web Services essentially un-GETable.  
>> It would seem to reinforce the perception that REST is only good 
>> for mostly public data.

> I don't see it that way.  Would you argue that a GET that bumped up a
> counter was safe?

What I meant was, in the future, there may be subscription-based 
Web Services that employ counters in this way - perhaps it doesn't 
lock out the resource completely when the user goes past a their limit, 
but it does have some side-effect.  

If conforming to a strict RESTian approach means that I can't use XSLT
to, say, extract a url out of a Google query:

  <xsl:variable name="url" select="document($google-search)//url"/>

then something ain't right.  You seem to be saying the entire 
business model itself ill-conceived, but I'm not so sure.

> .... what I didn't say, but would still try to do, is to
> identify the results of each query by a URI, so that I could re-GET
> them over and over without those being counted as a hit against my 1000
> (unless Google doesn't want to let you - a distinct possibility, sigh).

This is sort of a side-bar issue, but it would probably cost more for 
Google to keep that resource around than it would to simply re-execute 
the query. I doubt they'd go for it.

Couldn't they simply make the results cacheable for 24 hours on an
initial GET and be done with it?

> Anyhow, this is a bizarre case, because Google's business model on this
> service is completely screwed.  They'd be much better off opening up
> http://www.google.com/xml and saying "not for commercial use without
> agreement".  So as an example to set precedence, you can pretty much
> completely ignore Google.  Not that others won't try and copy them, but
> they won't last either.

I don't see this as particularly bizarre. Even today there are services that 
limit bandwidth etc.  This just seems like a more explicit metering - but 
then again, I'm not a business modeler. :)







-----------------------------------------------------------------------------------
Post ID:2355
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-04 15:46:15
Subject:Other view of DELETE? (was Re: GET: Shades of Grey)
Message:

From: "Miles Sabin" <miles@...>
>
> where "yields a result" seems to be refering to effects on the client.
> That can't be right tho', because if it were, DELETE wouldn't be
> idempotent: even tho' the effect of multiple DELETEs of the same
> resource is the same as just one on the server, it's likely that the
> client-visible result would differ: a 200 for the first invocation and
> 404s subsequently.

A thought occured to me about DELETE.  This is not specifically in response
to Mile's post, but the above paragraph did prompt the thought.  Bear with
me on this one.  It may take a while to get my "complete" thought out...

We all know that a URI is not a resource.  It is an identifier of a
representation of a resource.  The representation may or may not be
identical to the resource itself.  When we use PUT to create a resource,
what we are really doing is creating a resource for which the returned
representation of the same URI is the same as the data we uploaded.  In
reality, the server may use the request data to create additional resources
or even augment the data itself when creating the requested resource.  As
long as a subsequent GET on the same URI returns a representation that is
identical to the PUTted data, then everything is fine.  Given this, it seems
to me that it would be more correct to say that PUT creates a representation
of a resource, not the resource itself.  (frankly, I like this view more
than where PUT creates the actual resource).

But now this brings us to DELETE...  If you take a similar view as I do for
PUT, this means that DELETE only ever removes the representation, not the
resource itself!  Another way of looking at this is that DELETE invalidates
an otherwise valid identifier (URI).  The server itself may or may not do
anything with the data that was in the representation of the related URI.
This depends more on the application than on REST.

For instance, suppose we have a purchase order resource on the server.  It
has a representation identified by URI1.  At the same time, suppose we also
have another representation of the PO identified by URI2.  For clarity, URI1
returns a representation of the entire PO, while URI2 returns a
representation of only the header (billing address, shipping address, etc.).
Now, suppose we could DELETE URI2.  Does this delete the PO header?  Of
course not.  But it could very well cause URI2 to become invalidated (i.e.
subsequent requests to the same URI fail).

It also occurs to me that this could be an interesting way to implement
mutexes for a resource.  Successful creation of a URI that identifies a
resource indicates a lock.  Subsequent requests use the created URI to
access the resource.  When done, you DELETE the URI.  This releases the lock
but does not delete the underlying resource.

Well, I think that's it for now.  I hope it makes sense.  :~)

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2356
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-04 19:18:58
Subject:Re: [rest-discuss] Idempotent sequences
Message:

I wrote,
> Mathews, Walden wrote,
>
> > What's the trivial proof?  I also sense that it's easy, but if
> > it's that easy, then Alloy won't help.
>
> Hmm ... OK, this is a bit rough and ready, but let's see ...
<snip/>

No interest in this anyone? Or no opinions?

As a reminder this was the puzzle I posed earlier,

  Hmm ... spelt out this way, there's a trivial proof that all sequences 
  of idempotent requests are idempotent sequences. That means that
  either there's something wrong with spelling things out this way (in
  which case, what?), or there's something not quite right with 9.1

Thoughts?

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2357
Sender:DJ Adams <dj.adams@...>
Post Date/Time:2002-09-04 20:35:33
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

On Wed, Sep 04, 2002 at 09:43:21AM -0400, Mark Baker wrote:
> 
> I don't see it that way.  Would you argue that a GET that bumped up a
> counter was safe?

For me, this is the key question (and perhaps a little too tempting not
to address).

A safe operation is one that's not intended to modify the resource.
The resource in this Google example is the results of a search query. The
GET does not modify those results. 

The 'counter' isn't related to the resource being requested. Nor is it
(necessarily) exposed to the user. It's just a way for Google to work out
whether to allow you to make the query; it doesn't affect the query itself,
you can either make it or you can't. This is not significantly different
from a restriction based upon time of day, IP address of the client, or 
somesuch. I think there's perhaps a temptation to treat this '1001st request' 
example differently, because there's a loose sense of 'state' brought about
by association of state with previous calls. 

What if Google had performance problems (goodness forbid) and suddenly 
decided to restrict answering calls that day to clients that hadn't yet
made any ... and returned 500 (or another non-200 status) to those that
had - would the same 'unsafe' philosophy apply?

To bring in a point I made in a comment to the question/discussion [1]:
The Axioms document states 

  "It is wrong to represent the user doing a GET as ... doing any
  operation which effects the state of the Web or the state of the
  users relationship with the information provider or the server." [2]

Returning (e.g.) a 403 on the 1001st GET underlines, not undermines, the
relationship with the information provider and server.

In all, I'm having difficulty seeing this as an idempotency/side-effect
issue. I'd be grateful for any comments on the above.

Kind regards
dj (still learning)
http://www.pipetree.com/qmacro


[1] http://www.intertwingly.net/blog/?entry=784
[2] http://www.w3.org/DesignIssues/Axioms#state









-----------------------------------------------------------------------------------
Post ID:2358
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-04 21:15:28
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

On Wed, Sep 04, 2002 at 11:11:24AM -0400, Jeffrey Winter wrote:
> > I don't see it as any different than the authorization info as part of
> > an HTTP authentication transaction - it authenticates the user.  I
> > don't see how it changes anything.
> 
> This is exactly the way I see it also, which is why I drew the 
> analogy to the session timeout issue.  It seems to me that if 
> you are calling this putative Google query unsafe, then you'd 
> have to call anything that resets a session time-out clock  
> unsafe too.  Do you?

You mean a cookie session?  Those are stateful.

> >From my perspective, while the user "did not request the side-effects" 
> explicitly, in this context, the action isn't of "unexpected significance" 
> either.

Are you sure that the user didn't request the side-effect?  I believe
that they did, because the terms under which they're using the service
presumably say this (quick search turns up nothing except a FAQ).  They
understand that they can invoke it 1000 times per day.

What if you had a personal proxy which refreshed URIs for you, as
personal proxies are allowed to do?  If you've got a bunch of queries,
each with their own URI, this proxy may use up a sizable amount of

> > .... what I didn't say, but would still try to do, is to
> > identify the results of each query by a URI, so that I could re-GET
> > them over and over without those being counted as a hit against my 1000
> > (unless Google doesn't want to let you - a distinct possibility, sigh).
> 
> This is sort of a side-bar issue, but it would probably cost more for 
> Google to keep that resource around than it would to simply re-execute 
> the query. I doubt they'd go for it.

I'd guess it's at least an order of magnitude cheaper for them to hit
a cache than it is for them to re-query.

> Couldn't they simply make the results cacheable for 24 hours on an
> initial GET and be done with it?

No, because of the aforementioned "unsafe GET" issue.

Well, they could just drop the limit.  They say it's their for "lack of
resources"[1], but I don't buy that.  It's to test the market for
queries.

 [1] http://www.google.com/apis/api_faq.html#gen12

To DJ, "GET should be safe" is not a comment on the resource being
GETted, it's a general comment; no consequential state, as determined
by the server owner, should change as a result of a GET.  Otherwise
people would be afraid to click on links.

And BTW, I think this thread is well named.  It is shades of grey.  But
to SOAP proponents who somehow think this validates their approach, it
does not, because you're not even using POST.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2359
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-04 21:31:10
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

>> I don't see it that way.  Would you argue that a GET that bumped up a
>> counter was safe?

> For me, this is the key question (and perhaps a little too tempting not
> to address).

Okay, there's a qualitative difference between a GET that simply
bumps up a counter, which is *generally* safe, and one that triggers a
more meaningful state change, which is *generally* not safe.

> The resource in this Google example is the results of a search query. The
> GET does not modify those results.

Even if the GET does modify the results it's not necessarily unsafe (e.g., the
resource may contain the counter of the number of times it's been accessed)

Conversely even if the GET doesn't modify the results it's not necessarily
safe (e.g., accessing the resources always returns the same result, but
unbeknownst to the user, deducts five dollars from their checking account)

> The 'counter' isn't related to the resource being requested. Nor is it
> (necessarily) exposed to the user.

I don't see how you can say that it isn't related to the resource being
requested;
its whole purpose is to count the number of times it's been accessed which
seems like
a pretty important relationship.

I actually agree with Mark in the general case: a URL that suddenly starts
to return 403 when dereferenced via GET some magic number of times is bad
practice.  A user should, in general, be able to blithely dereference URIs
using
GET without it having any impact on the web they are using.

Where I see the line being drawn though is when this dereferencing is
happening
within the context of a known authorization relationship with that web.  That
authorization was given under the explicit terms that that specific resources
will only be accessed a limited number of times.  Given those terms, I no
longer
see the change as being of "unexpected significance"; in fact it has precisely
the
significance that the user expected it to have, which would make it safe.












-----------------------------------------------------------------------------------
Post ID:2360
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-04 21:39:29
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

>> This is exactly the way I see it also, which is why I drew the 
>> analogy to the session timeout issue.  It seems to me that if 
>> you are calling this putative Google query unsafe, then you'd 
>> have to call anything that resets a session time-out clock  
>> unsafe too.  Do you?

> You mean a cookie session?  Those are stateful.

What I was really refering to was something along the lines of:

    www.mysite.com/session/1234/some-resource

A session resource is established via some authorization mechanism 
that will time-out if not accessed within some time period. 

> What if you had a personal proxy which refreshed URIs for you, as
> personal proxies are allowed to do?  If you've got a bunch of queries,
> each with their own URI, this proxy may use up a sizable amount of

Yikes.  Well that certainly changes things...  But, what if the resources
were marked "no-cache"?

Thanks for the feedback,

Jeff









-----------------------------------------------------------------------------------
Post ID:2361
Sender:DJ Adams <dj.adams@...>
Post Date/Time:2002-09-04 22:03:14
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

On Wed, Sep 04, 2002 at 05:31:10PM -0400, Jeffrey Winter wrote:
> > The 'counter' isn't related to the resource being requested. Nor is it
> > (necessarily) exposed to the user.
> 
> I don't see how you can say that it isn't related to the resource being
> requested;
> its whole purpose is to count the number of times it's been accessed which
> seems like
> a pretty important relationship.

It's not related to the specific resource being requested at any point in
time - it's a counter for queries in general. I could query for 'apple'
then 'banana' and the same counter is incremented.

> authorization was given under the explicit terms that that specific resources
> will only be accessed a limited number of times.  Given those terms, I no
> longer
> see the change as being of "unexpected significance"; in fact it has precisely
> the
> significance that the user expected it to have, which would make it safe.

Indeed, one could (perversely) argue that not to give a 403 (or whatever)
in the context of Google's current T&Cs would be of unexpected significance.

I agree with (most people, I suppose) in that the key thing here is that
there's no black and white. 

dj






-----------------------------------------------------------------------------------
Post ID:2362
Sender:DJ Adams <dj.adams@...>
Post Date/Time:2002-09-04 22:09:33
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

On Wed, Sep 04, 2002 at 05:15:28PM -0400, Mark Baker wrote:

> by the server owner, should change as a result of a GET.  Otherwise
> people would be afraid to click on links.

<smile/> I think this last sentence is a clincher. Although this whole 
unsafeness of Google GETs just doesn't seem quite right (to me), I am
struck by the whole (printed) weight of the works (on which REST err,
rests) which those words carry.

Thanks
dj






-----------------------------------------------------------------------------------
Post ID:2363
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-05 01:53:23
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

On Wed, Sep 04, 2002 at 05:39:29PM -0400, Jeffrey Winter wrote:
> > You mean a cookie session?  Those are stateful.
> 
> What I was really refering to was something along the lines of:
> 
>     www.mysite.com/session/1234/some-resource
>
> A session resource is established via some authorization mechanism 
> that will time-out if not accessed within some time period. 

Why is the timeout needed?  You shouldn't need to timeout if you're
doing things statelessly, because the server doesn't have to remember
anything; all you need to know about authorization is in the request.

> > What if you had a personal proxy which refreshed URIs for you, as
> > personal proxies are allowed to do?  If you've got a bunch of queries,
> > each with their own URI, this proxy may use up a sizable amount of
> 
> Yikes.  Well that certainly changes things...  But, what if the resources
> were marked "no-cache"?

That's worse!  It will mean that more GETs will have to happen, because
the responses from the old ones aren't any good any longer. 8-O

> Thanks for the feedback,

No problem.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2364
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-05 04:01:38
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

----- Original Message ----- 
From: "DJ Adams" <dj.adams@...>

> The resource in this Google example is the results of a search query. 
Bingo. Emphasis on the 'results'.

> The GET does not modify those results. 
> The 'counter' isn't related to the resource being requested. 








-----------------------------------------------------------------------------------
Post ID:2365
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-05 03:55:17
Subject:Re: [rest-discuss] Other view of DELETE? (was Re: GET: Shades of Grey)
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

>
> We all know that a URI is not a resource.  It is an identifier of a
> representation of a resource.  The representation may or may not be
> identical to the resource itself.
I'm pretty sure the URI identifies the resource, not a representation.
Representations are transient things - unless you explicitly make the
representation a resource in its own right - but that gets fractally complex
(representations of a representation of a resource, etc.).


>
> For instance, suppose we have a purchase order resource on the server.  It
> has a representation identified by URI1.  At the same time, suppose we
also
> have another representation of the PO identified by URI2.
There would then be two resources. 'The PO' would be URI1, and 'The PO
headers' would be URI2. The data returned by URI2 also happens to be
available within the data returned by URI1.

This gets into what I call 'overlapping resources' (a possibly poor term,
but it works for me..) I think of URI2 as a 'synthetic resource' or a
'derived resource'. Operations like DELETE might not actually do anything -
either indicated by 'not implemented' or some other response - or they
might, its up to the application to decide.

Just my opinions though.








-----------------------------------------------------------------------------------
Post ID:2366
Sender:"firepipe_au" <michael@...>
Post Date/Time:2002-09-05 05:16:33
Subject:Other view of DELETE? (was Re: GET: Shades of Grey)
Message:

--- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote:
> 
> ----- Original Message -----
> From: "Seairth Jacobs" <seairth@s...>
> 
> >
> > We all know that a URI is not a resource.  It is an identifier of 
a
> > representation of a resource.  The representation may or may not 
be
> > identical to the resource itself.
> I'm pretty sure the URI identifies the resource, not a 
representation.
> Representations are transient things - unless you explicitly make 
the
> representation a resource in its own right - but that gets 
fractally complex
> (representations of a representation of a resource, etc.).
>

From the w3c's introduction to HTML:

  "Every resource available on the Web -- HTML document, image,
  video clip, program, etc. -- has an address that may be encoded
  by a Universal Resource Identifier, or "URI"...
  Some URIs refer to a location within a resource. This kind of URI
  ends with "#" followed by an anchor identifier (called the fragment
  identifier). For instance, here is a URI pointing to an anchor
  named section_2:

  http://somesite.com/html/top.html#section_2"

So a URI can identify a resource, or it can identify a fragment of a 
resource.  Just because you can identify something as a fragment of
something else using URIs doesn't necessarily mean that what you're 
identifying is a resource.

> 
> >
> > For instance, suppose we have a purchase order resource on the 
server.  It
> > has a representation identified by URI1.  At the same time, 
suppose we
> also
> > have another representation of the PO identified by URI2.
> There would then be two resources. 'The PO' would be URI1, and 'The 
PO
> headers' would be URI2. The data returned by URI2 also happens to be
> available within the data returned by URI1.
> 
> This gets into what I call 'overlapping resources' (a possibly poor 
term,
> but it works for me..) I think of URI2 as a 'synthetic resource' or 
a
> 'derived resource'. Operations like DELETE might not actually do 
anything -
> either indicated by 'not implemented' or some other response - or 
they
> might, its up to the application to decide.
> 
> Just my opinions though.

I wouldn't consider URI2 a resource at all.  Why not define it as 
a 'fragment'.  We're used to seeing browsers retrieving a resource 
and then scrolling to the fragment we require - this doesn't 
necessarily have to be the case.  If the fragment is truly such, and 
we have specified only requiring the fragment using '#fragment' why 
do we need the whole reource?  Why can't we just retrieve the 
fragment, keeping in mind that it is only that?

It's a matter of granularity, and I agree with S. Mike here, in so 
far as it becomes 'fractally complex' to start defining fragments of 
resources as resources in themselves - this behaviour begs the 
question of 'where does it end?'  Individual paragraphs?  Words?  
It's not as facetious as it would seem - the words in a resource are 
significant to a client such as Google who wants to index your 
resource and they become processable 'fragments' in that context.

I've never seen it done before, but imagine POSTing, PUTting or 
DELETE-ing to a fragment URI...  If the resource in question is 
represented as XML, each node (or perhaps child or sibling element) 
would by definition be an 'addressable' fragment that removes the 
need to pass around whole resources - especially significant when a 
resource contains a long history of modifications/operations/etc.  
I'm recalling the legal issues raised here a few days ago, and the 
need to share documents such as contracts whole - defining part of a 
contract as a separate resource removes the context, but defining 
that same part as a fragment seems to me to naturally imply that the 
context exists without needing to pass around the whole thing every 
time someone wants to reference/alter a clause ("You requested part 
of the resource, let it be on your head if you misunderstand the 
context").

I suppose it all boils down to a resource being defined as something 
that can be conceived of as being 'discrete' or 'atomic'.  (IMHO)









-----------------------------------------------------------------------------------
Post ID:2367
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-09-05 08:21:56
Subject:RE: [rest-discuss] Other view of DELETE? (was Re: GET: Shades of Grey)
Message:

> -----Original Message-----
> From: firepipe_au [mailto:michael@...]
> Sent: Thursday, September 05, 2002 7:17 AM
> To: rest-discuss@yahoogroups.com
> Subject: [rest-discuss] Other view of DELETE? (was Re: GET: Shades of
> Grey)
>...
>
> So a URI can identify a resource, or it can identify a fragment of a

...in which case it's not a URI but a URI reference....

> resource.  Just because you can identify something as a fragment of
> something else using URIs doesn't necessarily mean that what you're
> identifying is a resource.

Yes, that's what it means. Anything that has identity is a resource, and if
you have a name for it (the URI reference), how can you say it hasn't
identity?

> I've never seen it done before, but imagine POSTing, PUTting or
> DELETE-ing to a fragment URI...  If the resource in question is

You don't. HTTP methods operate on HTTP URLs (URIs), not HTTP URLs +
fragment identifierts (URI references).

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760







-----------------------------------------------------------------------------------
Post ID:2368
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-05 14:08:10
Subject:RE: [rest-discuss] Idempotent sequences
Message:

Miles,

I think that for my part I am convinced that by using a rigorous
interpretation of 'idempotent' that your proof is valid, which
leaves me also wondering what Roy meant.  Possibly he was merely
trying to avoid the assertion that a series of idempotent functions
is idempotent, as opposed to asserting that there are actual
counter-examples to that, as we seem to interpret him.  I dunno.

Your proof reminded me of an analysis I did a couple of years
ago for processing SQL trigger results represented as lists of
deletes and inserts for an entire transaction, especially the
technique of looking only at the beginning and the end of each
sequence.

I suspect that any disagreement about the idempotence of a string
of idempotent HTTP operations has more to do with the way you
might map HTTP operations onto the meaning of 'idempotent' than
with the particular proof you offered.  We touched on this before.
What is the 'function' of an HTTP PUT?  I.e., which mapping are
we interested in?  Clearly, sometimes it's resource before-and-after
state.  At other times it may be more like request-to-response
mapping?

I'm still open to trying an Alloy model, but I have a hunch that
it won't provide any more insight into the problem than your proof
has already given.

Walden

> -----Original Message-----
> From: Miles Sabin [mailto:miles@...]
> Sent: Wednesday, September 04, 2002 3:19 PM
> To: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Idempotent sequences
> 
> 
> I wrote,
> > Mathews, Walden wrote,
> >
> > > What's the trivial proof?  I also sense that it's easy, but if
> > > it's that easy, then Alloy won't help.
> >
> > Hmm ... OK, this is a bit rough and ready, but let's see ...
> <snip/>
> 
> No interest in this anyone? Or no opinions?
> 
> As a reminder this was the puzzle I posed earlier,
> 
>   Hmm ... spelt out this way, there's a trivial proof that 
> all sequences 
>   of idempotent requests are idempotent sequences. That means that
>   either there's something wrong with spelling things out this way (in
>   which case, what?), or there's something not quite right with 9.1
> 
> Thoughts?
> 
> Cheers,
> 
> 
> Miles
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2369
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-05 15:08:34
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

>> What I was really referring to was something along the lines of:
>> 
>>     www.mysite.com/session/1234/some-resource
>>
>> A session resource is established via some authorization mechanism 
>> that will time-out if not accessed within some time period. 
>
> Why is the timeout needed?  

I've seen this done to provide an extra modicum of security 
or privacy protection at sites that might be used in public 
places.  The concern is that someone might go to a library and 
check their bank balance and forget to shutdown the browser, 
allowing another person to come along and continue to use the 
credentials provided by the first user.  A time-out at least
limits their exposure.

Allowing for this sort of time-out with a GET-able interface
would require a similar kind of mechanism that the Google 
interface would have if it used GET.  So, my only point was
that if one is willing to grant that this is "safe" then a 
case could be made that it would be okay for Google.

>> But, what if the resources were marked "no-cache"?

> That's worse!  It will mean that more GETs will have to happen, because
> the responses from the old ones aren't any good any longer. 8-O

Right. It was really a poorly phrased question to understand 
what the rules are for proxy cache refreshing.  

- Jeff










-----------------------------------------------------------------------------------
Post ID:2370
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-09-05 15:35:16
Subject:RE: [rest-discuss] GET: Shades of Grey
Message:

> From: Jeffrey Winter [mailto:j.winter@...]
>
> > Mark Baker:
> > Why is the timeout needed?
> 
> I've seen this done to provide an extra modicum of security
> or privacy protection at sites that might be used in public 
> places.  The concern is that someone might go to a library and 
> check their bank balance and forget to shutdown the browser, 
> allowing another person to come along and continue to use the 
> credentials provided by the first user.  A time-out at least 
> limits their exposure.

Timeouts are also used to mange server load; which wouldn't be a problem
with systems that didn't use server sided sessions - then again there's
a lot of sites on the web that use sessions. And timeouts aren't even
sufficient in some cases. In a non-GET scenario, it's possible to have a
browser resubmit a login page simply by refreshing what looks like a
different page or hitting the back button *after* you logout (and your
session is closed on the server). This can happen easily enough with
controller type architectures (considered best practice in servlets/jsp
land), where you GET a login page, POST the login and are redirected
behind the scenes to an inbox page; if you POST logout and refresh
(POST) the inbox page, chances are be logged back in (or maybe someone
else will log you back). I like the idea of stateless servers and client
sided session management, but you'd need to throw out a lot of sites and
browsers to see that realized. 

Bill de hra 
--
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:2371
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-05 17:40:12
Subject:Resources vs. Representations (was Re: Other view of DELETE?)
Message:

----- Original Message -----
From: "S. Mike Dierken" <mdierken@...>
>
> I'm pretty sure the URI identifies the resource, not a representation.
> Representations are transient things - unless you explicitly make the
> representation a resource in its own right - but that gets fractally
complex
> (representations of a representation of a resource, etc.).

But this doesn't jive with my understanding of REST.  You can never retrieve
a resource.  You can only ever retrieve a representation of a resource.  If
you want, you could call the representation a "virtual" resource, meaning
that it can logically be treated as a resource, but does not necessarily
have a direct correlation with an actual resource on the server.

I don't see where anything gets complex here.  All that one can ever
retrieve is a representation of a resource.  If you have two (or two
hundred) URIs, each returns a representation of a resource.  If you take my
PurchaseOrder URI1 and URI2 examples, URI2 is not a representation of a
representation of the resource pointed to by URI1.  URI2 returns a
representation of a resource.  URI1 returns a representation of a resource.
Sure, they may both be pointing to the same resource, but that doesn't mean
that URI2 is subordinate to URI1.  If that *were* the case, it would mean to
me that URI1 is now synonymous for the resource itself.  This would mean
that a request to get the resource must return the resource itself, which we
know is not possible.  Therefore, URI1 can only even be synonymous with a
representation of a resource, which also means that URI2 cannot be
subordinate to URI1.

> This gets into what I call 'overlapping resources' (a possibly poor term,
> but it works for me..) I think of URI2 as a 'synthetic resource' or a
> 'derived resource'. Operations like DELETE might not actually do
anything -
> either indicated by 'not implemented' or some other response - or they
> might, its up to the application to decide.

So, based on what you are saying, if I were to add a querystring to the URI
such that the returned data was potentially different, each valid variation
of the querystring points to separate resource?  Using the
URI->Representation POV, the querystring would returns different
representations of the same resource.

I wonder if "view" would be a better word than "representation"?  Using the
"view" imagery (warning: some may consider this very unRESTful):

1)  A "view" is the data returned by a server.  Each view has its own URI.
More than one URI may return identical views, but they are not the same
view.  In other words, there is a one-to-one relationship between views and
URIs.

2) A view is not the same as a resource.  A view may be identical to a
resource, but it is not the resource itself.

3) PUT only creates association between a URI and a view with the added
restriction that a subsequent GET of the URI returns the same view.  The PUT
may cause the server to create a new resource or update an existing
resource.  The actual resource may be different than the view created by the
PUT as long as the view does not change.

4) GET only returns views of a resource.  Idempotency of a GET means that
the "intent" of the GET is to return a view only.  A GET may be considered
idempotent even though resources are altered on the server as long as the
GET wasn't being used to cause the alteration.

5) POST sends data to a URI.  It is not sending the data to a view (views
are what's returned).  In this case, URIs are "black boxes", into which
anything may be sent (though not necessarily accepted).  The function of a
POST is not strictly defined, except that it does imply an intent to alter a
resource (and is therefore not idempotent).  A view of the target resource
may be returned by the server.  The contents of the view are entirely
subject to the purpose of the POST.

6) DELETE only destroys or invalidates a view (and therefore the URI that
identified the view).  DELETE does not necessarily cause the deletion of the
underlying resource.  For instance, a single resource may have multiple
views (accessible by multiple URIs).  The server may only delete the
resource after all of the views have been DELETEd.  DELETEing just one view
would not, in this case, cause the underlying resource to be deleted (or
even necessarily altered).


What this means is a clear picture of where the coupling is: between the
view and the resource.  This means that the server has full control over how
tightly or loosely coupled the resource is to the view that the clients
receive.  What I mean by coupling here is the internal relationship of the
expressed view to the actual resource.  Loose coupling means that while the
view is related to the resource, it is not a direct corollary for the
resource.  Tight coupling, on the other hand, means that the view is more of
(or a direct) corollary for it's related resource.  To illustrate, the two
servers in the following example both provide identical views and therefore
identical functionality from the client's POV, while internally handling the
resources differently.

Server 1 (tight coupling):

PUT <data> /path/file.html : creates a file and puts <data> inside that
file.
GET /path/file.html : opens the file and returns <data> inside that file.
DELETE /path/file.html : deletes the file.
POST <data> /path/file.html : invalid request.

Server 2 (loose coupling):

PUT <data> /path/file.html : takes data, chops it up in several fragments
(for internal reasons) and places those fragments into a table on an SQL
server.  At the same time, it also processes and adds keywords to an index
table.  Further, it creates additional internal resources to provide links
between <data> and the user that uploaded.
GET /path/file.html : queries the SQL server and reconstructs <data> from
its individual fragments.
DELETE /path/file.html : only deletes access to the resource via this URI.
However, since no other URIs are pointing to the same resource in this
particular case, the server proceeds to delete the records in the SQL server
and all related resources.
POST <data> /path/file.html : invalid request.



I'm going to stop here for now.  I have had to step away from this message
about 15 times so now I have somewhat lost my train of thought.  What I have
above appears to be coherent to me, so I will start with this.  Now for the
fun part... in what way(s) is this view wrong?  :)

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2372
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-05 17:52:11
Subject:RE: [rest-discuss] Resources vs. Representations (was Re: Other v iew of DELETE?)
Message:

Seairth,

Your post is rather long and I only skimmed it, so apologies if
I missed important material.  I think the REST model says that there
are resources, representations and identifiers.  A resource may have
more than one identifier, but an identifier identifies only a single
resource.  A resource may have many representations, but a given
representation is a representation of only one resource (although
it may look an awful lot like some representation of some other
resource).  When you request the state of a resource (GET), you will
be given the representation that the server feels is most appropriate
for you in the circumstances.  Content negotiation headers aside,
you cannot directly request a particular representation of a resource.

You cannot directly address a representation.  If you could, then the
representation would, by definition, be a resource, which implies
that it also has representations, and hence the fractalness of resource
that Mike D pointed out.

The indirection of representations you are required to wade through
on your way to accessing resources is what accounts for the 'conceptual'
nature of those resources, more or less.

This model seems self-consistent.  Or does it?

Walden

> -----Original Message-----
> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Thursday, September 05, 2002 1:40 PM
> To: rest-discuss; S. Mike Dierken
> Subject: [rest-discuss] Resources vs. Representations (was Re: Other
> view of DELETE?)
> 
> 
> 
> ----- Original Message -----
> From: "S. Mike Dierken" <mdierken@...>
> >
> > I'm pretty sure the URI identifies the resource, not a 
> representation.
> > Representations are transient things - unless you 
> explicitly make the
> > representation a resource in its own right - but that gets fractally
> complex
> > (representations of a representation of a resource, etc.).
> 
> But this doesn't jive with my understanding of REST.  You can 
> never retrieve
> a resource.  You can only ever retrieve a representation of a 
> resource.  If
> you want, you could call the representation a "virtual" 
> resource, meaning
> that it can logically be treated as a resource, but does not 
> necessarily
> have a direct correlation with an actual resource on the server.
> 
> I don't see where anything gets complex here.  All that one can ever
> retrieve is a representation of a resource.  If you have two (or two
> hundred) URIs, each returns a representation of a resource.  
> If you take my
> PurchaseOrder URI1 and URI2 examples, URI2 is not a 
> representation of a
> representation of the resource pointed to by URI1.  URI2 returns a
> representation of a resource.  URI1 returns a representation 
> of a resource.
> Sure, they may both be pointing to the same resource, but 
> that doesn't mean
> that URI2 is subordinate to URI1.  If that *were* the case, 
> it would mean to
> me that URI1 is now synonymous for the resource itself.  This 
> would mean
> that a request to get the resource must return the resource 
> itself, which we
> know is not possible.  Therefore, URI1 can only even be 
> synonymous with a
> representation of a resource, which also means that URI2 cannot be
> subordinate to URI1.
> 
> > This gets into what I call 'overlapping resources' (a 
> possibly poor term,
> > but it works for me..) I think of URI2 as a 'synthetic 
> resource' or a
> > 'derived resource'. Operations like DELETE might not actually do
> anything -
> > either indicated by 'not implemented' or some other 
> response - or they
> > might, its up to the application to decide.
> 
> So, based on what you are saying, if I were to add a 
> querystring to the URI
> such that the returned data was potentially different, each 
> valid variation
> of the querystring points to separate resource?  Using the
> URI->Representation POV, the querystring would returns different
> representations of the same resource.
> 
> I wonder if "view" would be a better word than 
> "representation"?  Using the
> "view" imagery (warning: some may consider this very unRESTful):
> 
> 1)  A "view" is the data returned by a server.  Each view has 
> its own URI.
> More than one URI may return identical views, but they are 
> not the same
> view.  In other words, there is a one-to-one relationship 
> between views and
> URIs.
> 
> 2) A view is not the same as a resource.  A view may be identical to a
> resource, but it is not the resource itself.
> 
> 3) PUT only creates association between a URI and a view with 
> the added
> restriction that a subsequent GET of the URI returns the same 
> view.  The PUT
> may cause the server to create a new resource or update an existing
> resource.  The actual resource may be different than the view 
> created by the
> PUT as long as the view does not change.
> 
> 4) GET only returns views of a resource.  Idempotency of a 
> GET means that
> the "intent" of the GET is to return a view only.  A GET may 
> be considered
> idempotent even though resources are altered on the server as 
> long as the
> GET wasn't being used to cause the alteration.
> 
> 5) POST sends data to a URI.  It is not sending the data to a 
> view (views
> are what's returned).  In this case, URIs are "black boxes", 
> into which
> anything may be sent (though not necessarily accepted).  The 
> function of a
> POST is not strictly defined, except that it does imply an 
> intent to alter a
> resource (and is therefore not idempotent).  A view of the 
> target resource
> may be returned by the server.  The contents of the view are entirely
> subject to the purpose of the POST.
> 
> 6) DELETE only destroys or invalidates a view (and therefore 
> the URI that
> identified the view).  DELETE does not necessarily cause the 
> deletion of the
> underlying resource.  For instance, a single resource may 
> have multiple
> views (accessible by multiple URIs).  The server may only delete the
> resource after all of the views have been DELETEd.  DELETEing 
> just one view
> would not, in this case, cause the underlying resource to be 
> deleted (or
> even necessarily altered).
> 
> 
> What this means is a clear picture of where the coupling is: 
> between the
> view and the resource.  This means that the server has full 
> control over how
> tightly or loosely coupled the resource is to the view that 
> the clients
> receive.  What I mean by coupling here is the internal 
> relationship of the
> expressed view to the actual resource.  Loose coupling means 
> that while the
> view is related to the resource, it is not a direct corollary for the
> resource.  Tight coupling, on the other hand, means that the 
> view is more of
> (or a direct) corollary for it's related resource.  To 
> illustrate, the two
> servers in the following example both provide identical views 
> and therefore
> identical functionality from the client's POV, while 
> internally handling the
> resources differently.
> 
> Server 1 (tight coupling):
> 
> PUT <data> /path/file.html : creates a file and puts <data> 
> inside that
> file.
> GET /path/file.html : opens the file and returns <data> 
> inside that file.
> DELETE /path/file.html : deletes the file.
> POST <data> /path/file.html : invalid request.
> 
> Server 2 (loose coupling):
> 
> PUT <data> /path/file.html : takes data, chops it up in 
> several fragments
> (for internal reasons) and places those fragments into a 
> table on an SQL
> server.  At the same time, it also processes and adds 
> keywords to an index
> table.  Further, it creates additional internal resources to 
> provide links
> between <data> and the user that uploaded.
> GET /path/file.html : queries the SQL server and reconstructs 
> <data> from
> its individual fragments.
> DELETE /path/file.html : only deletes access to the resource 
> via this URI.
> However, since no other URIs are pointing to the same resource in this
> particular case, the server proceeds to delete the records in 
> the SQL server
> and all related resources.
> POST <data> /path/file.html : invalid request.
> 
> 
> 
> I'm going to stop here for now.  I have had to step away from 
> this message
> about 15 times so now I have somewhat lost my train of 
> thought.  What I have
> above appears to be coherent to me, so I will start with 
> this.  Now for the
> fun part... in what way(s) is this view wrong?  :)
> 
> ---
> Seairth Jacobs
> seairth@...
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2373
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-05 17:59:40
Subject:RE: [rest-discuss] Resources vs. Representations
Message:

Oh, I wanted to say one other thing on this subject.  There is
this idea that if we PUT a resource through its URI, then we GET
that resource back, we should get back the same value as we PUT.
That statement implies that we have representation-level control,
which we do not.  It would make more sense to think of it this
way.  If we PUT a representation to a URI, then GET back a representation,
the latter representation *means the same thing* as the former,
though it may differ in format or even typographically.  THoughts?

Walden

> -----Original Message-----
> From: Mathews, Walden 
> Sent: Thursday, September 05, 2002 1:52 PM
> To: 'Seairth Jacobs'; rest-discuss; S. Mike Dierken
> Subject: RE: [rest-discuss] Resources vs. Representations 
> (was Re: Other
> v iew of DELETE?)
> 
> 
> Seairth,
> 
> Your post is rather long and I only skimmed it, so apologies if
> I missed important material.  I think the REST model says that there
> are resources, representations and identifiers.  A resource may have
> more than one identifier, but an identifier identifies only a single
> resource.  A resource may have many representations, but a given
> representation is a representation of only one resource (although
> it may look an awful lot like some representation of some other
> resource).  When you request the state of a resource (GET), you will
> be given the representation that the server feels is most appropriate
> for you in the circumstances.  Content negotiation headers aside,
> you cannot directly request a particular representation of a resource.
> 
> You cannot directly address a representation.  If you could, then the
> representation would, by definition, be a resource, which implies
> that it also has representations, and hence the fractalness 
> of resource
> that Mike D pointed out.
> 
> The indirection of representations you are required to wade through
> on your way to accessing resources is what accounts for the 
> 'conceptual'
> nature of those resources, more or less.
> 
> This model seems self-consistent.  Or does it?
> 
> Walden
> 
> > -----Original Message-----
> > From: Seairth Jacobs [mailto:seairth@...]
> > Sent: Thursday, September 05, 2002 1:40 PM
> > To: rest-discuss; S. Mike Dierken
> > Subject: [rest-discuss] Resources vs. Representations (was Re: Other
> > view of DELETE?)
> > 
> > 
> > 
> > ----- Original Message -----
> > From: "S. Mike Dierken" <mdierken@...>
> > >
> > > I'm pretty sure the URI identifies the resource, not a 
> > representation.
> > > Representations are transient things - unless you 
> > explicitly make the
> > > representation a resource in its own right - but that 
> gets fractally
> > complex
> > > (representations of a representation of a resource, etc.).
> > 
> > But this doesn't jive with my understanding of REST.  You can 
> > never retrieve
> > a resource.  You can only ever retrieve a representation of a 
> > resource.  If
> > you want, you could call the representation a "virtual" 
> > resource, meaning
> > that it can logically be treated as a resource, but does not 
> > necessarily
> > have a direct correlation with an actual resource on the server.
> > 
> > I don't see where anything gets complex here.  All that one can ever
> > retrieve is a representation of a resource.  If you have two (or two
> > hundred) URIs, each returns a representation of a resource.  
> > If you take my
> > PurchaseOrder URI1 and URI2 examples, URI2 is not a 
> > representation of a
> > representation of the resource pointed to by URI1.  URI2 returns a
> > representation of a resource.  URI1 returns a representation 
> > of a resource.
> > Sure, they may both be pointing to the same resource, but 
> > that doesn't mean
> > that URI2 is subordinate to URI1.  If that *were* the case, 
> > it would mean to
> > me that URI1 is now synonymous for the resource itself.  This 
> > would mean
> > that a request to get the resource must return the resource 
> > itself, which we
> > know is not possible.  Therefore, URI1 can only even be 
> > synonymous with a
> > representation of a resource, which also means that URI2 cannot be
> > subordinate to URI1.
> > 
> > > This gets into what I call 'overlapping resources' (a 
> > possibly poor term,
> > > but it works for me..) I think of URI2 as a 'synthetic 
> > resource' or a
> > > 'derived resource'. Operations like DELETE might not actually do
> > anything -
> > > either indicated by 'not implemented' or some other 
> > response - or they
> > > might, its up to the application to decide.
> > 
> > So, based on what you are saying, if I were to add a 
> > querystring to the URI
> > such that the returned data was potentially different, each 
> > valid variation
> > of the querystring points to separate resource?  Using the
> > URI->Representation POV, the querystring would returns different
> > representations of the same resource.
> > 
> > I wonder if "view" would be a better word than 
> > "representation"?  Using the
> > "view" imagery (warning: some may consider this very unRESTful):
> > 
> > 1)  A "view" is the data returned by a server.  Each view has 
> > its own URI.
> > More than one URI may return identical views, but they are 
> > not the same
> > view.  In other words, there is a one-to-one relationship 
> > between views and
> > URIs.
> > 
> > 2) A view is not the same as a resource.  A view may be 
> identical to a
> > resource, but it is not the resource itself.
> > 
> > 3) PUT only creates association between a URI and a view with 
> > the added
> > restriction that a subsequent GET of the URI returns the same 
> > view.  The PUT
> > may cause the server to create a new resource or update an existing
> > resource.  The actual resource may be different than the view 
> > created by the
> > PUT as long as the view does not change.
> > 
> > 4) GET only returns views of a resource.  Idempotency of a 
> > GET means that
> > the "intent" of the GET is to return a view only.  A GET may 
> > be considered
> > idempotent even though resources are altered on the server as 
> > long as the
> > GET wasn't being used to cause the alteration.
> > 
> > 5) POST sends data to a URI.  It is not sending the data to a 
> > view (views
> > are what's returned).  In this case, URIs are "black boxes", 
> > into which
> > anything may be sent (though not necessarily accepted).  The 
> > function of a
> > POST is not strictly defined, except that it does imply an 
> > intent to alter a
> > resource (and is therefore not idempotent).  A view of the 
> > target resource
> > may be returned by the server.  The contents of the view 
> are entirely
> > subject to the purpose of the POST.
> > 
> > 6) DELETE only destroys or invalidates a view (and therefore 
> > the URI that
> > identified the view).  DELETE does not necessarily cause the 
> > deletion of the
> > underlying resource.  For instance, a single resource may 
> > have multiple
> > views (accessible by multiple URIs).  The server may only delete the
> > resource after all of the views have been DELETEd.  DELETEing 
> > just one view
> > would not, in this case, cause the underlying resource to be 
> > deleted (or
> > even necessarily altered).
> > 
> > 
> > What this means is a clear picture of where the coupling is: 
> > between the
> > view and the resource.  This means that the server has full 
> > control over how
> > tightly or loosely coupled the resource is to the view that 
> > the clients
> > receive.  What I mean by coupling here is the internal 
> > relationship of the
> > expressed view to the actual resource.  Loose coupling means 
> > that while the
> > view is related to the resource, it is not a direct 
> corollary for the
> > resource.  Tight coupling, on the other hand, means that the 
> > view is more of
> > (or a direct) corollary for it's related resource.  To 
> > illustrate, the two
> > servers in the following example both provide identical views 
> > and therefore
> > identical functionality from the client's POV, while 
> > internally handling the
> > resources differently.
> > 
> > Server 1 (tight coupling):
> > 
> > PUT <data> /path/file.html : creates a file and puts <data> 
> > inside that
> > file.
> > GET /path/file.html : opens the file and returns <data> 
> > inside that file.
> > DELETE /path/file.html : deletes the file.
> > POST <data> /path/file.html : invalid request.
> > 
> > Server 2 (loose coupling):
> > 
> > PUT <data> /path/file.html : takes data, chops it up in 
> > several fragments
> > (for internal reasons) and places those fragments into a 
> > table on an SQL
> > server.  At the same time, it also processes and adds 
> > keywords to an index
> > table.  Further, it creates additional internal resources to 
> > provide links
> > between <data> and the user that uploaded.
> > GET /path/file.html : queries the SQL server and reconstructs 
> > <data> from
> > its individual fragments.
> > DELETE /path/file.html : only deletes access to the resource 
> > via this URI.
> > However, since no other URIs are pointing to the same 
> resource in this
> > particular case, the server proceeds to delete the records in 
> > the SQL server
> > and all related resources.
> > POST <data> /path/file.html : invalid request.
> > 
> > 
> > 
> > I'm going to stop here for now.  I have had to step away from 
> > this message
> > about 15 times so now I have somewhat lost my train of 
> > thought.  What I have
> > above appears to be coherent to me, so I will start with 
> > this.  Now for the
> > fun part... in what way(s) is this view wrong?  :)
> > 
> > ---
> > Seairth Jacobs
> > seairth@...
> > 
> > 
> > ------------------------ Yahoo! Groups Sponsor 
> > ---------------------~-->
> > 4 DVDs Free +s&p Join Now
> > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> > --------------------------------------------------------------
> > -------~->
> > 
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> > 
> >  
> > 
> > Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Looking for a more powerful website? Try GeoCities for $8.95 
> per month.
> Register your domain name (http://your-name.com). More 
> storage! No ads!
> http://geocities.yahoo.com/ps/info
> http://us.click.yahoo.com/aHOo4D/KJoEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2374
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-05 18:51:51
Subject:Re: [rest-discuss] Resources vs. Representations
Message:

On Thu, Sep 05, 2002 at 01:59:40PM -0400, Mathews, Walden wrote:
> Oh, I wanted to say one other thing on this subject.  There is
> this idea that if we PUT a resource through its URI, then we GET
> that resource back, we should get back the same value as we PUT.
> That statement implies that we have representation-level control,
> which we do not.  It would make more sense to think of it this
> way.  If we PUT a representation to a URI, then GET back a representation,
> the latter representation *means the same thing* as the former,
> though it may differ in format or even typographically.  THoughts?

Actually, PUT's a bit funny that way.  It's definined to really mean
"store" more than "set the state", so it is expected that bits are
preserved.  For this reason, SOAP can't use PUT (at least how you'd
expect it to be used).

At some point, I'm going to propose a "SET" method that can be used
in this way.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2375
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-05 19:41:44
Subject:Re: [rest-discuss] Resources vs. Representations
Message:

From: "Mark Baker" <distobj@...>
>
> Actually, PUT's a bit funny that way.  It's definined to really mean
> "store" more than "set the state", so it is expected that bits are
> preserved.  For this reason, SOAP can't use PUT (at least how you'd
> expect it to be used).
>
> At some point, I'm going to propose a "SET" method that can be used
> in this way.

POST could be used for such a thing, but it requires the pre-existance of a
request URI.  Instead of suggesting a SET method, how about either:

1) Relaxing POST to allow the creation of resources, or
2) Issue an "empty" PUT to create the resource, then follow with a non-empty
POST to set the resource.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2376
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-05 19:52:01
Subject:RE: [rest-discuss] Resources vs. Representations
Message:

Or, how about fixing RFC 2616 so that PUT makes sense for resources
that are powerfully conceptual, as opposed to resources that are 'just
documents'?

But I like "SET" just fine, too.

Walden

> -----Original Message-----
> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Thursday, September 05, 2002 3:42 PM
> To: rest-discuss
> Subject: Re: [rest-discuss] Resources vs. Representations
> 
> 
> From: "Mark Baker" <distobj@...>
> >
> > Actually, PUT's a bit funny that way.  It's definined to really mean
> > "store" more than "set the state", so it is expected that bits are
> > preserved.  For this reason, SOAP can't use PUT (at least how you'd
> > expect it to be used).
> >
> > At some point, I'm going to propose a "SET" method that can be used
> > in this way.
> 
> POST could be used for such a thing, but it requires the 
> pre-existance of a
> request URI.  Instead of suggesting a SET method, how about either:
> 
> 1) Relaxing POST to allow the creation of resources, or
> 2) Issue an "empty" PUT to create the resource, then follow 
> with a non-empty
> POST to set the resource.
> 
> ---
> Seairth Jacobs
> seairth@...
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2377
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-05 20:08:48
Subject:Re: [rest-discuss] Resources vs. Representations
Message:

How can the RFC dictate this in the first place?  Isn't the way that the
server chooses to handle/store the actual resource entirely transparent to
the protocol as long as subsequent retrieval is identical to what's posted?

Also, if you were to "relax" the rules of PUT, it seems to me that the only
difference at that point between PUT and POST is that one allows the client
to give the URI of a created resource while the other does not.  Or am I
misundersanding how you want PUT to be fixed?

---
Seairth Jacobs
seairth@...


----- Original Message -----
From: "Mathews, Walden" <waldenm@...>
To: "'Seairth Jacobs'" <seairth@...>; "rest-discuss"
<rest-discuss@yahoogroups.com>
Sent: Thursday, September 05, 2002 3:52 PM
Subject: RE: [rest-discuss] Resources vs. Representations


> Or, how about fixing RFC 2616 so that PUT makes sense for resources
> that are powerfully conceptual, as opposed to resources that are 'just
> documents'?
>
> But I like "SET" just fine, too.
>
> Walden
>
> > -----Original Message-----
> > From: Seairth Jacobs [mailto:seairth@...]
> > Sent: Thursday, September 05, 2002 3:42 PM
> > To: rest-discuss
> > Subject: Re: [rest-discuss] Resources vs. Representations
> >
> >
> > From: "Mark Baker" <distobj@...>
> > >
> > > Actually, PUT's a bit funny that way.  It's definined to really mean
> > > "store" more than "set the state", so it is expected that bits are
> > > preserved.  For this reason, SOAP can't use PUT (at least how you'd
> > > expect it to be used).
> > >
> > > At some point, I'm going to propose a "SET" method that can be used
> > > in this way.
> >
> > POST could be used for such a thing, but it requires the
> > pre-existance of a
> > request URI.  Instead of suggesting a SET method, how about either:
> >
> > 1) Relaxing POST to allow the creation of resources, or
> > 2) Issue an "empty" PUT to create the resource, then follow
> > with a non-empty
> > POST to set the resource.
> >
> > ---
> > Seairth Jacobs
> > seairth@...
> >
> >
> > ------------------------ Yahoo! Groups Sponsor
> > ---------------------~-->
> > 4 DVDs Free +s&p Join Now
> > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> > --------------------------------------------------------------
> > -------~->
> >
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:2378
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-05 20:15:13
Subject:RE: [rest-discuss] Resources vs. Representations
Message:

My understanding of PUT and POST (gleaned from interactions on this
mail list, by the way) is that

	PUT - is for overwriting an entire resource, for some value of
'overwrite'
	POST - is for appending to a resource, for some value of 'append'

Append means the representation you are forwarding represents something
subordinate to the named resource, as if the resource is a container, but
you can mess with that meaning a bit when resources are pure processors
with uninteresting state of their own.

Overwrite means a complete replacement of state, except in the case where
identity was missing in the first place, in which case it is just a
placement of state, not a replacement.

The RFC 'dictates' the semantics of the protocol and thereby defines the
protocol, but it doesn't force developers to follow the protocol.  You could
say that to the extent that you use GET to induce side effects as the main
dish, to the extent that you use PUT to accomplish non-idempotent work,
etc.,
etc., you are not doing HTTP.

Sometimes the work 'tunneling' is used as a synonym for 'not doing', while
being a bit more expressive of what's going on.

Walden

> -----Original Message-----
> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Thursday, September 05, 2002 4:09 PM
> To: rest-discuss
> Subject: Re: [rest-discuss] Resources vs. Representations
> 
> 
> How can the RFC dictate this in the first place?  Isn't the 
> way that the
> server chooses to handle/store the actual resource entirely 
> transparent to
> the protocol as long as subsequent retrieval is identical to 
> what's posted?
> 
> Also, if you were to "relax" the rules of PUT, it seems to me 
> that the only
> difference at that point between PUT and POST is that one 
> allows the client
> to give the URI of a created resource while the other does 
> not.  Or am I
> misundersanding how you want PUT to be fixed?
> 
> ---
> Seairth Jacobs
> seairth@...
> 
> 
> ----- Original Message -----
> From: "Mathews, Walden" <waldenm@...>
> To: "'Seairth Jacobs'" <seairth@...>; "rest-discuss"
> <rest-discuss@yahoogroups.com>
> Sent: Thursday, September 05, 2002 3:52 PM
> Subject: RE: [rest-discuss] Resources vs. Representations
> 
> 
> > Or, how about fixing RFC 2616 so that PUT makes sense for resources
> > that are powerfully conceptual, as opposed to resources 
> that are 'just
> > documents'?
> >
> > But I like "SET" just fine, too.
> >
> > Walden
> >
> > > -----Original Message-----
> > > From: Seairth Jacobs [mailto:seairth@...]
> > > Sent: Thursday, September 05, 2002 3:42 PM
> > > To: rest-discuss
> > > Subject: Re: [rest-discuss] Resources vs. Representations
> > >
> > >
> > > From: "Mark Baker" <distobj@...>
> > > >
> > > > Actually, PUT's a bit funny that way.  It's definined 
> to really mean
> > > > "store" more than "set the state", so it is expected 
> that bits are
> > > > preserved.  For this reason, SOAP can't use PUT (at 
> least how you'd
> > > > expect it to be used).
> > > >
> > > > At some point, I'm going to propose a "SET" method that 
> can be used
> > > > in this way.
> > >
> > > POST could be used for such a thing, but it requires the
> > > pre-existance of a
> > > request URI.  Instead of suggesting a SET method, how 
> about either:
> > >
> > > 1) Relaxing POST to allow the creation of resources, or
> > > 2) Issue an "empty" PUT to create the resource, then follow
> > > with a non-empty
> > > POST to set the resource.
> > >
> > > ---
> > > Seairth Jacobs
> > > seairth@...
> > >
> > >
> > > ------------------------ Yahoo! Groups Sponsor
> > > ---------------------~-->
> > > 4 DVDs Free +s&p Join Now
> > > http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> > > --------------------------------------------------------------
> > > -------~->
> > >
> > > To unsubscribe from this group, send an email to:
> > > rest-discuss-unsubscribe@yahoogroups.com
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
> > http://docs.yahoo.com/info/terms/
> >
> >
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2379
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-05 20:35:41
Subject:Re: Resources vs. Representations (was Re: Other view of DELETE?)
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

>
> So, based on what you are saying, if I were to add a querystring to the
URI
> such that the returned data was potentially different, each valid
variation
> of the querystring points to separate resource?
Yes. Resources are /very/ flexible (possibly not innumerable, but infinite
enough for me).

> Using the URI->Representation POV, the querystring would returns different
> representations of the same resource.
The response header of Content-Type (and other headers maybe...) indicates
that it is a different representation.







-----------------------------------------------------------------------------------
Post ID:2380
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-05 20:19:05
Subject:Re: [rest-discuss] Other view of DELETE? (was Re: GET: Shades of Grey)
Message:

----- Original Message -----
From: "firepipe_au" <michael@...>

>
> I've never seen it done before, but imagine POSTing, PUTting or
> DELETE-ing to a fragment URI...
You can't.
The definition of URI with fragment identifiers is such that interactions
with the resource do not include the fragment portion (the stuff after '#').
So you can only interact with the 'base resource' via HTTP - a client can do
anything with portions of the representation retrieved, but can only talk
back to the full resource. Since the fragment identifier is used by the
client, it is dependent on the particular representation returned by the
server.






-----------------------------------------------------------------------------------
Post ID:2381
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-05 20:22:33
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

----- Original Message -----
From: "Bill de h�ra" <dehora@...>

> I like the idea of stateless servers and client sided session management,
> but you'd need to throw out a lot of sites and browsers to see that
realized.
Throwing out the browser as a foundation (or even a good example) for the
'automatable Web' isn't such a bad thing...






-----------------------------------------------------------------------------------
Post ID:2382
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-05 20:39:39
Subject:Re: [rest-discuss] Resources vs. Representations (was Re: Other view of DELETE?)
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

> I don't see where anything gets complex here.  All that one can ever
> retrieve is a representation of a resource.  If you have two (or two
> hundred) URIs, each returns a representation of a resource.  If you take
my
> PurchaseOrder URI1 and URI2 examples, URI2 is not a representation of a
> representation of the resource pointed to by URI1.  URI2 returns a
> representation of a resource.  URI1 returns a representation of a
resource.
> Sure, they may both be pointing to the same resource, but that doesn't
mean
> that URI2 is subordinate to URI1.
They cannot be pointing to the same resource, they have different URIs. They
might be pointing to the same data behind the scenes, but externally, that
is not visible. A resource is what is visible externally. The same PO data
(the bits) might have multiple resources exposed.
Personally, I wouldn't expose multiple resources in order to provide
different content types - I'd use Accept: and Content-Type: for that. I
might use different resources to expose different portions of a purchase
order - or perhaps different portions of the history of actions related to a
'purchase'.






-----------------------------------------------------------------------------------
Post ID:2383
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-05 20:42:23
Subject:Re: [rest-discuss] Resources vs. Representations
Message:

----- Original Message -----
From: "Mathews, Walden" <waldenm@...>


> Oh, I wanted to say one other thing on this subject.  There is
> this idea that if we PUT a resource through its URI, then we GET
> that resource back, we should get back the same value as we PUT.
> That statement implies that we have representation-level control,
> which we do not.  It would make more sense to think of it this
> way.  If we PUT a representation to a URI, then GET back a representation,
> the latter representation *means the same thing* as the former,
> though it may differ in format or even typographically.  THoughts?
>
I think this is the only way to think about it when considering content
negotiation (or at least potentially different content-types for a
representation).






-----------------------------------------------------------------------------------
Post ID:2384
Sender:"Yannick Loiseau" <yloiseau@...>
Post Date/Time:2002-09-05 20:48:25
Subject:Re: [rest-discuss] Resources vs. Representations (was Re: Other view of DELETE?)
Message:

so it's just a matter of replacing resources by data and representations by
resources  in Seairth  mail to agree ?


----- Original Message -----
From: "S. Mike Dierken" <mdierken@...>
To: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Thursday, September 05, 2002 10:39 PM
Subject: Re: [rest-discuss] Resources vs. Representations (was Re: Other
view of DELETE?)


>
> ----- Original Message -----
> From: "Seairth Jacobs" <seairth@...>
>
> > I don't see where anything gets complex here.  All that one can ever
> > retrieve is a representation of a resource.  If you have two (or two
> > hundred) URIs, each returns a representation of a resource.  If you take
> my
> > PurchaseOrder URI1 and URI2 examples, URI2 is not a representation of a
> > representation of the resource pointed to by URI1.  URI2 returns a
> > representation of a resource.  URI1 returns a representation of a
> resource.
> > Sure, they may both be pointing to the same resource, but that doesn't
> mean
> > that URI2 is subordinate to URI1.
> They cannot be pointing to the same resource, they have different URIs.
They
> might be pointing to the same data behind the scenes, but externally, that
> is not visible. A resource is what is visible externally. The same PO data
> (the bits) might have multiple resources exposed.
> Personally, I wouldn't expose multiple resources in order to provide
> different content types - I'd use Accept: and Content-Type: for that. I
> might use different resources to expose different portions of a purchase
> order - or perhaps different portions of the history of actions related to
a
> 'purchase'.
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>







-----------------------------------------------------------------------------------
Post ID:2385
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-05 20:52:43
Subject:RE: [rest-discuss] Resources vs. Representations (was Re: Other v iew of DELETE?)
Message:

> They cannot be pointing to the same resource, they have 
> different URIs. 

Are you implying that a single resource can't have two or more
identifiers?  I would think it can, and that should be no problem.
What do I miss?

Walden







-----------------------------------------------------------------------------------
Post ID:2386
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-09-05 21:04:09
Subject:RE: [rest-discuss] Resources vs. Representations (was Re: Other view of DELETE?)
Message:

> From: S. Mike Dierken [mailto:mdierken@...] 
>
> They cannot be pointing to the same resource, they have 
> different URIs. 
 
Where is it specified that a resource can only ever have one URI?

Bill de hra 
--
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:2387
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-09-05 21:18:44
Subject:Re: [rest-discuss] Resources vs. Representations (was Re: Other view of DELETE?)
Message:

On Thursday, Sep 5, 2002, at 22:04 Europe/Dublin, Bill de hra wrote:
>> From: S. Mike Dierken [mailto:mdierken@...]
>>
>> They cannot be pointing to the same resource, they have
>> different URIs.
>
> Where is it specified that a resource can only ever have one URI?

i haven't seen that specified anywhere.

however, i also haven't seen it specified anywhere in the semantic web 
propoganda (in the positive sense of the word) that i've seen, how you 
assert that two URI are equivalent, or identify the same resource.

so if you and i use distinct URIs (sp?) to refer to "the Ford Escort 
Mark II" (with apologies to non-europeans), nobody can assert that they 
in fact identify the same thing.

this troubles me.  sometimes i struggle to see how the semantic web can 
work without it.

to drag this back on topic, i see REST as a necessary prerequisite for 
a successful semantic web.






-----------------------------------------------------------------------------------
Post ID:2388
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-05 21:30:35
Subject:RE: [rest-discuss] Resources vs. Representations (was Re: Other v iew of DELETE?)
Message:

I would think that the naming authority could assert that two
URIs reference the same resource, and might do that with a third
resource which is an equivalence relation.

Walden

> -----Original Message-----
> From: Vincent D Murphy [mailto:vdm@...]
> Sent: Thursday, September 05, 2002 5:19 PM
> To: Bill de hra
> Cc: 'S. Mike Dierken'; 'rest-discuss'
> Subject: Re: [rest-discuss] Resources vs. Representations 
> (was Re: Other
> view of DELETE?)
> 
> 
> On Thursday, Sep 5, 2002, at 22:04 Europe/Dublin, Bill de hra wrote:
> >> From: S. Mike Dierken [mailto:mdierken@...]
> >>
> >> They cannot be pointing to the same resource, they have
> >> different URIs.
> >
> > Where is it specified that a resource can only ever have one URI?
> 
> i haven't seen that specified anywhere.
> 
> however, i also haven't seen it specified anywhere in the 
> semantic web 
> propoganda (in the positive sense of the word) that i've 
> seen, how you 
> assert that two URI are equivalent, or identify the same resource.
> 
> so if you and i use distinct URIs (sp?) to refer to "the Ford Escort 
> Mark II" (with apologies to non-europeans), nobody can assert 
> that they 
> in fact identify the same thing.
> 
> this troubles me.  sometimes i struggle to see how the 
> semantic web can 
> work without it.
> 
> to drag this back on topic, i see REST as a necessary 
> prerequisite for 
> a successful semantic web.
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2389
Sender:Jan Algermissen <algermissen@...>
Post Date/Time:2002-09-05 22:02:20
Subject:Re: [rest-discuss] Resources vs. Representations (was Re: Other view of DELETE?)
Message:

Hello RESTlers--

I am a REST newbie but coming from the topic map world I think
I can contribute something here:

Vincent D Murphy wrote:

> however, i also haven't seen it specified anywhere in the semantic web
> propoganda (in the positive sense of the word) that i've seen, how you
> assert that two URI are equivalent, or identify the same resource.

I think that there are two issues here:

1. How do you specify that two URIs identify the same resource (=are addressing
   the same resource)

I think that NewsML provides a way with the <Resource> element:

<Resource>
  <Urn>urn:newsml:iptc.org:20001006:topicset.iptc-howpresent:1</Urn>
  <Url>file://./topicsets/iptc-howpresent.xml</Url>
</Resource>


2. How do you specify that two URIs indicate the same subject ?
 
> so if you and i use distinct URIs (sp?) to refer to "the Ford Escort
> Mark II" (with apologies to non-europeans), nobody can assert that they
> in fact identify the same thing.

Besides the actual purpose of URIs (addressing and identifying resources) they
can be used to identify abstract things simply because they are unique
identifiers. In topic maps land such URIs are called 'subject indicators'.
(For example see http://www.topicmaps.org/xtm/1.0/language.xtm for a topic map that
defines subject indicators for ISO language codes)

One of the primary goals of topic maps is to solve the problem you mention
above: how can one assert that two subject indicators (URIs) identify the 
same thing (=subject).

This can be done by the follwing markup for example:

<topicMap>
<topic id="foo">
  <subjectIdentity>
    <subjectIndicatorRef
      xlink:href="http://www.foo.bar/ford-escort-mark-2" />
    <subjectIndicatorRef
      xlink:href="http://www.ford.com/models/escort/mark-2" />
  <subjectIdentity>
</topic>
</topicMap>

An topic map application will 'know' from this markup that the two URIs refer to
the same subject and will recognize both of them equally well as an identifier
for that subject.


> this troubles me.  sometimes i struggle to see how the semantic web can
> work without it.

So, no trouble here (if I understood you correctly).


> to drag this back on topic, i see REST as a necessary prerequisite for
> a successful semantic web.

Yes, and I am currently learning a lot from this list. Thanks.

Jan





-- 
Jan Algermissen
Consultant & Programmer

Tel:   ++49 (0)40 89 700 511
       ++49 (0)177 283 1440
Fax:   ++49 (0)40 89 700 841 
Email: algermissen@...
Web:   http://www.topicmapping.com






-----------------------------------------------------------------------------------
Post ID:2390
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-09-05 22:09:55
Subject:Re: [rest-discuss] Resources vs. Representations (was Re: Other v iew of DELETE?)
Message:

On Thursday, Sep 5, 2002, at 22:30 Europe/Dublin, Mathews, Walden wrote:
> I would think that the naming authority could assert that two
> URIs reference the same resource, and might do that with a third
> resource which is an equivalence relation.

granted..

but shouldn't the equivalence relation be standard, and endorsed by the 
W3C or whoever, rather than something each naming authority must 
(re)invent?  (that was sort of the whole point, though i doubt i made 
that clear enough.)







-----------------------------------------------------------------------------------
Post ID:2391
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-09-05 22:21:14
Subject:RE: [rest-discuss] Resources vs. Representations (was Re: Other view of DELETE?)
Message:

> From: Vincent D Murphy [mailto:vdm@...] 
>
> however, i also haven't seen it specified anywhere in the 
> semantic web 
> propoganda (in the positive sense of the word) that i've 
> seen, how you 
> assert that two URI are equivalent, or identify the same resource.

But you will see it specified that a URI can only ever denote one
resource. There isn't a way in RDF to say two resources denote the same
thing (DAML maybe). It's been a while since I looked at the Model
Theory, so I could be wrong there... What you could do with it is merge
graphs and from there determine if two URIs are likely as not pointing
at the same thing, possibly by swapping one URI for another in a graph
and seeing if the entailments remain the same or just counting up how
many property values the things have in common. 

> this troubles me.  sometimes i struggle to see how the 
> semantic web can work without it.

Think of how tricky the semantics of object equality can get in Java.
I'd be disinclined to bake in resource equality at the RDF level.

Bill de hra 
--
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:2392
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-05 22:57:12
Subject:Re: [rest-discuss] Resources vs. Representations (was Re: Other view of DELETE?)
Message:

----- Original Message ----- 
From: "Mathews, Walden" <waldenm@...>


> > They cannot be pointing to the same resource, they have 
> > different URIs. 
> 
> Are you implying that a single resource can't have two or more
> identifiers?  I would think it can, and that should be no problem.
> What do I miss?
Hmm. Maybe you are right. I just haven't been thinking about it that way.






-----------------------------------------------------------------------------------
Post ID:2393
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-06 02:38:01
Subject:Resources - when two are one
Message:

So if two identifiers identify the same resource, what assertions can we
make?

Assuming uri1 and uri2 are the same resource...
And assuming the same accept headers, no caching, etc.

1 equivalent representations
content1 = server.resource(uri1);    // via GET
content2 = server.resource(uri2);    // via GET

// are these true?
assert(content1.type == content2.type);
assert(content1.length == content2.length);
assert(content1.body == content2.body);

2 equivalent state
content1.body = "hello world";
content1.type = "text/plain";
server.resource(uri1) = content1;    // via PUT

content2.body = "<hello>world</hello>";
content2.type = "text/xml";
server.resource(uri2) = content2;    // via PUT

// are these true?
assert(server.resource(uri1).body == content2.body);
assert(server.resource(uri1).body != content1.body);
assert(server.resource(uri2).body == content2.body);

3 others?








-----------------------------------------------------------------------------------
Post ID:2394
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-06 02:51:25
Subject:Re: [rest-discuss] Resources - when two are one
Message:

From: "S. Mike Dierken" <mdierken@...>
>
> So if two identifiers identify the same resource, what assertions can we
> make?
>
> Assuming uri1 and uri2 are the same resource...
> And assuming the same accept headers, no caching, etc.
>
> 1 equivalent representations
> content1 = server.resource(uri1);    // via GET
> content2 = server.resource(uri2);    // via GET
>
> // are these true?
> assert(content1.type == content2.type);
> assert(content1.length == content2.length);
> assert(content1.body == content2.body);

Not necessarily.  For instance, you may have an online document which show
in English for uri1 and French for uri2.  Same resource, different
representations.

> 2 equivalent state
> content1.body = "hello world";
> content1.type = "text/plain";
> server.resource(uri1) = content1;    // via PUT
>
> content2.body = "<hello>world</hello>";
> content2.type = "text/xml";
> server.resource(uri2) = content2;    // via PUT
>
> // are these true?
> assert(server.resource(uri1).body == content2.body);
> assert(server.resource(uri1).body != content1.body);
> assert(server.resource(uri2).body == content2.body);

I am unclear about what you are asking here.  But I'll take a stab and say
that only the third assertion is true.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2395
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-09-06 03:12:25
Subject:Re: [rest-discuss] Resources vs. Representations (was Re: Other v iew of DELETE?)
Message:

> > I would think that the naming authority could assert that two
> > URIs reference the same resource, and might do that with a third
> > resource which is an equivalence relation.
> 
> granted..
> 
> but shouldn't the equivalence relation be standard, and endorsed by the 
> W3C or whoever, rather than something each naming authority must 
> (re)invent?  (that was sort of the whole point, though i doubt i made 
> that clear enough.)

The syntax for expressing equivalence relations should be standard (we in
the topic maps community have our views on what the standard should be ;-)
but anyone the on web should be free to use the syntax. Of course, some
expressions of equivalence will be more authoritative than others --
naming autorities, for example.

Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.goose-works.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2396
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-06 03:20:51
Subject:Re: [rest-discuss] REST + web services composition
Message:

On Sun, Sep 01, 2002 at 10:17:41PM -0000, qchong wrote:
> Hello, 
> I would like to know if anyone has considered how multiple web 
> services could be composed and coordinated together under the REST 
> architecture.  Specifically:
> 
> 1. What form would the representation of service composition take?

A pipeline.

> 2. How to handle dynamic binding of multiple services within a 
> session, given that REST is a stateless and asynchronous model?

Why is a session required?

> 3. How to automate service discovery, invocation (possibly using 
> ontology-aware agents?), and execution completion notification, with 
> provision for graceful recovery from a failed composite service 
> execution?

Whoa, slow down there.  "service discovery" is what you do when you
find a URI in some manner.  "invocation" is just the passage of a
message (GET, POST, whatever) through a set of intermediaries in
some order.  "execution completion notification" seems to be
suggesting that a "session" exists.  No such beast is required.
The message is entirely self-describing.

> In a simple composition model, a client (or possibly a coordinator 
> service) would be responsible for obtaining URLs of the service 
> providers, invoking them in some order, and converting responses from 
> one provider into a parameter that would go into the request message 
> to the other providers.

Right, hence the use of data-flow style composition in REST, which is
much much simpler because all components have a uniform interface.
This is much more amenable to decentralization too.  I know because
our platform supports fully decentralized routing as well as hub-and-
spoke if so desired.

>  Some way of specifiying  how to tranform 
> between representations would be necessary.  Also, this means that 
> the client (or coordinator) would be responsible for monitoring the 
> state of the service composition process.   

Sessions = bad.

> What are the kinds of compositions that would work best under REST? 

Message pipelining is an obvious one.  I think there are others.
KnowNow found one with the symmetry between GET responses and POST
requests.  It's still a pipeline, but it's different than with
intermediaries since it's not a message pipeline, but a message *body*
pipeline.  I'm still trying to figure out the difference.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2397
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-06 03:54:36
Subject:Re: [rest-discuss] Resources - when two are one
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

>
> Not necessarily.  For instance, you may have an online document which show
> in English for uri1 and French for uri2.  Same resource, different
> representations.
I was thinking that the Accept, Accept-Language, etc. request headers would
be used to distinguish certain representations against the same URI.


> > // are these true?
> > assert(server.resource(uri1).body == content2.body);
> > assert(server.resource(uri1).body != content1.body);
> > assert(server.resource(uri2).body == content2.body);
>
> I am unclear about what you are asking here.  But I'll take a stab and say
> that only the third assertion is true.
If I write to URI1, do I see those changes at URI2.

If interacting (updating, etc.) with URI1 /never/ appears to change URI2 -
if no change is ever visible at the other URI - then why say they are the
'same' resource?








-----------------------------------------------------------------------------------
Post ID:2398
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-06 04:53:31
Subject:Re: [rest-discuss] Idempotent sequences
Message:

Mathews, Walden wrote,
> I suspect that any disagreement about the idempotence of a string
> of idempotent HTTP operations has more to do with the way you
> might map HTTP operations onto the meaning of 'idempotent' than
> with the particular proof you offered.  We touched on this before.
> What is the 'function' of an HTTP PUT?  I.e., which mapping are
> we interested in?  Clearly, sometimes it's resource before-and-after
> state.  At other times it may be more like request-to-response
> mapping?

Yes, I think that's right.

The problem here is that these two views clearly aren't equivalent, and 
are typically in conflict. REST, as I understand it, looks to have a 
more natural fit with the resource before-and-after state view. So does 
that mean that REST is in conflict with part of RFC 2616? If it is in 
conflict, is that a problem for REST, or is it the inevitable 
consequence of an inconsistency in RFC 2616?

FWIW, the interpretation of idempotent sequences of requests isn't 
merely a niggling theoretical puzzle: it has direct implications for 
the implementation of HTTP/1.1 request piplining on the client side. 
Having built non-caching HTTP/1.1 proxies which support piplining 
across from downstream clients to upstream origin servers, I can vouch 
for the fact that the tensions in section 9.1 are a real headache with 
uncomfortable implications for interoperability.

Mark (B and N), you've done work in a similar area, so you must have run 
into the same issue: how did you resolve it?

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2399
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-06 05:19:40
Subject:Re: [rest-discuss] Resources - when two are one
Message:

S. Mike Dierken wrote,
> > Not necessarily.  For instance, you may have an online document
> > which show in English for uri1 and French for uri2.  Same resource,
> > different representations.
>
> I was thinking that the Accept, Accept-Language, etc. request headers
> would be used to distinguish certain representations against the same
> URI.

Even in this case the response entity is allowed to vary. GET must not 
mutate the server/resource state, but it doesn't follow that a constant 
response entity must be returned.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2400
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-09-06 08:10:51
Subject:RE: [rest-discuss] Resources - when two are one
Message:



> From: S. Mike Dierken [mailto:mdierken@...] 
>
> If interacting (updating, etc.) with URI1 /never/ appears to 
> change URI2 - if no change is ever visible at the other URI - 
> then why say they are the 'same' resource?

Because you want to use URIs as resource identifiers outside the HTTP
context. That is, these things have value outside hypertext retrieval
and document oriented worldviews. For example in RDF, who cares whether
writing to URI1 affects URI2? If they both represent Planck's constant,
of what possible interest is a write operation? What we can care about
is the relationship between the two in an RDF graph. If that
relationship happens to be resource-identical, then we can do
interesting things in terms of merging data.

Bill de hra 
--
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:2401
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-06 13:20:36
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

> Throwing out the browser as a foundation (or even a good example) for the
> 'automatable Web' isn't such a bad thing...

Browsers should obviously play nice with any part of the web; but 
still, I can't think of a machine-to-machine example where a session 
time-out would be necessary.

Nevertheless, Mark's point about proxy caches being able to refresh 
renders moot the issue I was trying to work through.  If they are
allowed to refresh when they see fit, that would demand a pretty strict 
interpretation of safety.

All that being said, I still think the Google interface should be 
GET-able even without a strictly idempotent GET.  Their choice of 
1000 hits is right on the hairy edge of where it would even matter to a 
casual developer (the audience they seem to be targeting right now).
For this audience it is effectively idempotent.  Had they chosen 
something like a million hits the limit would probably never get hit
by anyone, and requiring a POST would be overly strict.

Not being able to do some of the XSLT stuff I've been doing with Xoomle
and Amazon makes the current Google API less than useful. :[

Thanks all,

- Jeff








-----------------------------------------------------------------------------------
Post ID:2402
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-09-06 13:56:18
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

On Thursday, Sep 5, 2002, at 21:22 Europe/Dublin, S. Mike Dierken wrote:
> ----- Original Message -----
> From: "Bill de hra" <dehora@...>
>
>> I like the idea of stateless servers and client sided session 
>> management,
>> but you'd need to throw out a lot of sites and browsers to see that
> realized.
> Throwing out the browser as a foundation (or even a good example) for 
> the
> 'automatable Web' isn't such a bad thing...

agreed.  because of the crippled contemporary browsers, i see REST as 
being most useful for developing client/server applications where i can 
control what client is used.  it's like a mainframe architecture for 
the nineties (zeroes?).  that way i don't have to deal with html forms 
and other legacy baggage either.  i am experimenting in this regard 
using perl and poe (poe.perl.org) as a RESTful HTTP server and macos x 
cocoa apps as clients.

the other nice thing is that i can support contemporary browsers, just 
in the read-only way they support.  and perhaps supporting HTML forms 
via POST where it makes sense.  but the custom clients are most 
powerful because i can have them GET/PUT/DELETE and render/edit XML 
representations.

i think that to a large extent many of the current browsers lock their 
users into a read-only view of the web.  i doubt that IE/netscape were 
ever architected to allow users to edit representations.  aolpress is 
the last app i saw that did it well.  amaya does too but the UI is 
woeful IMHO.

mozilla's editor is a seperate app called composer.  why not just have 
a cursor in the displayed representation (perhaps as part of an edit 
'mode'), and a PUT button on the toolbar?  i see the seperate app as a 
false dichotomy from a REST point-of-view.

i was wondering whether mozilla (the navigator part) could be made to 
PUT representations (probably easy enough with some javascript/xul), 
and whether it would be possible to make representations editable 
(harder, but possible because mozilla composer exists), but i shelved 
the idea for a while.  i'm waiting for o'reilly's mozilla applications 
book because right now i find it too difficult to figure out how things 
work.

http://www.oreilly.com/catalog/mozilla/

i am trying to teach myself cocoa development on macos x by writing a 
RESTful browser.  this hasn't advanced much beyond the 'idea' stage and 
i've just been building interfaces in Interface Builder so far.

it has a box for a URL, GET, PUT, DELETE buttons, and a pane for a 
fully editable view of the representation.  and very little else.

i'll tell you all if/when it ever works.






-----------------------------------------------------------------------------------
Post ID:2403
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-06 14:01:08
Subject:RE: [rest-discuss] Resources vs. Representations (was Re: Other v iew of DELETE?)
Message:

Do you mean that the form of representation of URI->URI equivalence
should be standardized by the W3C?  That seems to make sense, but
I didn't think that was the thrust of the original question.  I thought
the original questions was more to the authority of the assertion
than to its format.

Walden

> -----Original Message-----
> From: Vincent D Murphy [mailto:vdm@...]
> Sent: Thursday, September 05, 2002 6:10 PM
> To: Mathews, Walden
> Cc: 'rest-discuss'
> Subject: Re: [rest-discuss] Resources vs. Representations 
> (was Re: Other
> v iew of DELETE?)
> 
> 
> On Thursday, Sep 5, 2002, at 22:30 Europe/Dublin, Mathews, 
> Walden wrote:
> > I would think that the naming authority could assert that two
> > URIs reference the same resource, and might do that with a third
> > resource which is an equivalence relation.
> 
> granted..
> 
> but shouldn't the equivalence relation be standard, and 
> endorsed by the 
> W3C or whoever, rather than something each naming authority must 
> (re)invent?  (that was sort of the whole point, though i doubt i made 
> that clear enough.)
> 






-----------------------------------------------------------------------------------
Post ID:2404
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-06 14:06:50
Subject:RE: [rest-discuss] Resources vs. Representations (was Re: Other v iew of DELETE?)
Message:

My exposure to RDF & DAML is minimal.  But it seems that all it
would take to assert that two URI refer to the same resource is
a 'deference' property and a logical 'equivalence'.  Neither
seems like hard baking to me, i.e., they are both rather
universally applicable.

Walden

> -----Original Message-----
> From: Bill de hra [mailto:dehora@...]
> Sent: Thursday, September 05, 2002 6:21 PM
> To: 'Vincent D Murphy'
> Cc: 'S. Mike Dierken'; 'rest-discuss'
> Subject: RE: [rest-discuss] Resources vs. Representations 
> (was Re: Other
> view of DELETE?)
> 
> 
> 
> > From: Vincent D Murphy [mailto:vdm@...] 
> >
> > however, i also haven't seen it specified anywhere in the 
> > semantic web 
> > propoganda (in the positive sense of the word) that i've 
> > seen, how you 
> > assert that two URI are equivalent, or identify the same resource.
> 
> But you will see it specified that a URI can only ever denote one
> resource. There isn't a way in RDF to say two resources 
> denote the same
> thing (DAML maybe). It's been a while since I looked at the Model
> Theory, so I could be wrong there... What you could do with 
> it is merge
> graphs and from there determine if two URIs are likely as not pointing
> at the same thing, possibly by swapping one URI for another in a graph
> and seeing if the entailments remain the same or just counting up how
> many property values the things have in common. 
> 
> > this troubles me.  sometimes i struggle to see how the 
> > semantic web can work without it.
> 
> Think of how tricky the semantics of object equality can get in Java.
> I'd be disinclined to bake in resource equality at the RDF level.
> 
> Bill de hra 
> --
> Propylon
> www.propylon.com 
> 
>  
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Looking for a more powerful website? Try GeoCities for $8.95 
> per month.
> Register your domain name (http://your-name.com). More 
> storage! No ads!
> http://geocities.yahoo.com/ps/info
> http://us.click.yahoo.com/aHOo4D/KJoEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2405
Sender:<paul@...>
Post Date/Time:2002-09-06 14:14:24
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

On Fri, 6 Sep 2002, Jeffrey Winter wrote:

>
> All that being said, I still think the Google interface should be
> GET-able even without a strictly idempotent GET.  Their choice of
> 1000 hits is right on the hairy edge of where it would even matter to a
> casual developer (the audience they seem to be targeting right now).
> For this audience it is effectively idempotent.  Had they chosen
> something like a million hits the limit would probably never get hit
> by anyone, and requiring a POST would be overly strict.

I've made roughly the same argument here:

 http://www.blogstream.com/pauls/1031155140

> Not being able to do some of the XSLT stuff I've been doing with Xoomle
> and Amazon makes the current Google API less than useful. :[

I agree. It *is* useful to you because it is *effectively* idempotent.
Because you probably don't do anywhere near 1000 hits per day. If you
needed to do somewhere between 500-1500 hits per day, you would probably
offer Google money for a service that would allow you to get back to
"effective idempotence." After all, a service that regularly craps out on
you sometime in the afternoon is hardly something you can trust and build
important applications on.

 Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2406
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-06 14:53:03
Subject:RE: [rest-discuss] Idempotent sequences
Message:


> -----Original Message-----
> From: Miles Sabin [mailto:miles@...]
> Sent: Friday, September 06, 2002 12:54 AM
> To: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Idempotent sequences
> 
> The problem here is that these two views clearly aren't 
> equivalent, and 
> are typically in conflict. REST, as I understand it, looks to have a 
> more natural fit with the resource before-and-after state 
> view. So does 
> that mean that REST is in conflict with part of RFC 2616? If it is in 
> conflict, is that a problem for REST, or is it the inevitable 
> consequence of an inconsistency in RFC 2616?

Sorry, which part of 2616 do you think is in conflict with REST
over the issue of idempotence?

Walden






-----------------------------------------------------------------------------------
Post ID:2407
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-09-06 14:54:58
Subject:RE: [rest-discuss] Resources vs. Representations (was Re: Other view of DELETE?)
Message:


> From: Mathews, Walden [mailto:waldenm@...] 
>
> My exposure to RDF & DAML is minimal.  But it seems that all 
> it would take to assert that two URI refer to the same 
> resource is a 'deference' property and a logical 
> 'equivalence'.  Neither seems like hard baking to me, i.e., 
> they are both rather universally applicable.

If you mean equivalence of representations, I don't think that would
work very well.


Bill de hra 
--
Propylon
www.propylon.com 

 







-----------------------------------------------------------------------------------
Post ID:2408
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-06 15:07:36
Subject:RE: [rest-discuss] Resources - when two are one
Message:

I'll take a stab ...

> -----Original Message-----
> From: S. Mike Dierken [mailto:mdierken@...]
> Sent: Thursday, September 05, 2002 10:38 PM
> To: rest-discuss
> Subject: [rest-discuss] Resources - when two are one
> 
> 
> So if two identifiers identify the same resource, what 
> assertions can we
> make?
> 
> Assuming uri1 and uri2 are the same resource...
> And assuming the same accept headers, no caching, etc.
> 
> 1 equivalent representations
> content1 = server.resource(uri1);    // via GET
> content2 = server.resource(uri2);    // via GET
> 
> // are these true?
> assert(content1.type == content2.type);
> assert(content1.length == content2.length);
> assert(content1.body == content2.body);

No to all, not even if the two GETs both happen 'at the
same time t'.  Practically speaking, I intuit that there
should be high consistency, but I don't know how to
formalize that expectation.

> 
> 2 equivalent state
> content1.body = "hello world";
> content1.type = "text/plain";
> server.resource(uri1) = content1;    // via PUT
> 
> content2.body = "<hello>world</hello>";
> content2.type = "text/xml";
> server.resource(uri2) = content2;    // via PUT
> 
> // are these true?
> assert(server.resource(uri1).body == content2.body);

According to that weird 'PUT' rule, it would have to be :-(

> assert(server.resource(uri1).body != content1.body);

Ditto :-(

> assert(server.resource(uri2).body == content2.body);

Stop, you're making me suicidal :-(

Try running this simulation with MarkB's 'SET' in place of
'PUT' and watch some different answers come pouring out. :-)

Walden






-----------------------------------------------------------------------------------
Post ID:2409
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-06 15:13:59
Subject:RE: [rest-discuss] Resources vs. Representations (was Re: Other v iew of DELETE?)
Message:


> -----Original Message-----
> From: Bill de hra [mailto:dehora@eircom.net]
> Sent: Friday, September 06, 2002 10:55 AM
> To: Mathews, Walden; 'Vincent D Murphy'
> Cc: 'S. Mike Dierken'; 'rest-discuss'
> Subject: RE: [rest-discuss] Resources vs. Representations 
> (was Re: Other
> view of DELETE?)
> 
> 
> 
> 
> > From: Mathews, Walden [mailto:waldenm@...] 
> >
> > My exposure to RDF & DAML is minimal.  But it seems that all 
> > it would take to assert that two URI refer to the same 
> > resource is a 'deference' property and a logical 
> > 'equivalence'.  Neither seems like hard baking to me, i.e., 
> > they are both rather universally applicable.
> 
> If you mean equivalence of representations, I don't think that would
> work very well.

Agreed.  I mean that two URIs are 'equivalent' => they both reference
the same resource.  I.e., when I say 'deference' above, I mean the
traversal from URI to its resource, not from resource to representation,
and certainly not all the way from URI to representation.

Walden






-----------------------------------------------------------------------------------
Post ID:2410
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-06 15:41:28
Subject:what is state?
Message:

Dear Abby,

In all of these conversations, we keep speaking of resource state.  However,
I am losing all understanding of what resource state actually is...


A resource has a state. One can only retrieve a representation of the
current state of a resource.

But then we are told that we can receive different representations of the
same state.  For instance, the same resource could be returned in different
spoken languages or in different content-types.  However, these are both
indicated by HTTP headers and not within the returned entity itself.
However, it you look at the infamous "hit counter", the returned entity
could differ between calls.  But it seems to me that people are saying that
the state hasn't necessarily changed.

If this is true, then it seems to me that the concept of "state" is more of
a logical (?) concept than a physical (?) concept.  In other words, state is
subjective.  One person may say that the state of a resource means one thing
while another person would say that the state of another resource means
something entirely different.  Is this true?  And if so, what is the value
of talking about state when discussing REST?  Isn't this just adding one
more jargon word for us to all trip over?

Signed,
In A State of Confussion

(aka:
---
Seairth Jacobs
seairth@...
)







-----------------------------------------------------------------------------------
Post ID:2411
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-06 16:49:04
Subject:Re: [rest-discuss] Resources vs. Representations (was Re: Other v iew of DELETE?)
Message:

FWIW, both HTTP 301 and daml:equivalentTo should be considered
authoritative with respect to asserting resource equivalence.
I also believe that they are equivalent, ala;

GET(uri1) = 301(uri2) <=> uri1 daml:equivalentTo uri2

but I could be wrong about that, not being a DAML guru.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2412
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-06 17:08:32
Subject:RE: [rest-discuss] Resources vs. Representations (was Re: Other v iew of DELETE?)
Message:

My reservations about 301 indicating equivalence comes from the
asymmetry of 301, but otherwise I see where you're coming from.

As for authoritative, I assume your DAML example was offered
by the naming authority, that latter fact making it authoritative,
not the fact that it's DAML (or damn anything, for that matter).
:-)

Walden

> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Friday, September 06, 2002 12:49 PM
> To: Mathews, Walden
> Cc: 'Bill de hra'; 'Vincent D Murphy'; 'S. Mike Dierken';
> 'rest-discuss'
> Subject: Re: [rest-discuss] Resources vs. Representations 
> (was Re: Other
> v iew of DELETE?)
> 
> 
> FWIW, both HTTP 301 and daml:equivalentTo should be considered
> authoritative with respect to asserting resource equivalence.
> I also believe that they are equivalent, ala;
> 
> GET(uri1) = 301(uri2) <=> uri1 daml:equivalentTo uri2
> 
> but I could be wrong about that, not being a DAML guru.
> 
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
> 






-----------------------------------------------------------------------------------
Post ID:2413
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-06 17:20:00
Subject:Re: [rest-discuss] Resources vs. Representations (was Re: Other v iew of DELETE?)
Message:

On Fri, Sep 06, 2002 at 01:08:32PM -0400, Mathews, Walden wrote:
> My reservations about 301 indicating equivalence comes from the
> asymmetry of 301, but otherwise I see where you're coming from.

Hmm, what asymmetry?

> As for authoritative, I assume your DAML example was offered
> by the naming authority, that latter fact making it authoritative,
> not the fact that it's DAML (or damn anything, for that matter).
> :-)

Heh, yep. 8-)

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2414
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-06 17:26:49
Subject:URI Equivalence (was Re: Resources vs. Representations)
Message:

From: "Mathews, Walden" <waldenm@...>
>
> My reservations about 301 indicating equivalence comes from the
> asymmetry of 301, but otherwise I see where you're coming from.

How about if we defined a new content-type (e.g. "text/uri-equivalent") such
that we could make a GET request to any URI where the content-type was
passed in the Accept: header?  In return, assuming that the server
recognized the content-type, it would return a CR/LF delimited list of all
equivalent URIs that it knows about.  The client can then use the list to
determine equivalence itself by testing the second URI against the returned
list.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2415
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-06 17:31:53
Subject:RE: [rest-discuss] Resources vs. Representations
Message:


> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Friday, September 06, 2002 1:20 PM
> To: Mathews, Walden
> Cc: 'Mark Baker'; 'Bill de hra'; 'Vincent D Murphy'; 'S. 
> Mike Dierken';
> 'rest-discuss'
> Subject: Re: [rest-discuss] Resources vs. Representations 
> (was Re: Other
> v iew of DELETE?)
> 
> 
> On Fri, Sep 06, 2002 at 01:08:32PM -0400, Mathews, Walden wrote:
> > My reservations about 301 indicating equivalence comes from the
> > asymmetry of 301, but otherwise I see where you're coming from.
> 
> Hmm, what asymmetry?

X says "see Y", but Y doesn't say "see X", so it's asymmetric.

Walden






-----------------------------------------------------------------------------------
Post ID:2416
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-06 18:55:14
Subject:Re: [rest-discuss] Idempotent sequences
Message:

On Fri, Sep 06, 2002 at 05:53:31AM +0100, Miles Sabin wrote:
> Mathews, Walden wrote,
> > I suspect that any disagreement about the idempotence of a string
> > of idempotent HTTP operations has more to do with the way you
> > might map HTTP operations onto the meaning of 'idempotent' than
> > with the particular proof you offered.  We touched on this before.
> > What is the 'function' of an HTTP PUT?  I.e., which mapping are
> > we interested in?  Clearly, sometimes it's resource before-and-after
> > state.  At other times it may be more like request-to-response
> > mapping?
> 
> Yes, I think that's right.

I don't understand the distinction I guess.

> The problem here is that these two views clearly aren't equivalent, and 
> are typically in conflict. REST, as I understand it, looks to have a 
> more natural fit with the resource before-and-after state view. So does 
> that mean that REST is in conflict with part of RFC 2616? If it is in 
> conflict, is that a problem for REST, or is it the inevitable 
> consequence of an inconsistency in RFC 2616?
> 
> FWIW, the interpretation of idempotent sequences of requests isn't 
> merely a niggling theoretical puzzle: it has direct implications for 
> the implementation of HTTP/1.1 request piplining on the client side. 
> Having built non-caching HTTP/1.1 proxies which support piplining 
> across from downstream clients to upstream origin servers, I can vouch 
> for the fact that the tensions in section 9.1 are a real headache with 
> uncomfortable implications for interoperability.
> 
> Mark (B and N), you've done work in a similar area, so you must have run 
> into the same issue: how did you resolve it?

We haven't had any troubles.  We tried to use Jeff Mogul's out-of-order
spec, but had practical issues with it (it requires using a new client
stack).  But we don't have a lot of heard reliability guarantees in our
use of our platform, so it's possible that I'm missing an edge case
that demonstrates the disconnect.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2417
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-06 18:57:03
Subject:Re: [rest-discuss] Idempotent sequences
Message:

Mathews, Walden wrote,
> Miles Sabin wrote,
> > The problem here is that these two views clearly aren't equivalent,
> > and are typically in conflict. REST, as I understand it, looks to
> > have a more natural fit with the resource before-and-after state
> > view. So does that mean that REST is in conflict with part of RFC
> > 2616? If it is in conflict, is that a problem for REST, or is it the
> > inevitable consequence of an inconsistency in RFC 2616?
>
> Sorry, which part of 2616 do you think is in conflict with REST over
> the issue of idempotence?

REST operates only in terms of resource/server state (ie. the resource 
before-and-after state view) and understands idempotence in only those 
terms. RFC 2616's understanding of idempotence seems to defined in 
terms of both resource/server state and client-visible results.

That means it's likely that there will be cases which are idempotent 
according to REST, but not according to RFC 2616 (and possibly vice 
versa). My proof that on the resource/server state view (which I take 
to be the REST view) all sequences of idempotent requests are 
idempotent sequences looks like being an example because it rules out a 
possibility explictly mentioned by RFC 2616.

It could be that RFC 2616 is wrong to suggest the possiblity of 
non-idempotent sequences of idempotent methods. OTOH, it could mean 
that there's a disconnect with REST, and that RFC 2616 really does mean 
to include client visible results in it's definition of idempotence 
(tho' if that's the case there are some delicate issues with client 
visible results of PUT and DELETE).

I'd like to know which. If nothing else, it'd make implementing HTTP/1.1 
request piplining a lot easier if the REST view is right.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2418
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-06 19:18:58
Subject:Re: [rest-discuss] Idempotent sequences
Message:

Mark Baker wrote,
> On Fri, Sep 06, 2002 at 05:53:31AM +0100, Miles Sabin wrote:
> > Mathews, Walden wrote,
> >
> > > I suspect that any disagreement about the idempotence of a string
> > > of idempotent HTTP operations has more to do with the way you
> > > might map HTTP operations onto the meaning of 'idempotent' than
> > > with the particular proof you offered.  We touched on this
> > > before. What is the 'function' of an HTTP PUT?  I.e., which
> > > mapping are we interested in?  Clearly, sometimes it's resource
> > > before-and-after state.  At other times it may be more like
> > > request-to-response mapping?
> >
> > Yes, I think that's right.
>
> I don't understand the distinction I guess.

OK, I think this example illustrates the difference,

  DELETE /foo   =>  200 OK
  DELETE /foo   =>  404 Not Found

On the resource/server state view the only things which count towards 
idempotence are changes of state at the server (I take this to be the 
REST view). Because the effect on the server of deleting /foo two or 
more times is the same as the effect on the server of deleting it just 
once we can count DELETE as idempotent.

On the client-visible-effects view the result is relevant (maybe as well 
as server state, maybe instead of). Because the client visible results 
of the second and subsequent deletions of /foo are different from that 
of the first we can't count DELETE as idempotent.

Given that RFC 2616 stipulates that DELETE is idempotent it seems as 
tho' the client-visible-effects view must be wrong. But that can't be 
the whole story because of RFC 2616's allusions to non-idempotent 
sequences of idempotent requests. If my proof that on the resource/ 
server view all sequences of idempotent requests are idempotent 
sequences is correct, then either there's something wrong with RFC 2616 
(maybe the discussion of non-idempotent sequences should be dropped, or 
maybe there's an inconsistency somewhere), or there's something wrong 
with the resource/server state view and hence a disconnect between REST 
and RFC 2616.

> We haven't had any troubles.  We tried to use Jeff Mogul's
> out-of-order spec, but had practical issues with it (it requires using
> a new client stack).  But we don't have a lot of heard reliability
> guarantees in our use of our platform, so it's possible that I'm
> missing an edge case that demonstrates the disconnect.

Does your client stack implement request piplining? If it does, there's 
presumably somewhere where a decision has to be made about whether to 
pipeline a request immediately or wait for pending responses to arrive. 
I played cautious and only allowed piplining for GET and then only if 
the only pending responses were for GETs.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2419
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-06 19:26:48
Subject:Re: [rest-discuss] Idempotent sequences
Message:

On Fri, Sep 06, 2002 at 08:18:58PM +0100, Miles Sabin wrote:
> OK, I think this example illustrates the difference,

Ah, ok.  I didn't recognize those terms as characterizing this
example.

>   DELETE /foo   =>  200 OK
>   DELETE /foo   =>  404 Not Found

I wonder, but I can't find anything in 2616 which says that a DELETE
on a non-existent resource has to return 404.  I also can't find
anything that suggests that a 200 response is wrong.

So perhaps DELETE is just under-defined?  Are there other examples
that demonstrate this issue that don't use DELETE?  Conditional PUTs
maybe?  Dunno.

> Does your client stack implement request piplining? If it does, there's 
> presumably somewhere where a decision has to be made about whether to 
> pipeline a request immediately or wait for pending responses to arrive. 
> I played cautious and only allowed piplining for GET and then only if 
> the only pending responses were for GETs.

We only block on non-idempotent methods (POST).

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2420
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-06 19:57:18
Subject:Re: [rest-discuss] Idempotent sequences
Message:

Mark Baker wrote,
> Ah, ok.  I didn't recognize those terms as characterizing this
> example.
>
> >   DELETE /foo   =>  200 OK
> >   DELETE /foo   =>  404 Not Found
>
> I wonder, but I can't find anything in 2616 which says that a DELETE
> on a non-existent resource has to return 404.  I also can't find
> anything that suggests that a 200 response is wrong.

True, but consider this sequence,

  DELETE /foo   =>  200 OK
  GET /foo      =>  404 Not Found
  DELETE /foo   =>  200 OK (Huh??? Wasn't /foo gone just a moment ago ?)

> So perhaps DELETE is just under-defined?

Perhaps, but I don't think 200 would be the right way to fill out the 
gap in this case.

> Are there other examples that demonstrate this issue that don't use
> DELETE?  Conditional PUTs maybe?  Dunno.

Well, anything where you'd expect to get a different response on the 
first request than on a second or subsequent request. Actually if the 
first PUT creates a new resource the request doesn't even need to be 
conditional to get something similar,

  PUT /foo      =>  201 Created  (this is a MUST in 9.6)
  PUT /foo      =>  200 OK       (this is a SHOULD)

Given that this behavior isn't underspecified, PUT is probably a better 
eg. than DELETE.

> > Does your client stack implement request piplining? If it does,
> > there's presumably somewhere where a decision has to be made about
> > whether to pipeline a request immediately or wait for pending
> > responses to arrive. I played cautious and only allowed piplining
> > for GET and then only if the only pending responses were for GETs.
>
> We only block on non-idempotent methods (POST).

So unless I'm missing something you're treating all sequences of 
idempotent requests as idempotent sequences? In which case how do you 
interpret that passage from RFC 2616, 9.1? (seeing as you're ignoring 
it ;-)

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2421
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-06 20:03:27
Subject:RE: [rest-discuss] Idempotent sequences
Message:

Miles,

This is not a properly researched statement (sorry for that, no
time) but I think I recall the same language in the REST manifesto
(to be called "maniRESTo" hence) about non-idempotence in sequences
of idempotent operations.  So if that's true, then it's not RFC
2616 vs. REST, it's something else.

Walden

> -----Original Message-----
> From: Miles Sabin [mailto:miles@...]
> Sent: Friday, September 06, 2002 3:19 PM
> To: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Idempotent sequences
> 
> 
> Mark Baker wrote,
> > On Fri, Sep 06, 2002 at 05:53:31AM +0100, Miles Sabin wrote:
> > > Mathews, Walden wrote,
> > >
> > > > I suspect that any disagreement about the idempotence 
> of a string
> > > > of idempotent HTTP operations has more to do with the way you
> > > > might map HTTP operations onto the meaning of 'idempotent' than
> > > > with the particular proof you offered.  We touched on this
> > > > before. What is the 'function' of an HTTP PUT?  I.e., which
> > > > mapping are we interested in?  Clearly, sometimes it's resource
> > > > before-and-after state.  At other times it may be more like
> > > > request-to-response mapping?
> > >
> > > Yes, I think that's right.
> >
> > I don't understand the distinction I guess.
> 
> OK, I think this example illustrates the difference,
> 
>   DELETE /foo   =>  200 OK
>   DELETE /foo   =>  404 Not Found
> 
> On the resource/server state view the only things which count towards 
> idempotence are changes of state at the server (I take this to be the 
> REST view). Because the effect on the server of deleting /foo two or 
> more times is the same as the effect on the server of 
> deleting it just 
> once we can count DELETE as idempotent.
> 
> On the client-visible-effects view the result is relevant 
> (maybe as well 
> as server state, maybe instead of). Because the client 
> visible results 
> of the second and subsequent deletions of /foo are different 
> from that 
> of the first we can't count DELETE as idempotent.
> 
> Given that RFC 2616 stipulates that DELETE is idempotent it seems as 
> tho' the client-visible-effects view must be wrong. But that can't be 
> the whole story because of RFC 2616's allusions to non-idempotent 
> sequences of idempotent requests. If my proof that on the resource/ 
> server view all sequences of idempotent requests are idempotent 
> sequences is correct, then either there's something wrong 
> with RFC 2616 
> (maybe the discussion of non-idempotent sequences should be 
> dropped, or 
> maybe there's an inconsistency somewhere), or there's something wrong 
> with the resource/server state view and hence a disconnect 
> between REST 
> and RFC 2616.
> 
> > We haven't had any troubles.  We tried to use Jeff Mogul's
> > out-of-order spec, but had practical issues with it (it 
> requires using
> > a new client stack).  But we don't have a lot of heard reliability
> > guarantees in our use of our platform, so it's possible that I'm
> > missing an edge case that demonstrates the disconnect.
> 
> Does your client stack implement request piplining? If it 
> does, there's 
> presumably somewhere where a decision has to be made about whether to 
> pipeline a request immediately or wait for pending responses 
> to arrive. 
> I played cautious and only allowed piplining for GET and then only if 
> the only pending responses were for GETs.
> 
> Cheers,
> 
> 
> Miles
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2422
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-06 21:22:25
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

----- Original Message -----
From: "Vincent D Murphy" <vdm@...>

> i doubt that IE/netscape were ever architected to allow users to edit
representations.

IE has some pretty amazing 'edit mode' DHTML capabilities. With DOM events
and javascript you can build a full wysiwyg editor totally within the
browser. I even remember seeing some company (blox?) with a spreadsheet done
in dhtml+script.








-----------------------------------------------------------------------------------
Post ID:2423
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-06 21:27:52
Subject:Re: [rest-discuss] Resources - when two are one
Message:

----- Original Message -----
From: "Mathews, Walden" <waldenm@...>

> >
> > // are these true?
> > assert(server.resource(uri1).body == content2.body);
>
> According to that weird 'PUT' rule, it would have to be :-(

I was assuming that the GET requests against the two different URI (which
are the 'same' resource) have the exact same headers.
I wasn't relying on PUT's weird definition for the content to be equivalent.
I'm just trying to figure out /why/ they would be different.






-----------------------------------------------------------------------------------
Post ID:2424
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-06 21:18:06
Subject:Re: [rest-discuss] Resources - when two are one
Message:

----- Original Message -----
From: "Miles Sabin" <miles@...>


> S. Mike Dierken wrote,
> > > Not necessarily.  For instance, you may have an online document
> > > which show in English for uri1 and French for uri2.  Same resource,
> > > different representations.
> >
> > I was thinking that the Accept, Accept-Language, etc. request headers
> > would be used to distinguish certain representations against the same
> > URI.
>
> Even in this case the response entity is allowed to vary. GET must not
> mutate the server/resource state, but it doesn't follow that a constant
> response entity must be returned.

Yes, I got that... its the approach where you have the same resource, but
different representation at /different/ URIs. I don't get that usage.
HTTP has enough headers to do most any varying representation against a
single URI.

I'm looking for what guarantees can be made when two URI are one resource.








-----------------------------------------------------------------------------------
Post ID:2425
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-06 21:24:13
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

----- Original Message -----
From: <paul@...>

> After all, a service that regularly craps out on you sometime in the
afternoon
> is hardly something you can trust and build important applications on.
You mean like a programmer without coffee?







-----------------------------------------------------------------------------------
Post ID:2426
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-06 21:28:46
Subject:Re: [rest-discuss] what is state?
Message:

Good gravy... I was going to post the same question last night....

----- Original Message ----- 
From: "Seairth Jacobs" <seairth@...>
To: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Friday, September 06, 2002 8:41 AM
Subject: [rest-discuss] what is state?








-----------------------------------------------------------------------------------
Post ID:2427
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-07 04:16:21
Subject:Re: [rest-discuss] Resources - when two are one
Message:


Seairth Jacobs wrote:

>Not necessarily.  For instance, you may have an online document which show
>in English for uri1 and French for uri2.  Same resource, different
>representations.
>
Your mistake is thinking that the document is the resource.  In this 
case, it is not.  Using your scheme, the resource identified by uri1 is 
'the document rendered in English'.  The resource identified by uri2 is 
'the document rendered in French'.

Of course, one can argue as to whether this is an appropriate way to 
make the French and English version of the document available...

--Chuck







-----------------------------------------------------------------------------------
Post ID:2428
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-07 05:29:57
Subject:Re: [rest-discuss] Resources vs. Representations
Message:


Mark Baker wrote:

>On Thu, Sep 05, 2002 at 01:59:40PM -0400, Mathews, Walden wrote:
>
>>Oh, I wanted to say one other thing on this subject.  There is
>>this idea that if we PUT a resource through its URI, then we GET
>>that resource back, we should get back the same value as we PUT.
>>That statement implies that we have representation-level control,
>>which we do not.  It would make more sense to think of it this
>>way.  If we PUT a representation to a URI, then GET back a representation,
>>the latter representation *means the same thing* as the former,
>>though it may differ in format or even typographically.  THoughts?
>>
>
>Actually, PUT's a bit funny that way.  It's definined to really mean
>"store" more than "set the state", so it is expected that bits are
>preserved.  
>
I'm having a hard time understanding why you say this.  In reading 2616, 
I can see how that might be one possible interpretation, but I don't see 
that it requires that interpretation.  Perhaps I'm missing something 
(quite likely).

I would like to think that if I want to create a resource that indicates 
the temperature in Paris at 0600 25-May-2002, I should be able to PUT 
the temperature in degrees Farenheit or Celcius.  And further, assuming 
some suitable kind of content negotiation, I would think that even 
though I PUT degrees Farenheit, I should be able to GET degrees Celcius.

--Chuck








-----------------------------------------------------------------------------------
Post ID:2429
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-07 17:54:56
Subject:Re: [rest-discuss] Resources - when two are one
Message:

From: "Chuck Hinson" <cmhinson@...>
>
> >Not necessarily.  For instance, you may have an online document which
show
> >in English for uri1 and French for uri2.  Same resource, different
> >representations.
> >
> Your mistake is thinking that the document is the resource.  In this
> case, it is not.  Using your scheme, the resource identified by uri1 is
> 'the document rendered in English'.  The resource identified by uri2 is
> 'the document rendered in French'.

Okay, change it from "an online document" to "a resource".  I think the
example was perfectly valid.  Of course, it was pointed out that this
particular example gets into the issue of the "Accept-Language".  The point
I was making was that it's perfectly legitimate to have a single resource
that returns different representations (where only the entity is different).
Therefore, you could not depend on content-type, content-length, or the
entity body itself  (or any combination of them) to confidently state
whether two URIs point to the same resource or not.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2430
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-07 19:01:03
Subject:Re: [rest-discuss] Resources - when two are one
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

> The point
> I was making was that it's perfectly legitimate to have a single resource
> that returns different representations (where only the entity is
different).
> Therefore, you could not depend on content-type, content-length, or the
> entity body itself  (or any combination of them) to confidently state
> whether two URIs point to the same resource or not.

Right - so if we /did/ hold the accept-style headers constant for requests
against the two URIs, what logical guarantees can be made?
If not for read-operations, what about write-operations?
Will there be a guarantee that a write operation of some kind against uri1
has a visible effect when inspecting uri2?







-----------------------------------------------------------------------------------
Post ID:2431
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-07 19:31:27
Subject:Re: [rest-discuss] what is state?
Message:

From: "Chuck Hinson" <cmhinson@...>
>
> Seairth Jacobs wrote:
>
> >In all of these conversations, we keep speaking of resource state.
However,
> >I am losing all understanding of what resource state actually is...
> >
> >A resource has a state. One can only retrieve a representation of the
> >current state of a resource.
> >
> >But then we are told that we can receive different representations of the
> >same state.  For instance, the same resource could be returned in
different
> >spoken languages or in different content-types.  However, these are both
> >indicated by HTTP headers and not within the returned entity itself.
> >
> What is the problem with that?  If the resource is 'the temperature at
> which water freezes' then there are at least two representations: 32
> degrees Farenhiet or 0 degrees Celsius.  (Ignore for now how the server
> decides which representation to deliver.)

I have not problem with that.  At this point, I would consider "state" and
"resource" to be one and the same.

> >
> >However, it you look at the infamous "hit counter", the returned entity
> >could differ between calls.  But it seems to me that people are saying
that
> >the state hasn't necessarily changed.
> >
> >If this is true, then it seems to me that the concept of "state" is more
of
> >a logical (?) concept than a physical (?) concept.
> >
>
> If I understand your distinction between logical and physical, then I
> would say that not only is "state" a logical concept, but so is
> "resource".  The only thing that is "physical" is the representation.

Sure, I too believe that "resources" only logically exist.  It is not
possible for a client to *know* the physical format of what makes up the
"resource".


I realize after reading my original post that I wasn't very clear in my
thoughts.  So, I'll try again...


In REST, we have three things (of interest to this topic):

1) Resource : we all agree that a resource is something identified by a URI.
The resource itself is only a concept.  It may or may not have a one-to-one
relationship with a "physical" entity (file, purchase order, person, car,
etc.).  For instance, one could have a purchase order stored in multiple
tables on a remote SQL server and we would still be able to consider the PO
as a resource.  Also, it is possible for more than one URI to identify the
same resource.

2) Representation : when one requests a resource, it can never be given the
actual resource.  Instead, the request gets back a representation of the
resource.  This representation is unique to the request URI (though more
than one URI could return unique representations that are byte-wise
identical).  An important point here is that "representation" only has
meaning in context to a response from the server.  In other words, one
cannot speak of sending a representation in a request.

3) State : what is state?  On the one hand, I think of state in the
"traditional" sense, which just means "what the resource is at a given
moment in time (usually 'now')".  But it is not possible to know what the
state of a resource is.  All that one can know is the representation
returned, which is presumably the "current state".  In fact, all that is
ever visible is the "current state".  From what I've read so far, there's
nothing in REST itself with clearly defines how to know when "state" has
changed.  This is left up to the application.

The other way of thinking of state it to related it to "representation"
instead.  In other words, under this view, all that a client knows is the
state of a resource, not the resource itself.  When we PUT an entity, we are
PUTting "the current state" of a resource and not the resource itself.  When
we use GET, we get back a "representation of the state of the resource", not
the resource itself.  This view certainly makes it more clear what "state"
is, but it also raises some questions.

    a) RFC2616 Section 9.6 (PUT) talks about the ability of a client to
request the creation of a resource located at the Request-URI.  Now, in term
s of REST, would it be more appropriate to say that the client is requesting
the creation of a resource whose initial state is that of the
request-entity?

    b) If you have two URIs identifing the same resource, suppose the
following sequence:

        PUT <entity> uri1
        GET uri1
        PUT <entity2> uri2
        GET uri1

        We would agree that the state of the resource changed after each PUT
request.  However, it would still be possible for the second GET to return a
byte-wise identical representation as the first GET.  How would we know that
the state changed?  Or is this scenario not allowed when using PUT?  Can
this only happen with POST?

    c) When issuing a DELETE against a URI, are we deleting the current
state or the resource itself? [note: In an earlier post, I had suggested
that the DELETE was actually deleting the identity (i.e. the relationship of
the URI to the resource).  It was up to the server to delete the resource or
not.]

    d) Does a URI identify the state of a resource or the resource itself?




<sigh>well, I had to step away again and have lost my train of thought...
again.  re-reading what I wrote hasn't helped, so I will stop here.</sigh>

I guess the nutshell version of all of the above is that "state" obviously
has a place in the REST (it's even in the name!).  But I am not
understanding how it fits.  I have all sorts of individual notions of how
"state" may be used, but none of them really work with each other and they
all bring up questions that cause the REST model to be unclear in other
areas.

Now, I realize that this could also be due to the fact that we use HTTP 1.1
as a RESTful example.  I am beginning to wonder if this is not so much the
case as we are led to believe.  Or it could be that the things I am asking
about and the questions I have are mostly "edge cases" and therefore less
likely to be an issue for 80% of the people who will use REST....

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2432
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-09-07 22:24:49
Subject:Re: [rest-discuss] what is state?
Message:

On Saturday, Sep 7, 2002, at 20:31 Europe/Dublin, Seairth Jacobs wrote:
> 2) Representation : when one requests a resource, it can never be 
> given the
> actual resource.  Instead, the request gets back a representation of 
> the
> resource.  This representation is unique to the request URI (though 
> more
> than one URI could return unique representations that are byte-wise
> identical).

agreed..

> An important point here is that "representation" only has
> meaning in context to a response from the server.  In other words, one
> cannot speak of sending a representation in a request.

i think this is incorrect.  can't representations be PUT/POSTed as 
well, as the body of the request?







-----------------------------------------------------------------------------------
Post ID:2433
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-07 23:39:10
Subject:Re: [rest-discuss] what is state?
Message:

From: "Vincent D Murphy" <vdm@...>
>
> On Saturday, Sep 7, 2002, at 20:31 Europe/Dublin, Seairth Jacobs wrote:
> > An important point here is that "representation" only has
> > meaning in context to a response from the server.  In other words, one
> > cannot speak of sending a representation in a request.
>
> i think this is incorrect.  can't representations be PUT/POSTed as
> well, as the body of the request?

No, I wouldn't think so.  You can send "request data".  The data may either
have a specific meaning (e.g. PUT of a resource state) or not (e.g. various
uses of POST), but it isn't a representation.  A representation (in the
context of this discussion) can only exist as it relates to a resource.
Only the server has resources and only the server returns representations of
those resources.  I think...

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2434
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-08 03:30:20
Subject:Re: [rest-discuss] Resources - when two are one
Message:


S. Mike Dierken wrote:

>----- Original Message -----
>From: "Seairth Jacobs" <seairth@...>
>
>>The point
>>I was making was that it's perfectly legitimate to have a single resource
>>that returns different representations (where only the entity is
>>
>different).
>
>>Therefore, you could not depend on content-type, content-length, or the
>>entity body itself  (or any combination of them) to confidently state
>>whether two URIs point to the same resource or not.
>>
>
>Right - so if we /did/ hold the accept-style headers constant for requests
>against the two URIs, what logical guarantees can be made?
>If not for read-operations, what about write-operations?
>Will there be a guarantee that a write operation of some kind against uri1
>has a visible effect when inspecting uri2?
>
First, I'm not sure I understand why it would be useful to be able to do 
this.

Second, I don't think you can make any sort of generalization about what 
behavior or properties you might observe when two URIs name the same 
resource.  The characteristics of resources vary so greatly, that I 
don't see that there would be any way to establish any kind of generic 
guarantee that would hold across all resources.  I'm sure that for set 
of simple cases you might be able to guarantee some sort of byte-wise 
equivalence, but I don't see that happening across all types of resources.

Third, I suspect that in many cases, when two URIs appear to name the 
same resource, they actually don't.  For example, some people might 
(mistakenly) believe that the following URIs name the same resource
        http://www.w3.org/TR/2002/WD-webarch-20020830/
        http://www.w3.org/TR/webarch/

--Chuck








-----------------------------------------------------------------------------------
Post ID:2435
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-08 03:52:01
Subject:Re: [rest-discuss] what is state?
Message:


Seairth Jacobs wrote:

>From: "Vincent D Murphy" <vdm@...>
>
>>On Saturday, Sep 7, 2002, at 20:31 Europe/Dublin, Seairth Jacobs wrote:
>>
>>>An important point here is that "representation" only has
>>>meaning in context to a response from the server.  In other words, one
>>>cannot speak of sending a representation in a request.
>>>
>>i think this is incorrect.  can't representations be PUT/POSTed as
>>well, as the body of the request?
>>
>
>No, I wouldn't think so.  You can send "request data".  The data may either
>have a specific meaning (e.g. PUT of a resource state) or not (e.g. various
>uses of POST), but it isn't a representation.  A representation (in the
>context of this discussion) can only exist as it relates to a resource.
>Only the server has resources and only the server returns representations of
>those resources.  I think...
>
Yes, you do send representations in PUT and POST.  The "Transfer" in 
Representational State Transfer is not just for responses - it also 
applies to requests.  A PUT request contains a representation of the 
resource you want to store at the specified URI.  And according to Mark 
B., the representation transferred in the PUT is the same representation 
(bytewise) that'll be returned by a GET of the same resource (assuming 
no intervening state changes).

I would argue the same holds for POST.  A POST request transfers an 
entity to the server.  I don't see any reason not to consider that 
entity a representation of some (perhaps unnamed) resource. In fact, in 
some cases, the representation that is transferred will be GETable as a 
named resource once it is submitted to the server.

--Chuck








-----------------------------------------------------------------------------------
Post ID:2436
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-08 05:22:08
Subject:Re: [rest-discuss] Resources - when two are one
Message:


>
> Second, I don't think you can make any sort of generalization about what
> behavior or properties you might observe when two URIs name the same
> resource.
The point I'm making is that any claim that server.resource(uri1) ===
server.resource(uri2) is unverifiable and indistinguishable from bogus
claims like server.resource("www.slashdot.net") ===
server.resource("www.microsoft.com")

If you can't demonstrate any runtime effects of claming two resources are
the same, then why make the claim?







-----------------------------------------------------------------------------------
Post ID:2437
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-08 05:25:38
Subject:Re: [rest-discuss] what is state?
Message:


Seairth Jacobs wrote:

[...]

>
>1) Resource : we all agree that a resource is something identified by a URI.
>The resource itself is only a concept.  It may or may not have a one-to-one
>relationship with a "physical" entity (file, purchase order, person, car,
>etc.).  For instance, one could have a purchase order stored in multiple
>tables on a remote SQL server and we would still be able to consider the PO
>as a resource.  Also, it is possible for more than one URI to identify the
>same resource.
>

For the most part, I think I agree, although I'm suspicious of the first 
and last sentences.  In my mind, the only relationship between URIs and 
resources is that resources arent very useful if they dont have names 
with which they can be referenced.

>
>2) Representation : when one requests a resource, it can never be given the
>actual resource.  Instead, the request gets back a representation of the
>resource.  This representation is unique to the request URI (though more
>than one URI could return unique representations that are byte-wise
>identical).  An important point here is that "representation" only has
>meaning in context to a response from the server.  In other words, one
>cannot speak of sending a representation in a request.
>

I don't understand what you're trying to say when you say the 
representation is unique to the request URI.  A representation only has 
meaning in connection with the resource it represents.  Actually, the 
meaning of a representation is dependent on the resource it represents. 
 But I'm not sure what we're accomplishing by pointing that out.

>
>
>3) State : what is state?  On the one hand, I think of state in the
>"traditional" sense, which just means "what the resource is at a given
>moment in time (usually 'now')".  But it is not possible to know what the
>state of a resource is. 
>

What do you mean by this?  The representation tells you exactly what the 
state of the resource was when the request was serviced.

> All that one can know is the representation
>returned, which is presumably the "current state".  In fact, all that is
>ever visible is the "current state".  From what I've read so far, there's
>nothing in REST itself with clearly defines how to know when "state" has
>changed.  This is left up to the application.
>

I would agree - REST focuses mainly on transferring state.  Only the 
application can determine what you should do or observe in order to 
determine whether the state of a resource has changed.

>
>
>The other way of thinking of state it to related it to "representation"
>instead.  In other words, under this view, all that a client knows is the
>state of a resource, not the resource itself.  When we PUT an entity, we are
>PUTting "the current state" of a resource and not the resource itself.  
>

When we do a PUT, we are transferring a representation of the state we 
want the specified resource to have.  If the specified resource does not 
already exist, it will be created before the PUT operation is applied to it.

>When
>we use GET, we get back a "representation of the state of the resource", not
>the resource itself.  This view certainly makes it more clear what "state"
>is, but it also raises some questions.
>
>     a) RFC2616 Section 9.6 (PUT) talks about the ability of a client to
>request the creation of a resource located at the Request-URI.  Now, in term
>s of REST, would it be more appropriate to say that the client is requesting
>the creation of a resource whose initial state is that of the
>request-entity?
>

 From 9.6 in 2616
<quote> The PUT method requests that the enclosed entity be stored under 
the supplied  Request-URI. </quote>

The enclosed entity is a representation of the resource's "inital state" 
as you call it.

>
>    b) If you have two URIs identifing the same resource, suppose the
>following sequence:
>
>        PUT <entity> uri1
>        GET uri1
>        PUT <entity2> uri2
>        GET uri1
>
>        We would agree that the state of the resource changed after each PUT
>request.  
>

I'm not sure that I would agree to that.  You can't know whether or not 
the resource will change state without knowing the specifics of that 
particular resource.  For some resources, your statement would be true. 
 For others it would not.

>However, it would still be possible for the second GET to return a
>byte-wise identical representation as the first GET.  How would we know that
>the state changed? 
>

You'd have to read the [API] documentation for that specific resource in 
order to know what you have to do to detect a state change.

>Or is this scenario not allowed when using PUT?  Can
>this only happen with POST?
>
>    c) When issuing a DELETE against a URI, are we deleting the current
>state or the resource itself? 
>

 From 9.7 in 2616
<quote>The DELETE method requests that the origin server delete the resource
identified by the Request-URI. </quote>

>[note: In an earlier post, I had suggested
>that the DELETE was actually deleting the identity (i.e. the relationship of
>the URI to the resource).  It was up to the server to delete the resource or
>not.]
>
>    d) Does a URI identify the state of a resource or the resource itself?
>

A URI identifies a resource.  The state of the resource is what is 
transferred as input and/or output by some of the various methods that 
can be applied to the resource.


I'm not sure whether I'm helping here or not.  It all seems clear to me 
(for now) - I'm just not sure I can describe things in a way that's 
helpful to anyone else.

--Chuck








-----------------------------------------------------------------------------------
Post ID:2438
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-08 05:37:26
Subject:Re: [rest-discuss] Resources - when two are one
Message:


S. Mike Dierken wrote:

>
>>Second, I don't think you can make any sort of generalization about what
>>behavior or properties you might observe when two URIs name the same
>>resource.
>>
>The point I'm making is that any claim that server.resource(uri1) ===
>server.resource(uri2) is unverifiable and indistinguishable from bogus
>claims like server.resource("www.slashdot.net") ===
>server.resource("www.microsoft.com")
>
>If you can't demonstrate any runtime effects of claming two resources are
>the same, then why make the claim?
>
In the general case I agree.  For two arbitrary URIs, I don't believe 
there's any way to determine whether they identify the same resource or not.

However, for a specific resource identified by two or more URIs, I would 
think that it might be possible to determine equivalence of URIs.  The 
rules for making that determination would, however, only be valid for 
that specific resource and would probably require detailed knowledge of 
the resource for which URI equivalence was being tested.  

Hmm.  Having said all that, I'm beginning to think the best you may be 
able to do is to determine non-equivalence.

--Chuck








-----------------------------------------------------------------------------------
Post ID:2439
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-09 02:18:23
Subject:Re: [rest-discuss] what is state?
Message:

From: "Chuck Hinson" <cmhinson@...>
>
> Seairth Jacobs wrote:
>
> >No, I wouldn't think so.  You can send "request data".  The data may
either
> >have a specific meaning (e.g. PUT of a resource state) or not (e.g.
various
> >uses of POST), but it isn't a representation.  A representation (in the
> >context of this discussion) can only exist as it relates to a resource.
> >Only the server has resources and only the server returns representations
of
> >those resources.  I think...
> >
> Yes, you do send representations in PUT and POST.  The "Transfer" in
> Representational State Transfer is not just for responses - it also
> applies to requests.

This makes no sense to me.  What is a request entity a representation of?

>  A PUT request contains a representation of the
> resource you want to store at the specified URI.  And according to Mark
> B., the representation transferred in the PUT is the same representation
> (bytewise) that'll be returned by a GET of the same resource (assuming
> no intervening state changes).

>From RFC2616 Section 9.6:

<quote>The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already existing
resource, the enclosed entity SHOULD be considered as a modified version of
the one residing on the origin server. If the Request-URI does not point to
an existing resource, and that URI is capable of being defined as a new
resource by the requesting user agent, the origin server can create the
resource with that URI.</quote>

I see nothing here saying that the request entity is a representation.  All
that I see is a request entity that may replace or create a new resource
identified by the request-URI.

> I would argue the same holds for POST.  A POST request transfers an
> entity to the server.  I don't see any reason not to consider that
> entity a representation of some (perhaps unnamed) resource. In fact, in
> some cases, the representation that is transferred will be GETable as a
> named resource once it is submitted to the server.

I would be even less inclined to agree with you for POST.  POST only
tansfers a request entity.  That's it.  Seeing it as a representation of an
unnamed resource only make the REST model (as applied to HTTP) more
confusing to me, not less.

This would be an entirely different matter if the request also contained a
URI that identified an actual resource that the request entity could be
considered a representation of (sort of a PUSH usage instead of PULL).  But
it doesn't.  Not even when using PUT.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2440
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-09 02:26:59
Subject:Re: [rest-discuss] what is state?
Message:

On Sat, Sep 07, 2002 at 11:52:01PM -0400, Chuck Hinson wrote:
> I would argue the same holds for POST.  A POST request transfers an 
> entity to the server.  I don't see any reason not to consider that 
> entity a representation of some (perhaps unnamed) resource. In fact, in 
> some cases, the representation that is transferred will be GETable as a 
> named resource once it is submitted to the server.

Exactly.

If the data being transferred cannot be described as a representation of
some (perhaps unnamed) resource, then you're not doing it right.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2441
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-09-09 02:50:24
Subject:Re: [rest-discuss] what is state?
Message:

On Sun, Sep 08, 2002 at 10:26:59PM -0400, Mark Baker wrote:
> On Sat, Sep 07, 2002 at 11:52:01PM -0400, Chuck Hinson wrote:
> > I would argue the same holds for POST.  A POST request transfers an 
> > entity to the server.  I don't see any reason not to consider that 
> > entity a representation of some (perhaps unnamed) resource. In fact, in 
> > some cases, the representation that is transferred will be GETable as a 
> > named resource once it is submitted to the server.
> 
> Exactly.
> 
> If the data being transferred cannot be described as a representation of
> some (perhaps unnamed) resource, then you're not doing it right.

Hmm ...

On Sun, Sep 08, 2002 at 10:18:23PM -0400, Seairth Jacobs wrote:
> 
> I see nothing here saying that the request entity is a representation.  All
> that I see is a request entity that may replace or create a new resource
> identified by the request-URI.

This has always bothered me too. Unless I misunderstand the concept of
'representation' (which is perfectly possible--I haven't gotten around
to reading Fielding's dissertation or other deep scholarly work on
REST), the ability to PUT or POST a representation raises a serious
issue which I have not seen addressed on this list.

What if a client PUTs a representation of a type that is impractical to
transform to the type of the existing resource? Doesn't that effectively
cripple the resource, upsetting the expectations of other clients? For
example, suppose your resource is an SVG graphic--one of the most
information-rich image formats, and one that can be transformed to any
output format (known in this context as a representation, right?) you
like. So your server might make available JPEG, PNG, and EPS
representations of the image. Outbound, there's no problem. But now
suppose somebody wants to PUT a JPEG to the URI? If you allow the put,
then your information-rich SVG image is now degraded to a dumb JPEG (I'm
talking about what happens in the real world, not the MIT Media Lab),
which not only contains less information than the old resource, but may
be impractical to transform to some of the representation types that are
supposed to be available.

So do you disallow certain types of representations from being PUT or 
POSTed? That certainly seems like a practical response to the problem.
But I would think that in a very large proportion of cases, you'd have
to prohibit any type but the original type of the resource--in which
case the distinction between resource and representation seems rather
academic.

Or am I just confused?

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:2442
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-09 03:57:30
Subject:Re: [rest-discuss] what is state?
Message:


Seairth Jacobs wrote:

>From: "Chuck Hinson" <cmhinson@...>
>
>>Seairth Jacobs wrote:
>>
>>>No, I wouldn't think so.  You can send "request data".  The data may
>>>
>either
>
>>>have a specific meaning (e.g. PUT of a resource state) or not (e.g.
>>>
>various
>
>>>uses of POST), but it isn't a representation.  A representation (in the
>>>context of this discussion) can only exist as it relates to a resource.
>>>Only the server has resources and only the server returns representations
>>>
>of
>
>>>those resources.  I think...
>>>
>>Yes, you do send representations in PUT and POST.  The "Transfer" in
>>Representational State Transfer is not just for responses - it also
>>applies to requests.
>>
>
>This makes no sense to me.  What is a request entity a representation of?
>
It is a respresentation of some resource.  One of the main concepts of 
REST is that you transfer representations of things, not the things 
themselves.  Note that there is no requirement that a resource have a URI.

I dont think its a terrible stretch to go from "POSTing some data" to 
"POSTing a representation." After all, what is the data that you're 
POSTing but a representation of some concept (resource).

>
>> A PUT request contains a representation of the
>>resource you want to store at the specified URI.  And according to Mark
>>B., the representation transferred in the PUT is the same representation
>>(bytewise) that'll be returned by a GET of the same resource (assuming
>>no intervening state changes).
>>
>
>>From RFC2616 Section 9.6:
>
><quote>The PUT method requests that the enclosed entity be stored under the
>supplied Request-URI. If the Request-URI refers to an already existing
>resource, the enclosed entity SHOULD be considered as a modified version of
>the one residing on the origin server. If the Request-URI does not point to
>an existing resource, and that URI is capable of being defined as a new
>resource by the requesting user agent, the origin server can create the
>resource with that URI.</quote>
>
>I see nothing here saying that the request entity is a representation.  All
>that I see is a request entity that may replace or create a new resource
>identified by the request-URI.
>

The request entity is a representation.  In other words, the data in the 
request entity comprises a representation of some resource/concept.

>
>>I would argue the same holds for POST.  A POST request transfers an
>>entity to the server.  I don't see any reason not to consider that
>>entity a representation of some (perhaps unnamed) resource. In fact, in
>>some cases, the representation that is transferred will be GETable as a
>>named resource once it is submitted to the server.
>>
>
>I would be even less inclined to agree with you for POST.  POST only
>tansfers a request entity.  That's it.  Seeing it as a representation of an
>unnamed resource only make the REST model (as applied to HTTP) more
>confusing to me, not less.
>
>This would be an entirely different matter if the request also contained a
>URI that identified an actual resource that the request entity could be
>considered a representation of (sort of a PUSH usage instead of PULL).  But
>it doesn't.  Not even when using PUT.
>

See my response above for PUT.  REST is about transferring 
representations of things.  You don't transfer anything else between 
client and server.

--Chuck








-----------------------------------------------------------------------------------
Post ID:2443
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-09 04:21:34
Subject:Re: [rest-discuss] what is state?
Message:


Matt Gushee wrote:

>On Sun, Sep 08, 2002 at 10:26:59PM -0400, Mark Baker wrote:
>
>>On Sat, Sep 07, 2002 at 11:52:01PM -0400, Chuck Hinson wrote:
>>
>>>I would argue the same holds for POST.  A POST request transfers an 
>>>entity to the server.  I don't see any reason not to consider that 
>>>entity a representation of some (perhaps unnamed) resource. In fact, in 
>>>some cases, the representation that is transferred will be GETable as a 
>>>named resource once it is submitted to the server.
>>>
>>Exactly.
>>
>>If the data being transferred cannot be described as a representation of
>>some (perhaps unnamed) resource, then you're not doing it right.
>>
>
>Hmm ...
>
>On Sun, Sep 08, 2002 at 10:18:23PM -0400, Seairth Jacobs wrote:
>
>>I see nothing here saying that the request entity is a representation.  All
>>that I see is a request entity that may replace or create a new resource
>>identified by the request-URI.
>>
>
>This has always bothered me too. Unless I misunderstand the concept of
>'representation' (which is perfectly possible--I haven't gotten around
>to reading Fielding's dissertation or other deep scholarly work on
>REST), the ability to PUT or POST a representation raises a serious
>issue which I have not seen addressed on this list.
>
>What if a client PUTs a representation of a type that is impractical to
>transform to the type of the existing resource? Doesn't that effectively
>cripple the resource, upsetting the expectations of other clients?
>
The server is free to reject the PUT request with something like:
    406 Not Acceptable
    409 Conflict
    415 Unsupported Media Type

Also, some readings of 2616 woud say that on a PUT, there's no 
transforming a representation to the existing resource type.   You're 
just storing the representation as is.

> For
>example, suppose your resource is an SVG graphic--one of the most
>information-rich image formats, and one that can be transformed to any
>output format (known in this context as a representation, right?) you
>like. So your server might make available JPEG, PNG, and EPS
>representations of the image. Outbound, there's no problem. But now
>suppose somebody wants to PUT a JPEG to the URI? If you allow the put,
>then your information-rich SVG image is now degraded to a dumb JPEG (I'm
>talking about what happens in the real world, not the MIT Media Lab),
>which not only contains less information than the old resource, but may
>be impractical to transform to some of the representation types that are
>supposed to be available.
>

Depending on the definition of the resource, it may be perfectly 
reasonable to accept a JPEG as 'input' and transform it to PNG.  Yes, 
this may result in some degradation of information, but in this case the 
owner of the resource has decided that that's OK.  Of course the 
resource may be defined in such a way that only requests in PNG format 
are accepted.

>
>So do you disallow certain types of representations from being PUT or 
>POSTed? That certainly seems like a practical response to the problem.
>But I would think that in a very large proportion of cases, you'd have
>to prohibit any type but the original type of the resource--in which
>case the distinction between resource and representation seems rather
>academic.
>
Dont confuse a resource with the entity that backs the resource.  A 
resource is a logical construct - a concept.  A resource may be backed 
by a document, and the bytes that comprise that document may correspond 
exactly to the representation of the resource, but the resource and the 
representation are never the same thing.

--Chuck









-----------------------------------------------------------------------------------
Post ID:2444
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-09-09 04:38:29
Subject:Re: [rest-discuss] what is state?
Message:

On Mon, Sep 09, 2002 at 12:21:34AM -0400, Chuck Hinson wrote:
> >
> >What if a client PUTs a representation of a type that is impractical to
> >transform to the type of the existing resource? Doesn't that effectively
> >cripple the resource, upsetting the expectations of other clients?
> >
> The server is free to reject the PUT request with something like:
>     406 Not Acceptable
>     409 Conflict
>     415 Unsupported Media Type
> 
> Also, some readings of 2616 woud say that on a PUT, there's no 
> transforming a representation to the existing resource type.   You're 
> just storing the representation as is.

In that case, does the PUTted representation become the resource at that
URI? If not, the implications are scary.
> >
> >So do you disallow certain types of representations from being PUT or 
> >POSTed? That certainly seems like a practical response to the problem.
> >But I would think that in a very large proportion of cases, you'd have
> >to prohibit any type but the original type of the resource--in which
> >case the distinction between resource and representation seems rather
> >academic.
> >
> Dont confuse a resource with the entity that backs the resource.  A 
> resource is a logical construct - a concept.  A resource may be backed 
> by a document, and the bytes that comprise that document may correspond 
> exactly to the representation of the resource, but the resource and the 
> representation are never the same thing.

I'm aware of the distinction, but I'm questioning whether it has any
practical value in cases where there is no transformation.

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:2445
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-09-09 04:58:00
Subject:Re: [rest-discuss] what is state?
Message:

> I'm aware of the distinction, but I'm questioning whether it has any
> practical value in cases where there is no transformation.

"resource vs representation" only makes sense at a conceptual level, not
at a protocol-sending-bytes-over-the-wire level.

For the image example:

 - http://foo.com/logo is a resource: a company logo

 - GET returns a representation of the company logo, possibly with content
negotiation applied to determine the image format.

 - PUT allows the webmaster to change the company logo by uploading a 
representation of another resource, in this case: "the logo I have been 
editing to replace our current company logo". This resource does not have 
a HTTP URI, although it may have a URI in a local namespace, such as a 
filename.

As was described before, the company logo resource can maintain its own
policy for accepting PUTs, depending on its internal nature (a PNG file,
an SVG file that gets rendered, a program drawing the logo on the fly, who
knows).

So:
	- resource is a concept
	- representation is a stream of bytes you can mess around with

Anyone have better definitions? Worth putting them in the REST FAQ, if
they are not already.

Michael







-----------------------------------------------------------------------------------
Post ID:2446
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-09-09 04:59:54
Subject:Re: [rest-discuss] what is state?
Message:

> > I'm aware of the distinction, but I'm questioning whether it has any
> > practical value in cases where there is no transformation.
> 
> "resource vs representation" only makes sense at a conceptual level, not
> at a protocol-sending-bytes-over-the-wire level.

I wasn't very clear; the answer was supposed to be "no it has no practical
value whatsoever, except as an aid to the conceptual design of the system
in question."

Michael







-----------------------------------------------------------------------------------
Post ID:2447
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-09 05:05:18
Subject:Re: [rest-discuss] what is state?
Message:


Matt Gushee wrote:

>On Mon, Sep 09, 2002 at 12:21:34AM -0400, Chuck Hinson wrote:
>
>>>What if a client PUTs a representation of a type that is impractical to
>>>transform to the type of the existing resource? Doesn't that effectively
>>>cripple the resource, upsetting the expectations of other clients?
>>>
>>The server is free to reject the PUT request with something like:
>>    406 Not Acceptable
>>    409 Conflict
>>    415 Unsupported Media Type
>>
>>Also, some readings of 2616 woud say that on a PUT, there's no 
>>transforming a representation to the existing resource type.   You're 
>>just storing the representation as is.
>>
>
>In that case, does the PUTted representation become the resource at that
>URI? 
>
Yes.

>If not, the implications are scary.
>
>>>So do you disallow certain types of representations from being PUT or 
>>>POSTed? That certainly seems like a practical response to the problem.
>>>But I would think that in a very large proportion of cases, you'd have
>>>to prohibit any type but the original type of the resource--in which
>>>case the distinction between resource and representation seems rather
>>>academic.
>>>
>>Dont confuse a resource with the entity that backs the resource.  A 
>>resource is a logical construct - a concept.  A resource may be backed 
>>by a document, and the bytes that comprise that document may correspond 
>>exactly to the representation of the resource, but the resource and the 
>>representation are never the same thing.
>>
>
>I'm aware of the distinction, but I'm questioning whether it has any
>practical value in cases where there is no transformation.
>
I guess I'm not sure I understand what you're getting at.  What do you 
mean by "there is no transformation"?  I don't think you can (or should) 
say that a resource is transformed into a representation - that might 
imply many things that probably aren't true.  It might be better to say 
that a resource generates a representation.

The only entity that knows whether there is "no transformation" is the 
resource's implementation.  No other entity has any way to make that 
determination - nor do I see any value in trying to do so.  When you 
request a representation of a resource, why do you care how that 
representation was generated?

--Chuck







-----------------------------------------------------------------------------------
Post ID:2448
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-09-09 04:58:05
Subject:Re: [rest-discuss] what is state?
Message:

On Mon, Sep 09, 2002 at 02:59:54PM +1000, Michael Day wrote:
> 
> > > I'm aware of the distinction, but I'm questioning whether it has any
> > > practical value in cases where there is no transformation.
> > 
> > "resource vs representation" only makes sense at a conceptual level, not
> > at a protocol-sending-bytes-over-the-wire level.
> 
> I wasn't very clear; the answer was supposed to be "no it has no practical
> value whatsoever, except as an aid to the conceptual design of the system
> in question."

Okay, that's pretty much what I thought. I guess I'm satisfied for
tonight. Thanks.

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:2449
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-09-09 05:37:00
Subject:Re: [rest-discuss] what is state?
Message:

On Mon, Sep 09, 2002 at 01:05:18AM -0400, Chuck Hinson wrote:

> >>Dont confuse a resource with the entity that backs the resource.  A 
> >>resource is a logical construct - a concept.  A resource may be backed 
> >>by a document, and the bytes that comprise that document may correspond 
> >>exactly to the representation of the resource, but the resource and the 
> >>representation are never the same thing.
> >>
> >
> >I'm aware of the distinction, but I'm questioning whether it has any
> >practical value in cases where there is no transformation.
> >
> I guess I'm not sure I understand what you're getting at.  What do you 
> mean by "there is no transformation"?  I don't think you can (or should) 
> say that a resource is transformed into a representation - that might 
> imply many things that probably aren't true.  It might be better to say 
> that a resource generates a representation.

Whoa, not so fast there! We were talking about PUTting and POSTing
things *to* a server ... let's limit it to PUT for the moment. I
understand that what lives at the URI is a resource; we are told that
what you PUT to the URI is a representation. And--perhaps out of
ignorance--I'm seeing conceptual and/or practical difficulties with that
notion. When you successfully put a representation, its contents become
the contents of a resource, right? And in that process, either those
contents can change form (e.g. from one XML vocabulary to another) or
they can't. If they can, then there's an issue of how to ensure that the
server receives something that can be meaningfully transformed --and I'm
wondering if REST has anything to say about that, or if it's left to the
application. 

If, on the other hand, those contents can never change on the way to
becoming a resource, then why not say that you 'PUT a resource'? Is
there any reason other than 'because that's not how a resource is
defined'?

> The only entity that knows whether there is "no transformation" is the 
> resource's implementation.  No other entity has any way to make that 
> determination - nor do I see any value in trying to do so.  When you 
> request a representation of a resource, why do you care how that 
> representation was generated?

Quite right--and my concern at the moment is how to implement those
resources. If I were only considering things from the client side, I
wouldn't care.

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:2450
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-09 07:47:13
Subject:Unamed resources? (WAS: what is state?)
Message:

Mark Baker wrote,
> If the data being transferred cannot be described as a representation
> of some (perhaps unnamed) resource, then you're not doing it right.

If resources can be nameless then we can't define "resource" primarily 
in terms of URIs ... ie. we can't say,

  X is a resource if and only if X is identified by some URI

I think that raises several interesting questions,

* Unnamed resources do away with the "only if", but is this a step in
  the direction of doing away with the "if" too ... ie. if we can have
  unnamed resources, why can't we also have names with no resource? eg.
  http://www.example.com/nothing-here-folks.

* If having a URI isn't the criterion of resource-hood, then what is? Is 
  "resource" just an RFC 2396 compliant way of saying "thing"?

* In the context of the discussions on the TAG list, is a URI-less
  resource "part of the Web"?

* How, if at all, do the kind of unamed resources that Mark's talking
  about here relate to RDFs anonymous nodes?

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2451
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-09-09 10:47:14
Subject:Re: [rest-discuss] Unamed resources? (WAS: what is state?)
Message:

> If resources can be nameless then we can't define "resource" primarily 
> in terms of URIs ... ie. we can't say,
> 
>   X is a resource if and only if X is identified by some URI

That seems reasonable, as there will always be some things we want to talk
about, refer to, infer properties of and so on for which there are no
suitable URI schemes. Or, resources that have a local name but no global
name, such as the email I am editing right now, before I send it (after it
is sent it will end up with possibly many global names, such as message id
URI and HTTP URI for the archive, etc).

> * Unnamed resources do away with the "only if", but is this a step in
>   the direction of doing away with the "if" too ... ie. if we can have
>   unnamed resources, why can't we also have names with no resource? eg.
>   http://www.example.com/nothing-here-folks.

The only way to have a name without a resource is to have a randomly
generated URI with no intended meaning whatsoever. That's subtly different
from having a meaningful resource with no representation. For example,
consider "news for 1 Jan 2003". That's a resource, but until 1 Jan 2003
you won't be able to get a representation of it. Nonetheless, you can
reason about it, assert properties of it such as "the news for 1 Jan 2003
will be read by news presenter X" and so on.

> * If having a URI isn't the criterion of resource-hood, then what is? Is 
>   "resource" just an RFC 2396 compliant way of saying "thing"?

Perhaps this thread would be a good place to come up with a canonical
sentence describing resource, if there isn't one already. I see it as
being any thing that has a meaning. Which, is not much of a definition.

> * In the context of the discussions on the TAG list, is a URI-less
>   resource "part of the Web"?

A few years ago, resources without HTTP URIs would not have been
considered to be part of the web (barring FTP, Gopher proxies and what
not). Now, who knows? With RDF, presumably foo://your/mother is a
perfectly valid resource that's part of the semantic web, once the foo URI
scheme has been approved.

> * How, if at all, do the kind of unamed resources that Mark's talking
>   about here relate to RDFs anonymous nodes?

Someone who knows more about RDF please answer this :)

Michael







-----------------------------------------------------------------------------------
Post ID:2452
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-09 11:13:38
Subject:Re: [rest-discuss] Unamed resources? (WAS: what is state?)
Message:

Michael Day wrote,
> Miles Sabin wrote,
> > * Unnamed resources do away with the "only if", but is this a step
> > in the direction of doing away with the "if" too ... ie. if we can
> > have unnamed resources, why can't we also have names with no
> > resource? eg. http://www.example.com/nothing-here-folks.
>
> The only way to have a name without a resource is to have a randomly
> generated URI with no intended meaning whatsoever.

Did you try that example URI? If you think a 404 response is a resource, 
how about,

  http://this.host.does.not.exist.com/nothing-here-folks

The point at issue is whether or not we can treat resources as being 
defined in terms of URIs ... this is a coherent view, tho' not mine.
At the very least for that we need it to be the case that every resource 
has a URI, and that every URI has a resource (irrespective of whether 
or not there's a server prepared to return a useful representation). 
The possibility of unnamed resources is inconsistent with that view, 
clearly.

But the only good argument I've seen against the claim that particular 
URIs might be empty (have no resource, not name anything, etc., etc.) 
is that there's nothing more to being a resource than having a URI and 
that the existence of a corresponding resource is guaranteed by 
definition. IOW, the argument depends on the definition. But allowing 
unnamed resources means abandoning the definition, so we might as well 
be hung for a sheep as a lamb, and allow resourceless names too.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2453
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-09-09 11:24:34
Subject:Re: [rest-discuss] Unamed resources? (WAS: what is state?)
Message:

> Did you try that example URI? If you think a 404 response is a resource, 
> how about,
> 
>   http://this.host.does.not.exist.com/nothing-here-folks

A 404 response is not a resource. Nor is that URI a resource. The question
is whether it identifies a resource, or whether you just made it up
randomly to demonstrate a point. If you just made it up randomly, then the
URI does not identify a resource. (In my opinion. Again, it's a subtle
difference, because made up URIs can still identify resources, even the
this.host.does... etc. variety. But, made up URIs need not identify
resources. Perhaps a good example is John Smith of Number 42 High St,
which is an identifier for a resource (some guy). Also, Frodo Baggins of
Bag End, which is also an identifier for a resource, in this case a
fictional character, so it's not something that you can access directly
over HTTP. However FOOP!SQUIGGLE, which I just typed in randomly, is not a
resource, nor is Mr FOOP!SQUIGGLE of Number 42 High St, as this identifier
does not identify a resource to which I (nor anyone else) has assigned
meaning).

> The point at issue is whether or not we can treat resources as being 
> defined in terms of URIs ... this is a coherent view, tho' not mine.
> At the very least for that we need it to be the case that every resource 
> has a URI, and that every URI has a resource (irrespective of whether 
> or not there's a server prepared to return a useful representation). 
> The possibility of unnamed resources is inconsistent with that view, 
> clearly.

Not every URI identifies a resource, as the example you gave shows. Two
URIs may both return 404, and yet one identifies a resource (such as my
future news example) and one does not (such as your random URI example).  
Result of dereferencing does not indicate resourcefulness; the URI must
identify something which has been assigned meaning by someone (or some
process, in the case of programs generating/naming resources).

> But the only good argument I've seen against the claim that particular 
> URIs might be empty (have no resource, not name anything, etc., etc.) 
> is that there's nothing more to being a resource than having a URI and 
> that the existence of a corresponding resource is guaranteed by 
> definition. IOW, the argument depends on the definition. But allowing 
> unnamed resources means abandoning the definition, so we might as well 
> be hung for a sheep as a lamb, and allow resourceless names too.

Resourceless names are certainly possible, nameless resources will exist 
until we have a method to identify every possible resource, which may take 
a while.

Michael







-----------------------------------------------------------------------------------
Post ID:2454
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-09 12:00:15
Subject:Re: [rest-discuss] Unamed resources? (WAS: what is state?)
Message:

Michael Day wrote,
> Resourceless names are certainly possible, nameless resources will
> exist until we have a method to identify every possible resource,
> which may take a while.

OK, we agree on this. Not everyone does tho' ...

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2455
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-09 14:46:02
Subject:RE: [rest-discuss] Unamed resources?
Message:


> -----Original Message-----
> From: Miles Sabin [mailto:miles@...]
> Sent: Monday, September 09, 2002 3:47 AM
> To: rest-discuss
> Subject: [rest-discuss] Unamed resources? (WAS: what is state?)
> 
> 
> Mark Baker wrote,
> > If the data being transferred cannot be described as a 
> representation
> > of some (perhaps unnamed) resource, then you're not doing it right.
> 
> If resources can be nameless then we can't define "resource" 
> primarily 
> in terms of URIs ... ie. we can't say,
> 
>   X is a resource if and only if X is identified by some URI

Agreed that you can't say that.  But you might be able to say that
"X is a resource if and only if X *could be* identified by some
URI".  This is pretty broad, granted, but it's not quite vacuous.
For instance, "walking down the road" seems to me like something
that fails the predicate above.  Although there are extreme cases
that almost break the rule, remember that the purpose for a
resource to exist is to have state that we can communicate about.

> 
> I think that raises several interesting questions,
> 
> * Unnamed resources do away with the "only if", but is this a step in
>   the direction of doing away with the "if" too ... ie. if we can have
>   unnamed resources, why can't we also have names with no 
> resource? eg.
>   http://www.example.com/nothing-here-folks.

It's a funny property of namings that they always seem to bind to
some state.  Given that REST resources are conceptual, it's hard
to imagine naming something that can't be a resource.

> 
> * If having a URI isn't the criterion of resource-hood, then 
> what is? Is 
>   "resource" just an RFC 2396 compliant way of saying "thing"?

It says more than just "thing"; it says "thing with meaning", and
moreover, it says "thing with meaning that we can talk about all
day long and never change or directly touch the meaning itself".

> 
> * In the context of the discussions on the TAG list, is a URI-less
>   resource "part of the Web"?

I'd say if it's not connected, it's not part of the Web, and if
the URI is the only way to connect it, then ....

> 
> * How, if at all, do the kind of unamed resources that Mark's talking
>   about here relate to RDFs anonymous nodes?

Dunno!

Walden Mathews







-----------------------------------------------------------------------------------
Post ID:2456
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-09 14:48:29
Subject:RE: [rest-discuss] what is state?
Message:

It might be a good idea to realize that the web is evolving from
a web of documents into a web of concepts, any of which may at some
point be realized in the form of a document.  As it undergoes this
change, some of the legacy language will get in the way and harken
back to a simpler but less versatile time.  The description around
PUT in RFC 2616 seems to leave a little too little to the imagination.

Walden

> -----Original Message-----
> From: Matt Gushee [mailto:mgushee@...]
> Sent: Sunday, September 08, 2002 10:50 PM
> To: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] what is state?
> 
> 
> On Sun, Sep 08, 2002 at 10:26:59PM -0400, Mark Baker wrote:
> > On Sat, Sep 07, 2002 at 11:52:01PM -0400, Chuck Hinson wrote:
> > > I would argue the same holds for POST.  A POST request 
> transfers an 
> > > entity to the server.  I don't see any reason not to 
> consider that 
> > > entity a representation of some (perhaps unnamed) 
> resource. In fact, in 
> > > some cases, the representation that is transferred will 
> be GETable as a 
> > > named resource once it is submitted to the server.
> > 
> > Exactly.
> > 
> > If the data being transferred cannot be described as a 
> representation of
> > some (perhaps unnamed) resource, then you're not doing it right.
> 
> Hmm ...
> 
> On Sun, Sep 08, 2002 at 10:18:23PM -0400, Seairth Jacobs wrote:
> > 
> > I see nothing here saying that the request entity is a 
> representation.  All
> > that I see is a request entity that may replace or create a 
> new resource
> > identified by the request-URI.
> 
> This has always bothered me too. Unless I misunderstand the concept of
> 'representation' (which is perfectly possible--I haven't gotten around
> to reading Fielding's dissertation or other deep scholarly work on
> REST), the ability to PUT or POST a representation raises a serious
> issue which I have not seen addressed on this list.
> 
> What if a client PUTs a representation of a type that is 
> impractical to
> transform to the type of the existing resource? Doesn't that 
> effectively
> cripple the resource, upsetting the expectations of other clients? For
> example, suppose your resource is an SVG graphic--one of the most
> information-rich image formats, and one that can be transformed to any
> output format (known in this context as a representation, right?) you
> like. So your server might make available JPEG, PNG, and EPS
> representations of the image. Outbound, there's no problem. But now
> suppose somebody wants to PUT a JPEG to the URI? If you allow the put,
> then your information-rich SVG image is now degraded to a 
> dumb JPEG (I'm
> talking about what happens in the real world, not the MIT Media Lab),
> which not only contains less information than the old 
> resource, but may
> be impractical to transform to some of the representation 
> types that are
> supposed to be available.
> 
> So do you disallow certain types of representations from being PUT or 
> POSTed? That certainly seems like a practical response to the problem.
> But I would think that in a very large proportion of cases, you'd have
> to prohibit any type but the original type of the resource--in which
> case the distinction between resource and representation seems rather
> academic.
> 
> Or am I just confused?
> 
> -- 
> Matt Gushee
> Englewood, Colorado, USA
> mgushee@...
> http://www.havenrock.com/
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Looking for a more powerful website? Try GeoCities for $8.95 
> per month.
> Register your domain name (http://your-name.com). More 
> storage! No ads!
> http://geocities.yahoo.com/ps/info
> http://us.click.yahoo.com/aHOo4D/KJoEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2457
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-09 14:56:47
Subject:RE: [rest-discuss] Resources - when two are one
Message:


> -----Original Message-----
> From: Chuck Hinson [mailto:cmhinson@...]
> Sent: Sunday, September 08, 2002 1:37 AM
> To: S. Mike Dierken
> Cc: rest-discuss
> Subject: Re: [rest-discuss] Resources - when two are one
> 
> 
> 
> 
> S. Mike Dierken wrote:
> 
> >
> >>Second, I don't think you can make any sort of 
> generalization about what
> >>behavior or properties you might observe when two URIs name the same
> >>resource.
> >>
> >The point I'm making is that any claim that server.resource(uri1) ===
> >server.resource(uri2) is unverifiable and indistinguishable 
> from bogus
> >claims like server.resource("www.slashdot.net") ===
> >server.resource("www.microsoft.com")
> >
> >If you can't demonstrate any runtime effects of claming two 
> resources are
> >the same, then why make the claim?
> >
> In the general case I agree.  For two arbitrary URIs, I don't believe 
> there's any way to determine whether they identify the same 
> resource or not.
> 
> However, for a specific resource identified by two or more 
> URIs, I would 
> think that it might be possible to determine equivalence of 
> URIs.  The 
> rules for making that determination would, however, only be valid for 
> that specific resource and would probably require detailed 
> knowledge of 
> the resource for which URI equivalence was being tested.  
> 
> Hmm.  Having said all that, I'm beginning to think the best 
> you may be 
> able to do is to determine non-equivalence.
> 
> --Chuck

Determinations may be an individual thing.  For instance, I may
have determined that for my own use, Stop & Shop is equivalent to
Shop Rite.  However, other shoppers would not agree, nor would
the managements of these two different concerns.

If you're talking about some kind of authoritative determination
of equivalence among URI's, you have to appeal to the author, just
as you have to when you want to know the "real meaning" of a work
of art.  The naming authority picks the meanings and the symbols.
When you interact with a resource, you are playing by the author's
rules; period.

SO:

If you repeatedly GET two URIs and get back identical bit streams,
that does not make for authoritative equivalence.

If you repeatedly GET two URIs and get back utterly different bit
streams, nor does that make for authoritative unequivalence.

The equivalence of two URIs should mean one and only one thing:
that they may be used interchangeably with the guarantee that substitution
of one for the other yields the exact same result as no substitution.

One should also ponder whether it would ever be wise to have two
URI that are equivalent by design.

Walden






-----------------------------------------------------------------------------------
Post ID:2458
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-09 14:59:16
Subject:RE: [rest-discuss] Resources - when two are one
Message:

I think the only "runtime effect" you should be claiming is that
they are interchangeable symbols for the same concept.

Walden

> -----Original Message-----
> From: S. Mike Dierken [mailto:mdierken@...]
> Sent: Sunday, September 08, 2002 1:22 AM
> To: rest-discuss
> Subject: Re: [rest-discuss] Resources - when two are one
> 
> 
> 
> 
> >
> > Second, I don't think you can make any sort of 
> generalization about what
> > behavior or properties you might observe when two URIs name the same
> > resource.
> The point I'm making is that any claim that server.resource(uri1) ===
> server.resource(uri2) is unverifiable and indistinguishable from bogus
> claims like server.resource("www.slashdot.net") ===
> server.resource("www.microsoft.com")
> 
> If you can't demonstrate any runtime effects of claming two 
> resources are
> the same, then why make the claim?
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Looking for a more powerful website? Try GeoCities for $8.95 
> per month.
> Register your domain name (http://your-name.com). More 
> storage! No ads!
> http://geocities.yahoo.com/ps/info
> http://us.click.yahoo.com/aHOo4D/KJoEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2459
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-09 15:02:39
Subject:RE: [rest-discuss] Resources - when two are one
Message:

Chuck Hinson wrote:

> Second, I don't think you can make any sort of generalization 
> about what 
> behavior or properties you might observe when two URIs name the same 
> resource.  The characteristics of resources vary so greatly, that I 
> don't see that there would be any way to establish any kind 
> of generic 
> guarantee that would hold across all resources.  I'm sure 
> that for set 
> of simple cases you might be able to guarantee some sort of byte-wise 
> equivalence, but I don't see that happening across all types 
> of resources.

That's the way I see it, too.  If not for the variable characteristics,
guaranteed by the designed-in indirection between names and resource
and between resources and their representations, you could make some
claims about repeatable results with different URIs.  But the variability
is designed in, so you can't.

Walden






-----------------------------------------------------------------------------------
Post ID:2460
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-09 15:08:14
Subject:RE: [rest-discuss] Resources - when two are one
Message:


> -----Original Message-----
> From: S. Mike Dierken [mailto:mdierken@...]
> Sent: Saturday, September 07, 2002 3:01 PM
> To: rest-discuss
> Subject: Re: [rest-discuss] Resources - when two are one
> 
> 
> 
> ----- Original Message -----
> From: "Seairth Jacobs" <seairth@...>
> 
> > The point
> > I was making was that it's perfectly legitimate to have a 
> single resource
> > that returns different representations (where only the entity is
> different).
> > Therefore, you could not depend on content-type, 
> content-length, or the
> > entity body itself  (or any combination of them) to 
> confidently state
> > whether two URIs point to the same resource or not.
> 
> Right - so if we /did/ hold the accept-style headers constant 
> for requests
> against the two URIs, what logical guarantees can be made?
> If not for read-operations, what about write-operations?
> Will there be a guarantee that a write operation of some kind 
> against uri1
> has a visible effect when inspecting uri2?

The terminology is too direct for the architecture.  You can't "write
against
a URI".  You can transfer a representation to a resource behind a name.  The
great thing about resource modeling is the way it parallels people
management!
I can give you a hint, but I can't tell you what to do.

But if the URI are authoritatively equivalent, then you are addressing the
same resource no matter which URI you pick for a given request.  If you
only care about which resource you are addressing, then that should answer
your question.

Walden






-----------------------------------------------------------------------------------
Post ID:2461
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-09 15:12:36
Subject:RE: [rest-discuss] Resources - when two are one
Message:


> -----Original Message-----
> From: S. Mike Dierken [mailto:mdierken@...]
> Sent: Friday, September 06, 2002 5:28 PM
> To: Mathews, Walden; rest-discuss
> Subject: Re: [rest-discuss] Resources - when two are one
> 
> 
> 
> ----- Original Message -----
> From: "Mathews, Walden" <waldenm@...>
> 
> > >
> > > // are these true?
> > > assert(server.resource(uri1).body == content2.body);
> >
> > According to that weird 'PUT' rule, it would have to be :-(
> 
> I was assuming that the GET requests against the two 
> different URI (which
> are the 'same' resource) have the exact same headers.
> I wasn't relying on PUT's weird definition for the content to 
> be equivalent.
> I'm just trying to figure out /why/ they would be different.
> 

I think that except for the wierd 'PUT' rule, it's unsafe to make
any concrete assertions about the values returned by a GET, so trying
to set 'server.resource(uri1).body' equal to some pre-calculated
value is risky.  Mark's 'PUT' rule seems to override the otherwise
absolute rule that resources are not their representations.

Walden






-----------------------------------------------------------------------------------
Post ID:2462
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-09 15:52:55
Subject:Re: [rest-discuss] Unamed resources? (WAS: what is state?)
Message:

On Mon, Sep 09, 2002 at 08:47:13AM +0100, Miles Sabin wrote:
> Mark Baker wrote,
> > If the data being transferred cannot be described as a representation
> > of some (perhaps unnamed) resource, then you're not doing it right.
> 
> If resources can be nameless then we can't define "resource" primarily 
> in terms of URIs ... ie. we can't say,

I think that's a good thing.

>   X is a resource if and only if X is identified by some URI
> 
> I think that raises several interesting questions,
> 
> * Unnamed resources do away with the "only if", but is this a step in
>   the direction of doing away with the "if" too ... ie. if we can have
>   unnamed resources, why can't we also have names with no resource? eg.
>   http://www.example.com/nothing-here-folks.
> 
> * If having a URI isn't the criterion of resource-hood, then what is? Is 
>   "resource" just an RFC 2396 compliant way of saying "thing"?

Having identity.

> * In the context of the discussions on the TAG list, is a URI-less
>   resource "part of the Web"?

I thought about that for a bit, but decided that it wasn't really a
very interesting question, because the cost is zero for assigning a URI
to something that already has identity.  The easy answer would be "no",
but then you'd also have to ask yourself if maybe it did have a URI, but
you just don't know it.  Or, even if you don't know if it has a URI,
just assign your own.

> * How, if at all, do the kind of unamed resources that Mark's talking
>   about here relate to RDFs anonymous nodes?

A bNode is a good example of a resource with identity, but without a
(known) URI.  Of course, they could trivially be given one, and why
RDF doesn't do this, I have no idea.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2463
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-09 16:02:14
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

Mark,

I thought that I had the issue of Google allowing an strictly 
non-idempotent GET resolved in my mind, but a recent item on 
the tag list pointed out this:

    http://www.w3.org/2001/tag/doc/get7#obligations

I had been trying to argue - perhaps ineffectually - that the 
Developer's Key effects the notion of what "safety" means.  
The key is obtained through of an authorization relationship 
established in a way similar to that described in the "TAG Finding: 
URIs, Addressability, and the use of HTTP GET" document
referenced above.

I gave up on this line of reasoning because of your point 
about proxy cache refereshing.  

Do you think that your point effects the findings described 
in that TAG document?  Or do you not think that the way
Google is setup falls under this notion of "obligation"?

Thanks,

- Jeff







-----------------------------------------------------------------------------------
Post ID:2464
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-09 16:18:35
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

Yah, I'm following that too, and admit to being a bit puzzled by Dan's
response and the finding.  I think each request has to stand alone in
its status as state-changing or not, for all the reasons I gave.

I'll see how the discussion, if any, goes, before chiming in.  Dan's a
smart guy, so you better make sure your ducks are lined up before
challenging him. 8-)

MB

On Mon, Sep 09, 2002 at 12:02:14PM -0400, Jeffrey Winter wrote:
> Mark,
> 
> I thought that I had the issue of Google allowing an strictly 
> non-idempotent GET resolved in my mind, but a recent item on 
> the tag list pointed out this:
> 
>     http://www.w3.org/2001/tag/doc/get7#obligations
> 
> I had been trying to argue - perhaps ineffectually - that the 
> Developer's Key effects the notion of what "safety" means.  
> The key is obtained through of an authorization relationship 
> established in a way similar to that described in the "TAG Finding: 
> URIs, Addressability, and the use of HTTP GET" document
> referenced above.
> 
> I gave up on this line of reasoning because of your point 
> about proxy cache refereshing.  
> 
> Do you think that your point effects the findings described 
> in that TAG document?  Or do you not think that the way
> Google is setup falls under this notion of "obligation"?
> 
> Thanks,
> 
> - Jeff
> 

-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2465
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-09 16:38:04
Subject:Things, with and without identity? (WAS: Unamed resources?)
Message:

Mark Baker wrote,
> On Mon, Sep 09, 2002 at 08:47:13AM +0100, Miles Sabin wrote:
> > * If having a URI isn't the criterion of resource-hood, then what
> > is? Is "resource" just an RFC 2396 compliant way of saying "thing"?
>
> Having identity.

I'm heartily sick of this "having identity" nonsense ;-)

If tacking "having identity" onto the end of "thing" isn't completely 
redundant, then presumably it also makes sense to talk about things 
which *don't* have identity ... except of course that it doesn't, or at 
any rate it hasn't seemed attractive since Parmenides, Heraclitus and 
Hegel went out of fashion. At least starting with Frege,

  (Vx)(x = x)

has been taken as a logical truth. IOW, *everything* has identity. Or to 
quote Quine, "No entity without identity".

Seeing as RFC 2396 is coming up for revision I think now would be a good 
time to get rid of this silliness once and for all.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2466
Sender:Dan Brickley <danbri@...>
Post Date/Time:2002-09-09 16:44:46
Subject:Re: [rest-discuss] Things, with and without identity? (WAS: Unamed resources?)
Message:

+1, heartily

On Mon, 9 Sep 2002, Miles Sabin wrote:

> Mark Baker wrote,
> > On Mon, Sep 09, 2002 at 08:47:13AM +0100, Miles Sabin wrote:
> > > * If having a URI isn't the criterion of resource-hood, then what
> > > is? Is "resource" just an RFC 2396 compliant way of saying "thing"?
> >
> > Having identity.
>
> I'm heartily sick of this "having identity" nonsense ;-)
>
> If tacking "having identity" onto the end of "thing" isn't completely
> redundant, then presumably it also makes sense to talk about things
> which *don't* have identity ... except of course that it doesn't, or at
> any rate it hasn't seemed attractive since Parmenides, Heraclitus and
> Hegel went out of fashion. At least starting with Frege,
>
>   (Vx)(x = x)
>
> has been taken as a logical truth. IOW, *everything* has identity. Or to
> quote Quine, "No entity without identity".
>
> Seeing as RFC 2396 is coming up for revision I think now would be a good
> time to get rid of this silliness once and for all.
>
> Cheers,
>
>
> Miles
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:2467
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-09 16:55:03
Subject:Re: [rest-discuss] Things, with and without identity? (WAS: Unamed resources?)
Message:

On Mon, Sep 09, 2002 at 05:38:04PM +0100, Miles Sabin wrote:
> Mark Baker wrote,
> > On Mon, Sep 09, 2002 at 08:47:13AM +0100, Miles Sabin wrote:
> > > * If having a URI isn't the criterion of resource-hood, then what
> > > is? Is "resource" just an RFC 2396 compliant way of saying "thing"?
> >
> > Having identity.
> 
> I'm heartily sick of this "having identity" nonsense ;-)
> 
> If tacking "having identity" onto the end of "thing" isn't completely 
> redundant,

It is most definitely redundant.

> Seeing as RFC 2396 is coming up for revision I think now would be a good 
> time to get rid of this silliness once and for all.

I think it's quite clear when it says;

"A resource can be anything that has identity."

It doesn't say that resources have to have URIs, only that they have to
have identity.  But of course, anything with identity can have a URI.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2468
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-09 17:11:58
Subject:Re: [rest-discuss] Things, with and without identity? (WAS: Unamed resources?)
Message:

Mark Baker wrote,
> On Mon, Sep 09, 2002 at 05:38:04PM +0100, Miles Sabin wrote:
> > Mark Baker wrote,
> >
> > > On Mon, Sep 09, 2002 at 08:47:13AM +0100, Miles Sabin wrote:
> > > > * If having a URI isn't the criterion of resource-hood, then
> > > > what is? Is "resource" just an RFC 2396 compliant way of saying
> > > > "thing"?
> > >
> > > Having identity.
> >
> > I'm heartily sick of this "having identity" nonsense ;-)
> >
> > If tacking "having identity" onto the end of "thing" isn't
> > completely redundant,
>
> It is most definitely redundant.

Then what was the point of your response to my original question?

> > Seeing as RFC 2396 is coming up for revision I think now would be a
> > good time to get rid of this silliness once and for all.
>
> I think it's quite clear when it says;
>
> "A resource can be anything that has identity."
>
> It doesn't say that resources have to have URIs,

I agree, tho' FWIW I'm sure that lots of people have read this as,

  A resource can be anything that has an identifier (ie. a URI).

or,

  A resource can be anything that can be identified (ie. be picked out
  effectively).

> only that they have to have identity.  But of course, anything with
> identity can have a URI.

Sure, but what's the point of the the "with identity"? Any *thing*, 
period, can have an identifier: "with identity" is completely redundant 
as you've just agreed.

The RFC 2396 text is misleading, because it suggests that the potential 
resources are a *proper* subset of the set of things, the proper subset 
which has identity as opposed to the subset which doesn't. That's close 
to gibberish IMO.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2469
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-09 17:33:25
Subject:Re: [rest-discuss] Things, with and without identity? (WAS: Unamed resources?)
Message:

On Mon, Sep 09, 2002 at 06:11:58PM +0100, Miles Sabin wrote:
> > It is most definitely redundant.
> 
> Then what was the point of your response to my original question?

'cause you asked! 8-O

> I agree, tho' FWIW I'm sure that lots of people have read this as,
> 
>   A resource can be anything that has an identifier (ie. a URI).
> 
> or,
> 
>   A resource can be anything that can be identified (ie. be picked out
>   effectively).
> 
> > only that they have to have identity.  But of course, anything with
> > identity can have a URI.
> 
> Sure, but what's the point of the the "with identity"? Any *thing*, 
> period, can have an identifier: "with identity" is completely redundant 
> as you've just agreed.

IMO, it's just clearer language.

> The RFC 2396 text is misleading, because it suggests that the potential 
> resources are a *proper* subset of the set of things, the proper subset 
> which has identity as opposed to the subset which doesn't. That's close 
> to gibberish IMO.

I wouldn't say that.  It's just saying the same thing twice, since to
only say it once would look odd, ala "a resource can be anything"(?!).

Followups to uri@..., I suggest.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2470
Sender:Dan Brickley <danbri@...>
Post Date/Time:2002-09-09 17:43:07
Subject:Re: [rest-discuss] Things, with and without identity? (WAS: Unamed resources?)
Message:

On Mon, 9 Sep 2002, Mark Baker wrote:
> On Mon, Sep 09, 2002 at 06:11:58PM +0100, Miles Sabin wrote:
> > The RFC 2396 text is misleading, because it suggests that the potential
> > resources are a *proper* subset of the set of things, the proper subset
> > which has identity as opposed to the subset which doesn't. That's close
> > to gibberish IMO.
>
> I wouldn't say that.  It's just saying the same thing twice, since to
> only say it once would look odd, ala "a resource can be anything"(?!).

In RDF circles, the phrase 'a resource can be anything with identity' has
often been taken to suggest that there might be some non-Resource things,
which has led to much time wasted in trying to figure out what those are,
how we identify them, etc etc.

> Followups to uri@..., I suggest.

(didn't seem worth doing that for my followup...)

Dan


-- 
mailto:danbri@...
http://www.w3.org/People/DanBri/







-----------------------------------------------------------------------------------
Post ID:2471
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-09-09 18:02:57
Subject:Re: Things, with and without identity? (WAS: Unamed resources?)
Message:

Miles, 

When you say:

> Sure, but what's the point of the the "with identity"? Any 
>*thing*,  period, can have an identifier

This is a meaningless statement. As soon as you've stated **that 
thing** you've identified it. 

What you might be asking is whether there are concepts and 
abstractions which cannot be universally and uniquely addressed. 
Most likely there are. For example, it makes sense for a specific 
person to have a URI but you can't really assign a URI to the 
concept of 'people'. (And if you do, it's guaranteed not everybody 
will agree that your URI addresses the 'people' resource since 
everybody has different notions of what the 'people' resource might 
constitute). Or can you assign URIs to emotions like 'happy' 
and 'jealous'? Again you can, but these URIs no longer have the same 
edge of universality as a URI that addresses yahoo's webpage or your 
mailbox.

The point is resources aren't meant to be super-historical entities 
though there are many people who believe such super-historical 
entities exist. The word 'identity' implies a certain physicality 
and concreteness which jives well with REST because ultimately it 
comes down to executing methods against objects that exist on a 
network. 

Anyways I doubt anybody is really mislead by the "with identity" 
part unless they've already worked into a confusing, never-ending 
spiral of tautology and assumption while trying to decide what 
constitutes a resource.

- itdp



--- In rest-discuss@y..., Miles Sabin <miles@m...> wrote:
> Mark Baker wrote,
> > On Mon, Sep 09, 2002 at 05:38:04PM +0100, Miles Sabin wrote:
> > > Mark Baker wrote,
> > >
> > > > On Mon, Sep 09, 2002 at 08:47:13AM +0100, Miles Sabin wrote:
> > > > > * If having a URI isn't the criterion of resource-hood, 
then
> > > > > what is? Is "resource" just an RFC 2396 compliant way of 
saying
> > > > > "thing"?
> > > >
> > > > Having identity.
> > >
> > > I'm heartily sick of this "having identity" nonsense ;-)
> > >
> > > If tacking "having identity" onto the end of "thing" isn't
> > > completely redundant,
> >
> > It is most definitely redundant.
> 
> Then what was the point of your response to my original question?
> 
> > > Seeing as RFC 2396 is coming up for revision I think now would 
be a
> > > good time to get rid of this silliness once and for all.
> >
> > I think it's quite clear when it says;
> >
> > "A resource can be anything that has identity."
> >
> > It doesn't say that resources have to have URIs,
> 
> I agree, tho' FWIW I'm sure that lots of people have read this as,
> 
>   A resource can be anything that has an identifier (ie. a URI).
> 
> or,
> 
>   A resource can be anything that can be identified (ie. be picked 
out
>   effectively).
> 
> > only that they have to have identity.  But of course, anything 
with
> > identity can have a URI.
> 
> Sure, but what's the point of the the "with identity"? Any 
*thing*, 
> period, can have an identifier: "with identity" is completely 
redundant 
> as you've just agreed.
> 
> The RFC 2396 text is misleading, because it suggests that the 
potential 
> resources are a *proper* subset of the set of things, the proper 
subset 
> which has identity as opposed to the subset which doesn't. That's 
close 
> to gibberish IMO.
> 
> Cheers,
> 
> 
> Miles







-----------------------------------------------------------------------------------
Post ID:2472
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-09 18:22:04
Subject:Re: [rest-discuss] Re: Things, with and without identity? (WAS: Unamed resources?)
Message:

inthedarkplace wrote,
> When you say:
> > Sure, but what's the point of the the "with identity"? Any
> >*thing*,  period, can have an identifier
>
> This is a meaningless statement. As soon as you've stated **that
> thing** you've identified it.

You're confusing identity with identification. Someone will be the first 
person to call me on the phone tomorrow, I've no idea who (ie. I 
couldn't identify them), but whoever it will be is (and always was and 
will be) a satisifer of x = x. That's all identity is, nothing more, 
nothing less.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2473
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-09 19:35:33
Subject:Re: [rest-discuss] Re: Things, with and without identity? (WAS: Unamed resources?)
Message:


Miles Sabin wrote:

>inthedarkplace wrote,
>
>>When you say:
>>
>>>Sure, but what's the point of the the "with identity"? Any
>>>*thing*,  period, can have an identifier
>>>
>>This is a meaningless statement. As soon as you've stated **that
>>thing** you've identified it.
>>
>
>You're confusing identity with identification. Someone will be the first 
>person to call me on the phone tomorrow, I've no idea who (ie. I 
>couldn't identify them), but whoever it will be is (and always was and 
>will be) a satisifer of x = x. That's all identity is, nothing more, 
>nothing less.
>
Hmm. Seems like different people are operating with different (pefrectly 
valid) definitions for the word identity:

   1. The collective aspect of the set of characteristics by which a
      thing is definitively recognizable or known: ?If the broadcast
      group is the financial guts of the company, the news division is
      its public identity? (Bill Powell).
   2. The set of behavioral or personal characteristics by which an
      individual is recognizable as a member of a group.
   3. The quality or condition of being the same as something else.
   4. _/Mathematics./_
         1. An equation that is satisfied by any number that replaces
            the letter for which the equation is defined.
         2. Identity element.


Personally, I think of 1. when seeing the word. It would appear that 
others may be thinking more in terms of 4.

I'll not argue which should be used.

--Chuck













-----------------------------------------------------------------------------------
Post ID:2474
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-09 19:43:20
Subject:Re: [rest-discuss] Resources vs. Representations
Message:

On Fri, Sep 06, 2002 at 01:31:53PM -0400, Mathews, Walden wrote:
> > Hmm, what asymmetry?
> 
> X says "see Y", but Y doesn't say "see X", so it's asymmetric.

Ok.

Also, I don't know why this just occurred to me, but clearly 301,
in addition to meaning "equivalent" (I think), also means "and I'm
going away" too.  So it's most definitely not the same as
daml:equivalentTo.  Duh.

I expect that equivalence would best be expressed as a response header
rather than a response code.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2475
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-09 19:48:04
Subject:Re: [rest-discuss] Re: Things, with and without identity? (WAS: Unamed resources?)
Message:

Chuck Hinson wrote,
> Hmm. Seems like different people are operating with different
> (pefrectly valid) definitions for the word identity:
>
>    1. The collective aspect of the set of characteristics by which a
>       thing is definitively recognizable or known: ?If the broadcast
>       group is the financial guts of the company, the news division
>       is its public identity? (Bill Powell).
>    2. The set of behavioral or personal characteristics by which an
>       individual is recognizable as a member of a group.

Yup, this is one way of understanding the concept of identity. I guess 
you could call it the social or psychological sense.

>    3. The quality or condition of being the same as something else.
>    4. _/Mathematics./_
>          1. An equation that is satisfied by any number that replaces
>             the letter for which the equation is defined.
>          2. Identity element.

Call this the logical sense.

These two are pretty much equivalent. An equation states that the 
expression on the LHS of an '=' picks out the same entity as the 
expression on the RHS. An identity element is an element which supports 
a particular class of equations, eg. 0 and 1 in x+0 = x and x*1 = x.

FWIW, I think the logical sense is the only sensible option (if nothing 
else because in the social/psychological sense things can have multiple 
identities, which would be much too confusing to be useful here).

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2476
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-09 19:56:22
Subject:Re: [rest-discuss] Re: Things, with and without identity? (WAS: Unamed resources?)
Message:

I wrote,
<snip/>
> I guess you could call it the social or psychological sense.

<snip/>

> Call this the logical sense.
>
> These two are pretty much equivalent.

I didn't mean that quite the way it sounded ;-)

What I _actually_ meant was that Chucks (3) and (4) are pretty much 
equivalent, *not* that the social and logical senses of identity are 
equivalent.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2477
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-09-09 19:59:55
Subject:Re: Resources vs. Representations
Message:

I thinked "equivalence" (as if that's really a meaningful word) can 
best be expressed by returning HTTP 303 SeeOther. This doesn't carry 
the connotations of expiration carried by the HTTP 301 Moved but it 
makes it clear what the client wants is to be found at another 
place. In reality, I believe all of the 3xx codes express 
equivalence because the client MUST follow the redirect--if the 
client fails to follow it then she can make no inferrences about the 
nature of the resource located at the original URI that caused the 
redirect. 

- itdp
 
--- In rest-discuss@y..., Mark Baker <distobj@a...> wrote:
> On Fri, Sep 06, 2002 at 01:31:53PM -0400, Mathews, Walden wrote:
> > > Hmm, what asymmetry?
> > 
> > X says "see Y", but Y doesn't say "see X", so it's asymmetric.
> 
> Ok.
> 
> Also, I don't know why this just occurred to me, but clearly 301,
> in addition to meaning "equivalent" (I think), also means "and I'm
> going away" too.  So it's most definitely not the same as
> daml:equivalentTo.  Duh.
> 
> I expect that equivalence would best be expressed as a response 
header
> rather than a response code.
> 
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@a...
> http://www.markbaker.ca        http://www.idokorro.com







-----------------------------------------------------------------------------------
Post ID:2478
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-09 21:50:02
Subject:Shameless plug
Message:

My current company is closing its doors today - the thundering silence in
the sales dept (in which there were no actual employees... - a possible
problem...) got too loud to ignore.

Which means I am available for freelance contracting in the near term.
So if anybody has a strong need for a crack Web architect (in the Seattle
area), send me some mail and let's see what we can do.

Mike






-----------------------------------------------------------------------------------
Post ID:2479
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-09-09 23:03:19
Subject:Resources
Message:

The recent discussion about unnamed resources and the implications of URIs 
and identity has been very interesting, but given that we are trying to 
resolve this in a REST context rather than a URI or RDF context, how about 
we stick to the following definition of resource:

"A thing with meaning that has been assigned (or will be assigned?) a HTTP
or HTTPS URI."

A lot of the resources I've been thinking about are completely useless
from a REST perspective; for example urn:isbn:123-456 might identify a
resource, namely a book (in the abstract, not any particular copy). And
yet, what good is it? Handy for RDF, but it's not HTTP addressable so 
there is not much to say about it in a REST context.

Any thoughts?

Michael







-----------------------------------------------------------------------------------
Post ID:2480
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-09 23:17:42
Subject:Re: Possible new issue: Things with and without identity?
Message:

Stephen Cranefield wrote,
> Miles Sabin <miles@...> wrote:
> > At issue is the first sentence of the informal definition of
> > resource in RFC 2396 1.1,
> >
> >   A resource can be anything that has identity.
> >
> > "that has identity" is redundant because *everything* has identity
> > in the only reasonably straightforward understanding of identity,
> > ie. the logical truth in all but the most obscure formal systems
> > that,
> >
> >   (Vx) x = x
>
> A discussion of the philosophical notion of identity can be found in:
>
> Guarino, Nicola and Chris Welty. 2000. Identity, Unity, and
> Individuality: Towards a formal toolkit for ontological analysis. In,
> Horn, W. ed., Proceedings of ECAI-2000: The European Conference on
> Artificial Intelligence. pp. 219-223. Berlin: IOS Press. August, 2000
> http://www.ladseb.pd.cnr.it/infor/Ontology/Papers/LADSEB02-2000.pdf

It's an interesting enough paper, but it's about unity, integrity and 
persistence of physical objects rather than identity. And that's a good 
thing, because their theory appears to be expressed in terms of 
first-order predicate calculus with identity initially, then later a 
simple first-order mereology and set theory, both of which presuppose 
identity: so if it really was supposed to be a theory of identity it'd 
be hopelessly circular. There are formal systems around which don't 
take identity as a primitive, but, like I said, they're somewhat 
obscure.

That said, if the qualifier in RFC 2396 said something like,

  A resource can be anything that is integrated (for some value of
  "integrated")

it would at least be adding something non-trivial. But I'd strongly 
advise against going down that route. Integrity is a slippery enough 
concept for physical objects (eg. it's extremely difficult to 
distinguish is-attached-to from is-part-of without running into all 
kinds of awkward edge cases) never mind the kind of electronic 
artifacts which are RFC 2396's primary (tho' maybe not exclusive) 
concern.

There's also a brief discussion of the relation between stuffs and 
things, but that's irrelevant here: RFC 2396 talks about things from 
the outset, so individuation is already presupposed.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2481
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-09 23:29:27
Subject:Re: [rest-discuss] Resources
Message:

Michael Day wrote,
> A lot of the resources I've been thinking about are completely
> useless from a REST perspective; for example urn:isbn:123-456 might
> identify a resource, namely a book (in the abstract, not any
> particular copy). And yet, what good is it? Handy for RDF, but it's
> not HTTP addressable so there is not much to say about it in a REST
> context.

There's a perfectly good URI resolution mechanism built on top of DNS,

  http://www.uri.net/

All that's missing is clients.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2482
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-09 23:47:36
Subject:Re: [rest-discuss] Resources
Message:

----- Original Message ----- 
From: "Michael Day" <mikeday@...>
To: <rest-discuss@yahoogroups.com>
Sent: Monday, September 09, 2002 4:03 PM
Subject: [rest-discuss] Resources


> 

> 
> A lot of the resources I've been thinking about are completely useless
> from a REST perspective; for example urn:isbn:123-456 might identify a
> resource, namely a book (in the abstract, not any particular copy). 
In theory REST is not limited to HTTP - but in practice it usually is.

> And
> yet, what good is it? Handy for RDF, but it's not HTTP addressable so 
> there is not much to say about it in a REST context.
Well... you technically /can/ de-reference non http URI via HTTP.

GET urn:isbn:123-456 HTTP/1.1
Host: www.library-of-congress.gov









-----------------------------------------------------------------------------------
Post ID:2483
Sender:Stephen Cranefield <scranefield@...>
Post Date/Time:2002-09-09 22:14:01
Subject:Re: Possible new issue: Things with and without identity?
Message:

Miles Sabin <miles@...> wrote:
> At issue is the first sentence of the informal definition of resource in 
> RFC 2396 1.1,
> 
>   A resource can be anything that has identity.
> 
> "that has identity" is redundant because *everything* has identity in 
> the only reasonably straightforward understanding of identity, ie. the 
> logical truth in all but the most obscure formal systems that,
> 
>   (Vx) x = x

A discussion of the philosophical notion of identity can be found in:

Guarino, Nicola and Chris Welty. 2000. Identity, Unity, and
Individuality: Towards a formal toolkit for ontological analysis. In,
Horn, W. ed., Proceedings of ECAI-2000: The European Conference on
Artificial Intelligence. pp. 219-223. Berlin: IOS Press. August, 2000
http://www.ladseb.pd.cnr.it/infor/Ontology/Papers/LADSEB02-2000.pdf

More pragmatically, a distinction between things with and things
without identity should be quite familiar to Java programmers.  You
can distinguish between two instances of the String class that happen
to have the same content, but you can't distinguish between two
occurrences of the int value 7.  Unless you consider that a literal is
not a "thing", you have to allow for there to be things that don't
have identity.

I have argued that ontology modelling languages need to be able to
declare which concepts have identity (and thus correspond to
resources) and which represent structured "value types" without
identity.  See the following paper for a discussion of this in the
context of ontology modelling using UML:

Stephen Cranefield and Martin Purvis
A UML profile and mapping for the generation of ontology-specific
content languages
Knowledge Engineering Review, 17(1) 2002
Pages 21-39

- Stephen








-----------------------------------------------------------------------------------
Post ID:2484
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-10 01:20:27
Subject:Re: Possible new issue: Things with and without identity?
Message:

Al Gilman wrote,
> At 07:17 PM 2002-09-09, Miles Sabin wrote:
> >There's also a brief discussion of the relation between stuffs and
> >things, but that's irrelevant here: RFC 2396 talks about things from
> >the outset, so individuation is already presupposed.
>
> Yes, but erroneously so.  This language in RFC 2396 was heuristic,
> and the idea that individuation and a persistent referenceable
> identity are intrinsic and universal in the Web, while central to the
> thinking of some people, did not at that time nor at this one reflect
> a globally valid interpretation of all the uses of URIs.

I must admit I'm a bit taken aback by this response, however ...

> And the distinction between things and stuffs is not at all
> irrelevant to building a reasonable engineering foundation for
> semantics for the Web.
>
> On the web we need to be able to refer to both stuffs and things.

... even tho' I don't have any particular metaphysical scruples when it 
comes to stuffs and substances, I'm afraid I simply don't buy this. 
Stuffs probably have a useful place somewhere, but I think not here.

> We just discovered we needed to factor ACSS into perturbations of the
> text-to-speech transform, which is analogous to font characteristic
> manipulation, and sonicons that are used as punctuation for phrasal
> elements. Analogous to quotation marks and other punctuation which
> appear in the final stream as characters but this is because these
> controls are of such antiquity that there are standard glyphic
> characters for them.
>
> The moral here is that this points straight at a distinction between
> text and fills, which are styled as stuffs, and list elements and
> paragraphs and such, which are styled as things.
>
> If we comprehend this distinction at the outset, it would make the
> whole job of characterizing styling a lot easier, and the result more
> like natural language semantics.

Why are fills stuffs? Sure, I fill my pies with apple (apple-stuff, not 
individual apples), but text is nothing like a pie. This is a physical 
analogy too far: surely text-fills are properties. That gets you a 
categorical distinction between text and fill ... but a different one.

> In particular, for my dump on how regarding a search URL as a
> reference to an identity is spurious, see
>
>   http://lists.w3.org/Archives/Public/www-talk/2001NovDec/0058.html
>
> It is just much more direct to view a search URL as subclassing a
> stuff and the server as returning references to things that exemplify
> the stuff that the user's URL described.

I have no idea what "subclassing a stuff" could possibly mean. I do 
understand types and subtypes tho'. And I've no idea how a thing 
"exemplifies" a stuff. A thing might exemplify (I'd prefer instantiate) 
a property, but it's _made_ of stuff ... and that's a different kind of 
relationship altogether.

Are we talking at cross-purposes? Do you mean by stuff what I mean by 
property?

> The data of the 'dark Web' is more practical to approach as stuff
> typed by tuples of properties than as entified things. Or at least
> that view matches application semantics better.
>
>   http://lists.w3.org/Archives/Public/uri/2000Apr/thread.html#18

I can't see anything there which directly relates to this thread. Could 
you give me an example?

I can certainly see a case for properties having first class status on 
the web, and I have no problem with properties counting as resources 
and having URIs. You'd need, in effect a second-order version of,

  A resource can be anything that has identity.

but it's also true that in almost all second-order systems,

  (VX)(X = X)

(ie. a second-order quantifier ranging over properties) is either an 
axiom or a theorem, so "that has identity" is _still_ redundant.

I can't see any immediate role for stuffs tho', and the fact that 
there's no well worked out formal theory of stuffs doesn't help either.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2485
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-09-10 03:35:00
Subject:Re: [rest-discuss] Resources
Message:

> Well... you technically /can/ de-reference non http URI via HTTP.
> 
> GET urn:isbn:123-456 HTTP/1.1
> Host: www.library-of-congress.gov

My goodness. That never occurred to me :)

In that case, what I was ineffectually grasping for was that while you can
operate on a resource identified by a non-HTTP URI over HTTP, how will you
know which server to go to? But I think the link to "Dynamic Delegation
Discovery System" Miles Sabin just posted is probably an answer to that.  
So, no further questions :)

Michael







-----------------------------------------------------------------------------------
Post ID:2486
Sender:"firepipe_au" <michael@...>
Post Date/Time:2002-09-10 04:34:52
Subject:resources and identity
Message:

all this discussion about state and identity has been really great.  
I've regularly been running off to my philosophy and maths books (and 
my dictionary half the time, too) to try to figure out what some of 
the more educated folks on this list are saying.

Responding to some of the thoughts, I came up with a physical 
analogy:  some of the physicists around the joint have come up with a 
way to teleport a laser beam across a room.  They shine the beam into 
a detector, which translates the beam's 'entangled' photons into a 
radio signal, beam /that/ across the room, and use it to reconstruct 
the 'original' beam.  Problem is, the original beam is destroyed in 
the process.  I personally think this is a little bogus, because it 
isn't the original beam that comes out the other end, just a 'copy'.

I thought this was great at describing the way you can't get a 
resource, only a representation.  But it's WRONG.

I thought of internet-connected fridges and air-conditioners

GET www.my-airconditioner.net/bedroom/temperature HTTP/1.1

->  24 degrees C

POST www.my-airconditioner.net/bedroom/temperature HTTP/1.1
Content-type: text/xml

<new-temperature>19</new-temperature>

-> 200 OK
(a bit more comfortable)

Does that make my air conditioner a resource?  I really couldn't 
tell.  So I went to the source, and read 5.2.2.1-2 of Roy's 
dissertation over and over.  And got confused.

<quote>Any information that can be named can be a resource: a 
document or image, a temporal service (e.g. "today's weather in Los 
Angeles"), a collection of other resources, a non-virtual object 
(e.g. a person), and so on</quote>

That means it is possible that the air conditioner /could be/ a 
resource, by Roy's use of the word 'can', and inclusion of non-
virtual objects. No?

<quote>In other words, any concept that might be the target of an 
author's hypertext reference must fit within the definition of a 
resource</quote>

What?  That means my air conditioner isn't a resource, because I 
can't reference it through hypertext (HTTP).  It does have a 
temperature function, however, that I can reference.  Does the 
presence of the temperature function as part of the air conditioner 
make the air conditioner a resource?

<quote>A resource is a conceptual mapping to a set of entities, not 
the entity that corresponds to the mapping at any particular point in 
time  More precisely, a resource R is a temporally varying membership 
function M<sub>R</sub>(t), which for time t maps to a set of 
entities, or values, which are equivalent. The values in the set may 
be resource representations and/or resource identifiers</quote>

Ah, the resource is nothing I can ever get my hands on.  The resource 
is the 'concept' that maps to reporting/changing temperature in my 
bedroom (and/or humidity, if my air conditioner was fancy enough).  
So the air conditioner itself, the physical, plastic reality of the 
thing, is not a resource.  But by the act of mapping some of its 
functions as URIs, it becomes conceptually a resource, providing 
representations of its functions.  Additionally, the functions of 
temperature and humidity, though subordinate to the air conditioner, 
because they are both concepts that map to one or more 
representations (change temperature, report temperature).

So now I see it is /both/.  It is the act of performing the mapping 
that makes a resource, in the context of REST.  This makes my PUT 
above a representation, but not a resource, because I am not defining 
the mapping, I am using it.

In a similar vein, just because I can identify my air conditioner, 
doesn't mean that it has identity /in the context of REST/.  It is 
only the representations of its functions that it provides as URIs 
that have any identity /in the context of REST/.

I keep repeating that about context, because I keep losing it in the 
discussion.

However, at this moment, I am basking in extraordinary clarity. I can 
see a way ahead to do something practical.

1) Define a resource, conceptually
2) Define representations of that resource
3) Map one URI to each representation - two representations being 
equivalent at some time does not confuse the issue, they are 
representations I have chosen to present.
4) Give the URIs to others to play with  :-)


A note:
Reading RFC 2068 Section 9.6 on PUT, I see a lot of stuff about 
PUTting resources, not representations.  I think this means to me, in 
the light of what is above, that put /creates/ resources while, ie 
the conceptual mapping of some thing/function, and its associated 
representations.  A PUT to

http://www.myairconditioner.net/time

may add a 'time' component (also a resource in its own right, in lieu 
of the fact that it provides one or more representations) that allows 
me to GET the time, or POST a time if it's wrong.  This is seen to 
have a dual purpose: while the conceptual framework of the air 
conditioner (a resource) is /modified/ by the PUT, the conceptual 
framework of the time functions (also a resource) is /created/.

Roy says I can't GET the time functions that I just PUT, though, 
because you can't GET resources.  I can, however, GET a 
representation which seems to me like a fine compromise - the RFC 
says nothing about GETting back what you put, so that's OK (an indeed 
necessary by definition of a resource).

In a Java/Tomcat context, this also means that I am PUTting Java 
class files the place I specify, creating a new 'context' in my 
server configuration file, and running the manager program to start 
that context up within the Tomcat container.  I don't see any problem 
with this except in regards to security.

Michael








-----------------------------------------------------------------------------------
Post ID:2487
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-10 05:34:38
Subject:Re: [rest-discuss] Resources
Message:

----- Original Message -----
From: "Michael Day" <mikeday@...>

> > Well... you technically /can/ de-reference non http URI via HTTP.
> >
> > GET urn:isbn:123-456 HTTP/1.1
> > Host: www.library-of-congress.gov
>
> My goodness. That never occurred to me :)
>
> In that case, what I was ineffectually grasping for was that while you can
> operate on a resource identified by a non-HTTP URI over HTTP, how will you
> know which server to go to?
That and a million dollars of VC funding will get you my answer...







-----------------------------------------------------------------------------------
Post ID:2488
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-09-10 05:38:40
Subject:Re: [rest-discuss] Resources
Message:

> That and a million dollars of VC funding will get you my answer...

How enigmatic :) Can't say I like the implementation of DDDS, given that I
don't particularly appreciate the implementation of DNS. Has the topic of
DNS reimplemented over HTTP requests to known server IPs, acting as proxy
caches to root HTTP domain name servers been covered on this list? It
would be fun to reimplement DNS and cover generic URI/URN resolving at
once. (Not that the world would rush to adopt it or anything; you'd spend
your million dollars on marketing and bribery, not development...)

Michael







-----------------------------------------------------------------------------------
Post ID:2489
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-10 05:39:30
Subject:Re: [rest-discuss] Resources
Message:


Michael Day wrote:

>The recent discussion about unnamed resources and the implications of URIs 
>and identity has been very interesting, but given that we are trying to 
>resolve this in a REST context rather than a URI or RDF context, how about 
>we stick to the following definition of resource:
>
>"A thing with meaning that has been assigned (or will be assigned?) a HTTP
>or HTTPS URI."
>
Because there is no requirement that a resource be assigned a URI.

REST is about (among other things) the transfer of representations of 
resources.

Representations can be transferred in both requests and responses.

A POST request transfers a representation to the server to be processed 
by the resource identified by the request.

It's kind of hard to have a representation if there's no resource 
(however temporary or unreferencable that resource might be).


Here's a snippet from Fielding's _Principled design of the modern Web 
Architecture_ :
<snippet>
Depending on the message control data, a given representation may 
indicate the current state of the requested resource, the desired state 
for the requested resource, or the value of some other resource, such as 
a representation of the input data within a client's query form, or a 
representation of some error condition for a response.
</snippet>

I read this to say that "the input data within a client's query form" is 
a resource.  Note that it is not likely that the data within a client's 
query form has a URI.  (I also note that the first three examples seem 
to line up pretty well with GET, PUT and POST.)

>
>A lot of the resources I've been thinking about are completely useless
>from a REST perspective; for example urn:isbn:123-456 might identify a
>resource, namely a book (in the abstract, not any particular copy). And
>yet, what good is it? Handy for RDF, but it's not HTTP addressable so 
>there is not much to say about it in a REST context.
>

There's nothing preventing me from POSTing a representation of 
urn:isbn:123-456 to some other resource that is HTTP addressable.  The 
fact that its not HTTP addressable does not prevent it from being used 
as a resource.

I apoligize if I'm beating the proverbial dead horse (take my stick, 
please!), but...
I dont understand this desire to pigeonhole resources as only (HTTP) 
addressable things.  One way to look at it is that resources don't exist 
so they can have names - resources exist so that representations of them 
can be transferred to or from other resources.

--Chuck







-----------------------------------------------------------------------------------
Post ID:2490
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-10 05:45:42
Subject:Re: [rest-discuss] Resources
Message:



>
> > That and a million dollars of VC funding will get you my answer...
>
> How enigmatic :) Can't say I like the implementation of DDDS, given that I
> don't particularly appreciate the implementation of DNS. Has the topic of
> DNS reimplemented over HTTP requests to known server IPs, acting as proxy
> caches to root HTTP domain name servers been covered on this list? It
> would be fun to reimplement DNS and cover generic URI/URN resolving at
> once. (Not that the world would rush to adopt it or anything; you'd spend
> your million dollars on marketing and bribery, not development...)
>
True. True.






-----------------------------------------------------------------------------------
Post ID:2491
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-09-10 05:43:55
Subject:Re: [rest-discuss] Resources
Message:

"resources exist so that representations of them can be transferred to or
from other resources."

That's a nice definition to keep in mind. Rather circular, but it seems to
make sense :)

Michael







-----------------------------------------------------------------------------------
Post ID:2492
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-10 04:43:15
Subject:twipperty
Message:

We say that it is possible for a URI to not identify anything.  However, I
am beginning to wonder if that's true.  Suppose you were to take the English
language.  Now, suppose I were to present to you the following:


    twipperty


You say: "what's that?"  I answer absolutely nothing.  It has not meaning
(identifies nothing)  as a result it isn't even a word, even though it looks
like one.


And this brings us to URIs.  Just because you can put together a random
string of characters that looks like a URI does not, in fact, make it a URI.
And this is where I think we make our mistake....


If you were to see:

http://www.not-an-actual-website.com/some-random-path/twipperty


Is it a URI?  Well, it looks like one (and "twipperty" looked like a word).
But until you can resolve it to some sort of meaning (identify something
with it), then it ain't a URI, no matter how much it looks like one!


---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2493
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-10 05:14:33
Subject:REST and the Web
Message:

I have been learning REST for some time now, and I feel that I have even
more to learn.  However, I keep coming to one conclusion in partcicular.
This conclusion may not be very popular within this list, esp. since this
list is generally pro-HTTP.  But I like sticking my neck out, so here
goes...


The most common "proof" that REST works is HTTP.  This makes sense
considering that Fielding had been looking at HTTP when he did his work on
REST.  Also, considering that he helped author HTTP 1.1, this would lend
even more credence to the statement that "The Web proves that REST works."

Because of this, I have focused on learning REST as it applies to HTTP,
though I had initially started by trying to learn REST independent of any
application or protocol.  In this learning process, I continually run into
questions that do not seem to have clear, understandable answers.
Considering that HTTP was considered RESTful, I thought this to be an odd
thing.  I would expect a RESTful protocol to clearly show how the REST
architecture works.

Then it hit me.  I have let myself fall victem to marketing hype!  And here
is why I say that.  I took it as gospel that HTTP === REST.  I believed in
the statement that "The Web proves that REST works."  But I kept coming up
with these "issues" I couldn't reconcile.  So I sat down this weekend and
instead of considering *what* wasn't reconciling, I considered *why* it
wasn't reconciling.  And I think I finally hit upon the reason.

HTTP is not as RESTful as we would all like to believe.  For years, people
have been building web sites, mostly static pages.  Did these people use
HTTP PUT to update the server?  Absolutely not!  They used FTP.  They used
the access to their HTTP server through their local network.  To some
extent, they even used HTML Form-base file uploads via POST.  But PUT?
Hardly.  The exact same could be said for DELETE.

So, then we are left with POST and GET.  How do their "typical" usage play
out in the REST arena?  Well, as has been pointed out by many, many threads
on this very list, POST is often missused.  I'd even be willing to bet that
the vast majority of uses for POST are wrong in the eyes of REST.

This leaves us with GET.  GET is probably the one HTTP verb that generally
conforms to the REST architecture.  This is a good thing, considering that
probably 90% or more of the web traffic uses GET.

Sure, there *are* more and more implemenations of REST showing up, but in
ratio to the existing "non-REST" implementations already on the web, this is
probably quite a small number.

So, how can people say that "The Web proves that REST works"?  It's because
one (GET) of the four major HTTP verbs provides for 90% or more of the
proof. POST provides the most of the remaining percentage, and even though
many consider its usage to often be non-RESTful, we'll conveniently ignore
that.  And, as usual, PUT and DELETE are pretty much non-existant (in terms
of actual usage).

In the end, this does not make the Web a killer app that proves REST works.
If anything, it proves that certain aspects of REST work (i.e. GET).  Beyond
that, I am beginning to feel that HTTP has as much to prove as a truly
RESTful tool as does just about any other web-based technology out there
right now....

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2494
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-09-10 13:41:19
Subject:Re: [rest-discuss] REST and the Web
Message:

On Tuesday, Sep 10, 2002, at 06:14 Europe/Dublin, Seairth Jacobs wrote:
> So, how can people say that "The Web proves that REST works"?

to be honest, i have always been a bit dubious about that statement as 
well, given that (among many other things) so many websites use URIs of 
the form "/articles/showArticle.[pl|jsp|cfm]?articleId=123" instead of 
simply "/articles/123".

i don't think the Web (or more precisely the ubiquity of HTTP) proves 
that REST works.  much of the time HTTP is being used as something 
else, which i am thus far incapable of labelling.

that said, i am a firm believer that REST does work, but more because 
it 'feels right' than because the Web (or anything else) /proves/ that 
it works.







-----------------------------------------------------------------------------------
Post ID:2495
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-10 14:10:15
Subject:RE: [rest-discuss] REST and the Web
Message:


> -----Original Message-----
> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Tuesday, September 10, 2002 1:15 AM
> To: rest-discuss
> Subject: [rest-discuss] REST and the Web
> 
> 
> I have been learning REST for some time now, and I feel that 
> I have even
> more to learn.  However, I keep coming to one conclusion in 
> partcicular.
> This conclusion may not be very popular within this list, 
> esp. since this
> list is generally pro-HTTP.  But I like sticking my neck out, so here
> goes...
> 
> 
> The most common "proof" that REST works is HTTP.  This makes sense
> considering that Fielding had been looking at HTTP when he 
> did his work on
> REST.  Also, considering that he helped author HTTP 1.1, this 
> would lend
> even more credence to the statement that "The Web proves that 
> REST works."

According to Fielding, REST provided valuable guidance in some
of the more recent design of web protocol, and in that sense he's
declaring it to "work", but we mostly mean something else when
we talk about REST "working".

> 
> Because of this, I have focused on learning REST as it 
> applies to HTTP,
> though I had initially started by trying to learn REST 
> independent of any
> application or protocol.  In this learning process, I 
> continually run into
> questions that do not seem to have clear, understandable answers.
> Considering that HTTP was considered RESTful, I thought this 
> to be an odd
> thing.  I would expect a RESTful protocol to clearly show how the REST
> architecture works.

The protocol itself can support REST architected applications, but
it can't control the way it is used, just like you can't prevent
houses from being used as targets on Halloween.  So while HTTP may
be considered "RESTful", the same doesn't go for all applications
of HTTP.

But sans applications (which admittedly makes architecture study
that much harder) you can see HTTP as an example of a way to bring
REST style to life.  You can see that it has a limited number of
very generic methods, that it has uniform identifiers built right
in, that it separates client from server in each task it undertakes,
that it has directives for caching, and so on.  One of the things
HTTP doesn't do well is constrain applications from holding
conversational state on the server.  Another thing it really can't
constrain is whether your application can directly address the
resources in its domain or whether you tunnel all requests through
a single identifier.

Instead of thinking of HTTP as a proof of REST, it might be more
productive to think of REST of a guideline for using HTTP for
maximum benefit.

> 
> Then it hit me.  I have let myself fall victem to marketing 
> hype!

In the application design arena, this is inevitable, even when
you go in with your eyes wide open.  The fact is that we're
only playing a game here, applying heuristics to find the best
patterns to spend time with.  There's no way to do this without
employing faith, because otherwise you'd never make any
sweeping decisions.  So unlax.  REST isn't perfect; neither is
HTTP.  Still, the discovery of simple forms that do powerful
work is an exciting discovery.  I had a ball piecing together
the puzzle of how to map a set of entitlements function calls
onto an entitlements resource model, and I'm still having fun
refining that model and selling the results.  I can tell it's
good because the API keeps shrinking without losing function.

> And here
> is why I say that.  I took it as gospel that HTTP === REST.  
> I believed in
> the statement that "The Web proves that REST works."  But I 
> kept coming up
> with these "issues" I couldn't reconcile.  So I sat down this 
> weekend and
> instead of considering *what* wasn't reconciling, I 
> considered *why* it
> wasn't reconciling.  And I think I finally hit upon the reason.
> 
> HTTP is not as RESTful as we would all like to believe.  For 
> years, people
> have been building web sites, mostly static pages.  Did these 
> people use
> HTTP PUT to update the server?  Absolutely not!  They used 
> FTP.  They used
> the access to their HTTP server through their local network.  To some
> extent, they even used HTML Form-base file uploads via POST.  But PUT?
> Hardly.  The exact same could be said for DELETE.

REST merely says that connectors are constrained to a limited set
of very generic methods.  HTTP supplies such a set of methods, plus
some rules for when they apply.  I'm not sure if REST says
that there has to be a resource modification method that's
idempotent, a retrieval method that's safe, etc.  I'm pretty sure
REST says nothing about there having to be a deletion method.
So, the fact that you can design systems around GET and POST
doesn't disprove REST; nor does it disprove HTTP.  The argument
in favor of using what's already in HTTP instead of reinventing
is different from the more general argument for styling applications
with REST, IMO.

The distinction is there if you wish to observe it, but culturally
the two seem to blend in the name of common sense.

> In the end, this does not make the Web a killer app that 
> proves REST works.
> If anything, it proves that certain aspects of REST work 
> (i.e. GET).  Beyond
> that, I am beginning to feel that HTTP has as much to prove as a truly
> RESTful tool as does just about any other web-based 
> technology out there
> right now....

That's a fair assessment, and it corresponds with my experience
in trying to go beyond what Jackson calls the "static information
frame"-type application using HTTP.  Making intricate behaviors
occur through a very generic interface is a real challenge.  But,
the fact that I can use the web to research the things I do gives
credibility to the fact that at least the GET side is "killer".

Walden






-----------------------------------------------------------------------------------
Post ID:2496
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-10 14:26:15
Subject:Re: [rest-discuss] REST and the Web
Message:

----- Original Message -----
From: "Vincent D Murphy" <vdm@...>

>
> to be honest, i have always been a bit dubious about that statement as
> well, given that (among many other things) so many websites use URIs of
> the form "/articles/showArticle.[pl|jsp|cfm]?articleId=123" instead of
> simply "/articles/123".
Both are equivalent from the "URI is an identifier" point of view.
The path-based URI has certain nice properties, as does the query-based URI.
REST and RESTful HTTP designs do not necessarily prefer one over the other.







-----------------------------------------------------------------------------------
Post ID:2497
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-10 14:28:15
Subject:Re: [rest-discuss] REST and the Web
Message:

----- Original Message ----- 
From: "Mathews, Walden" <waldenm@...>

> 
> Instead of thinking of HTTP as a proof of REST, it might be more
> productive to think of REST of a guideline for using HTTP for
> maximum benefit.
Well put.

> Still, the discovery of simple forms that do powerful
> work is an exciting discovery.  I had a ball piecing together
> the puzzle of how to map a set of entitlements function calls
> onto an entitlements resource model, and I'm still having fun
> refining that model and selling the results.  I can tell it's
> good because the API keeps shrinking without losing function.
Cool!







-----------------------------------------------------------------------------------
Post ID:2498
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-10 18:10:33
Subject:Re: [rest-discuss] REST and the Web
Message:

Seairth Jacobs wrote:
>...

> HTTP is not as RESTful as we would all like to believe.  For years, people
> have been building web sites, mostly static pages.  Did these people use
> HTTP PUT to update the server?  Absolutely not!  They used FTP.  They used
> the access to their HTTP server through their local network.  To some
> extent, they even used HTML Form-base file uploads via POST.  But PUT?
> Hardly.  The exact same could be said for DELETE.

I don't think that PUT and DELETE are core to REST. They are just 
logical extensions of HTTP's two core methods of GET and POST. 
Fielding's interface doesn't say WHAT generic interface you should use, 
just that you should use one.

> So, then we are left with POST and GET.  How do their "typical" usage play
> out in the REST arena?  Well, as has been pointed out by many, many threads
> on this very list, POST is often missused.  I'd even be willing to bet that
> the vast majority of uses for POST are wrong in the eyes of REST.

It might be accurate to say that most uses of POST are wrong in one way 
or the other. But how many object oriented programs do not 100% conform 
to that paradigm? The important thing is that the *best* web-based 
services tend to use REST principles quite a bit, and the more they do 
the better they tend to get -- at least from the client's perspective. 
The more they uniquely identify things with URIs, the more the client 
can bookmark. The more they use GET for GET and POST for POST the fewer 
issues they will have with spiders that trigger actions or things that 
should be bookmarkable but aren't. The less they use cookies, the easier 
it is for customers to move between devices. etc.

>...
> So, how can people say that "The Web proves that REST works"?  It's because
> one (GET) of the four major HTTP verbs provides for 90% or more of the
> proof. POST provides the most of the remaining percentage, and even though
> many consider its usage to often be non-RESTful, we'll conveniently ignore
> that.  And, as usual, PUT and DELETE are pretty much non-existant (in terms

REST isn't GET+PUT+POST+DELETE. It's identification of resources (name a 
website without a URL ;) ), manipulation of resources through 
representations (e.g. form-encoded), self-descriptive messages and 
hypermedia as the engine of application state, universal interfaces, ... 
You can do these things with only two methods. Having four instead 
increases interoperability and I would have no compunction about going 
beyond four (e.g. adding WATCH or NOTIFY or maybe GETCHILDREN).


> In the end, this does not make the Web a killer app that proves REST works.
> If anything, it proves that certain aspects of REST work (i.e. GET).  Beyond
> that, I am beginning to feel that HTTP has as much to prove as a truly
> RESTful tool as does just about any other web-based technology out there
> right now....

HTTP explicitly supports the things I describe above. Other protocols 
don't. That doesn't mean that HTTP is perfect but it is the starting 
point. BTW, if you look at BEEP, the issues they punt on are exactly the 
issues that HTTP addresses.

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2499
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-10 18:52:20
Subject:Re: [rest-discuss] Resources
Message:

Michael Day wrote:

> How enigmatic :) Can't say I like the implementation of DDDS, given that I
> don't particularly appreciate the implementation of DNS. Has the topic of
> DNS reimplemented over HTTP requests to known server IPs, acting as proxy
> caches to root HTTP domain name servers been covered on this list? It
> would be fun to reimplement DNS and cover generic URI/URN resolving at
> once. (Not that the world would rush to adopt it or anything; you'd spend
> your million dollars on marketing and bribery, not development...)

I think that if you want DNS' performance you'd at least need to move 
HTTP to a UDP foundation before moving DNS to an HTTP foundation. TCP 
connections are kind of expensive and DNS runs all over the Internet 
trying to resolve each address.

  Paul Prescod









-----------------------------------------------------------------------------------
Post ID:2500
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-09-10 23:23:30
Subject:Re: [rest-discuss] Resources
Message:

> I think that if you want DNS' performance you'd at least need to move 
> HTTP to a UDP foundation before moving DNS to an HTTP foundation. TCP 
> connections are kind of expensive and DNS runs all over the Internet 
> trying to resolve each address.

How about the variant of TCP whose name I sadly forget which piggybacks
the first data on the connect packets? I seem to recall that reduced the
overhead of TCP compared to UDP, particularly for small requests like DNS
lookups, but as I can't remember the name I'm having trouble finding it.

Michael







-----------------------------------------------------------------------------------
Post ID:2501
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-09-10 23:40:18
Subject:Re: [rest-discuss] Resources
Message:

> How about the variant of TCP whose name I sadly forget which piggybacks
> the first data on the connect packets? I seem to recall that reduced the
> overhead of TCP compared to UDP, particularly for small requests like DNS
> lookups, but as I can't remember the name I'm having trouble finding it.

Ah, it was T/TCP, RFC 1644.

Michael







-----------------------------------------------------------------------------------
Post ID:2502
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-11 00:31:36
Subject:Re: [rest-discuss] Resources
Message:

Michael Day wrote:
>>How about the variant of TCP whose name I sadly forget which piggybacks
>>the first data on the connect packets? I seem to recall that reduced the
>>overhead of TCP compared to UDP, particularly for small requests like DNS
>>lookups, but as I can't remember the name I'm having trouble finding it.
> 
> 
> Ah, it was T/TCP, RFC 1644.

Looks interesting. Is it implemented anywhere?

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2503
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-09-11 01:35:32
Subject:Re: [rest-discuss] Resources
Message:

> > Ah, it was T/TCP, RFC 1644.
> 
> Looks interesting. Is it implemented anywhere?

I've seen a prototype implementation for Linux, but I don't know if the
protocol is in widespread use anywhere. Theoretically it should be easy to
deploy, as you can always fallback to regular TCP operation if the host
doesn't understand the T/TCP request and refuses the connection.

Michael








-----------------------------------------------------------------------------------
Post ID:2504
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-09-11 05:23:44
Subject:FYI: iCal
Message:

Today, Apple released iCal, a calendaring product that uses the IETF
format of the same name, today. It claims to require a WEBDAV-enabled Web
server to publish to.

Aaron and I did some testing of it tonight, and discovered that it's
perfectly possible to use with a PUT/DELETE-enabled Web server; it only
seems to use MKCOL from WebDAV to make sure that the containing resource
is present.

Question: has anyone done a writeup of WebDAV to see what the additional
functionality over REST is, and how often it's required? To my knowledge,
the only notable bits are MKCOL and properties (which IIRC have been
discussed here as capable of being modeled in a more RESTful manner).
Anything else?

P.S. iCal supports Digest Auth; yippee!

--
Mark Nottingham







-----------------------------------------------------------------------------------
Post ID:2505
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-09-11 09:31:13
Subject:URI syntax
Message:

I'm sure this has come up before, but it's bugging me, so:

Many protocols such as XML Namespaces and RDF compare URIs syntactically.  
Consider the following six URIs:

	1. http://www.foo.com/resource
	2. http://www.foo.com/resource/
	3. http://www.foo.com/resource#
	4. http://www.foo.com/resource?
	5. http://www.foo.com/resource?#
	6. http://www.foo.com/resource/?#

Syntactically they are all different, and yet different in different ways.
1 and 2 have been giving me trouble as I originally used 1 for many
resources that were actually directories underneath, and Apache insisted
on redirecting to 2. So I use 2 now. 3 seems to come up very often when
using RDF, and appears to be a namespace URI hack to generate URIs with
fragment IDs from namespace qualified names. I haven't seen examples of 
the rest.

Can anyone comment on the differences between these URIs? Are there any
rough guidelines as to which style should be used in different
circumstances?

Michael







-----------------------------------------------------------------------------------
Post ID:2506
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-09-11 13:15:14
Subject:Re: [rest-discuss] URI syntax
Message:

On Wednesday, Sep 11, 2002, at 10:31 Europe/Dublin, Michael Day wrote:
> 	1. http://www.foo.com/resource
> 	2. http://www.foo.com/resource/
>
> Syntactically they are all different, and yet different in different 
> ways.
> 1 and 2 have been giving me trouble as I originally used 1 for many
> resources that were actually directories underneath, and Apache 
> insisted
> on redirecting to 2. So I use 2 now.

i have thought for a while now that this behaviour in apache is 
incorrect.  URIs without trailing slashes should be just accepted.

i reckon the trailing slash is just a side-effect of apache's 
filesystem-bias.  (along with index.html, which is meaningless IMHO).

what's the best place to 'change' this behavior?  mod_dir?

anyway, to answer your question (partially):  i avoid the trailing 
slash in URIs whenever i can.







-----------------------------------------------------------------------------------
Post ID:2507
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-11 15:04:54
Subject:Re: [rest-discuss] URI syntax
Message:

----- Original Message -----
From: "Vincent D Murphy" <vdm@...>

> i reckon the trailing slash is just a side-effect of apache's
> filesystem-bias.  (along with index.html, which is meaningless IMHO).

Oh, I don't know about meaningless for index.html. That's the 'magic name'
of the 'list all children' or 'list all outbound links' for a collection
based resource. If you squint a little bit...
Doing just a file-system list isn't flexible enough - as index.html can hold
links to arbitrary (non-relative) resources.






-----------------------------------------------------------------------------------
Post ID:2508
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-11 16:58:21
Subject:Re: [rest-discuss] FYI: iCal
Message:

Mark Nottingham wrote:
> Today, Apple released iCal, a calendaring product that uses the IETF
> format of the same name, today. It claims to require a WEBDAV-enabled Web
> server to publish to.
> 
> Aaron and I did some testing of it tonight, and discovered that it's
> perfectly possible to use with a PUT/DELETE-enabled Web server; it only
> seems to use MKCOL from WebDAV to make sure that the containing resource
> is present.
> 
> Question: has anyone done a writeup of WebDAV to see what the additional
> functionality over REST is, and how often it's required? 

Just to clarify...

I'd phrase that: "has anyone done a writeup of WebDAV to see how closely 
it adheres to the REST architectural style?" The reason I quibble is 
because some people have the sense that REST is GET/PUT/POST/DELETE and 
I'm probably as much at fault for that as anyone. But I don't think 
Fielding's thesis mentions any particular methods at all. WebDAV's 
"extra" methods are not against REST merely because they are extra 
methods. Perhaps if they violate some of the other constraints of 
REST...(e.g. if they were specific, or stateful, ...) I'm not convinced 
that WebDAV properties are necessarily "against" REST but it may be that 
could have been done in a manner that fit Web infrastructure better. 
Someone definately needs to write a paper on that one day.

You probably know this Mark but I just wanted to make the point.

> P.S. iCal supports Digest Auth; yippee!

Alright!

Did you reverse engineer the iCal protocol and file formats enough to 
determine to what extent it is RESTful? Does it use URIs in a sane way etc?

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2509
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-09-11 22:12:13
Subject:Re: [rest-discuss] FYI: iCal
Message:

> I'd phrase that: "has anyone done a writeup of WebDAV to see how closely
> it adheres to the REST architectural style?"

I was interested in how much of the functionality of WebDAV actually comes
from vanilla HTTP (PUT, DELETE, and so forth); i.e., "What does compiling
in WebDAV give me over mod_put?" But this would be a good thing as well...


> Did you reverse engineer the iCal protocol and file formats enough to
> determine to what extent it is RESTful? Does it use URIs in a sane way
etc?

Just some live testing whilst watching the logs; I may set up a proxy to
examine the headers as they fly by as well. Its use of URIs seems quite
sensible (i.e., having a calendar or group of events identifiable as a
URI), except for the one problem with the new scheme, as noted to the URI
list.







-----------------------------------------------------------------------------------
Post ID:2510
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-09-12 07:40:28
Subject:RE: [rest-discuss] FYI: iCal
Message:

Hi,

> Just some live testing whilst watching the logs; I may set up a proxy to
> examine the headers as they fly by as well. Its use of URIs seems quite
> sensible (i.e., having a calendar or group of events identifiable as a
> URI), except for the one problem with the new scheme, as noted to the URI
> list.

is this scheme documented somewhere, or did you just see it in the traces?
Where does it appear?

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760








-----------------------------------------------------------------------------------
Post ID:2511
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-09-12 15:13:28
Subject:Re: [rest-discuss] FYI: iCal
Message:

It wasn't in the traces; the request-line was relative, not absolute, and
I haven't had a chance to hook up a proxy capable of recording header
traces yet.

iCal has a function where you can send someone a notification of your
calendar through e-mail. This e-mail contains a URI with the webcal
scheme. Also, see the 'subscribe' links at:
  http://www.apple.com/ical/library/



----- Original Message -----
From: "Julian Reschke" <julian.reschke@...>
To: "Mark Nottingham" <mnot@...>; <rest-discuss@yahoogroups.com>;
"Paul Prescod" <paul@...>
Cc: <me@...>
Sent: Thursday, September 12, 2002 12:40 AM
Subject: RE: [rest-discuss] FYI: iCal


> Hi,
>
> > Just some live testing whilst watching the logs; I may set up a proxy
to
> > examine the headers as they fly by as well. Its use of URIs seems
quite
> > sensible (i.e., having a calendar or group of events identifiable as a
> > URI), except for the one problem with the new scheme, as noted to the
URI
> > list.
>
> is this scheme documented somewhere, or did you just see it in the
traces?
> Where does it appear?
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>







-----------------------------------------------------------------------------------
Post ID:2512
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-12 11:13:37
Subject:Re: [rest-discuss] URI syntax
Message:

Michael Day wrote:
> I'm sure this has come up before, but it's bugging me, so:
> 
> Many protocols such as XML Namespaces and RDF compare URIs syntactically.  
> Consider the following six URIs:
> 
> 	1. http://www.foo.com/resource
> 	2. http://www.foo.com/resource/
> 	3. http://www.foo.com/resource#
> 	4. http://www.foo.com/resource?
> 	5. http://www.foo.com/resource?#
> 	6. http://www.foo.com/resource/?#
> 
> Syntactically they are all different, and yet different in different ways.
> 1 and 2 have been giving me trouble as I originally used 1 for many
> resources that were actually directories underneath, and Apache insisted
> on redirecting to 2. So I use 2 now. 3 seems to come up very often when
> using RDF, and appears to be a namespace URI hack to generate URIs with
> fragment IDs from namespace qualified names. I haven't seen examples of 
> the rest.

I think Tim Berners-Lee and Roy Fielding disagree on what is appropriate 
between 1. and 3. IIRC, Basically Tim's position is that "1" identifies 
the HTTP resource (the W3C's web page) and "3" identifies the "logical 
concept" (the W3C). I believe that Fielding thinks that 1. identifies 
the logical concept and it is up to the identifying context to be 
explicit whether it is talking about a resource or a representation.

I tend to agree with Vincent that there is no reason in Web architecture 
to prefer 2. to 1. I guess it doesn't hurt to "hint" that the resource 
is a container. But if it isn't then it is especially annoying that it 
is difficult to leave off the slash in most web servers.

  Paul Prescod









-----------------------------------------------------------------------------------
Post ID:2513
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-12 11:24:53
Subject:Re: [rest-discuss] resources and identity
Message:

firepipe_au wrote:
> ...

> 
> <quote>Any information that can be named can be a resource: a 
> document or image, a temporal service (e.g. "today's weather in Los 
> Angeles"), a collection of other resources, a non-virtual object 
> (e.g. a person), and so on</quote>
> 
> That means it is possible that the air conditioner /could be/ a 
> resource, by Roy's use of the word 'can', and inclusion of non-
> virtual objects. No?
> 
> <quote>In other words, any concept that might be the target of an 
> author's hypertext reference must fit within the definition of a 
> resource</quote>
> 
> What?  That means my air conditioner isn't a resource, because I 
> can't reference it through hypertext (HTTP).  

If the air conditioner has a URI then you can reference it through 
hypertext. When you dereference you don't get back the air conditioner, 
though, you get back a representation of it (perhaps a webcam snapshot, 
perhaps a static HTML document, perhaps an RDF instance)

 > ...
> Ah, the resource is nothing I can ever get my hands on.  The resource 
> is the 'concept' that maps to reporting/changing temperature in my 
> bedroom (and/or humidity, if my air conditioner was fancy enough).  
> So the air conditioner itself, the physical, plastic reality of the 
> thing, is not a resource.  But by the act of mapping some of its 
> functions as URIs, it becomes conceptually a resource, providing 
> representations of its functions.  

When you give URIs to the functions, the functions become Web resources. 
But if you want the air conditioner to be a Web resource then it needs 
its own URI.


> 1) Define a resource, conceptually
> 2) Define representations of that resource
> 3) Map one URI to each representation - two representations being 
> equivalent at some time does not confuse the issue, they are 
> representations I have chosen to present.
> 4) Give the URIs to others to play with  :-)

Note that there is nothing wrong with having multiple representations at 
one URI. That's what HTTP content negotiation allows. Then your air 
conditioner can report itself in XML to XML clients and JPEG to 
graphically oriented clients.

> A note:
> Reading RFC 2068 Section 9.6 on PUT, I see a lot of stuff about 
> PUTting resources, not representations.  

The HTTP spec uses the term "entity" not representation for historical 
reasons. And in fact it does talk about PUTting entities, not resources.

> Roy says I can't GET the time functions that I just PUT, though, 
> because you can't GET resources.  I can, however, GET a 
> representation which seems to me like a fine compromise - the RFC 
> says nothing about GETting back what you put, so that's OK (an indeed 
> necessary by definition of a resource).

I disagree. I do think that GET and PUT are meant to be symmetrical. 
Resources can not be GOT nor PUT. Only representations/entities.

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2514
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-09-12 17:49:06
Subject:RE: [rest-discuss] URI syntax
Message:

> From: Paul Prescod [mailto:paul@...]
> Sent: Thursday, September 12, 2002 1:14 PM
> To: Michael Day
> Cc: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] URI syntax
> ...
> >
> > Many protocols such as XML Namespaces and RDF compare URIs
> syntactically.
> > Consider the following six URIs:
> >
> > 	1. http://www.foo.com/resource
> > 	2. http://www.foo.com/resource/
> > 	3. http://www.foo.com/resource#
> > 	4. http://www.foo.com/resource?
> > 	5. http://www.foo.com/resource?#
> > 	6. http://www.foo.com/resource/?#
> >
> > Syntactically they are all different, and yet different in
> different ways.
> > 1 and 2 have been giving me trouble as I originally used 1 for many
> > resources that were actually directories underneath, and Apache insisted
> > on redirecting to 2. So I use 2 now. 3 seems to come up very often when
> > using RDF, and appears to be a namespace URI hack to generate URIs with
> > fragment IDs from namespace qualified names. I haven't seen examples of
> > the rest.
>
> I think Tim Berners-Lee and Roy Fielding disagree on what is appropriate
> between 1. and 3. IIRC, Basically Tim's position is that "1" identifies
> the HTTP resource (the W3C's web page) and "3" identifies the "logical
> concept" (the W3C). I believe that Fielding thinks that 1. identifies
> the logical concept and it is up to the identifying context to be
> explicit whether it is talking about a resource or a representation.
>
> I tend to agree with Vincent that there is no reason in Web architecture
> to prefer 2. to 1. I guess it doesn't hurt to "hint" that the resource
> is a container. But if it isn't then it is especially annoying that it
> is difficult to leave off the slash in most web servers.

I think the issue here is that 1 and 2 may identify *different* resources.

WebDAV says that collections should be identified with trailing "/", but
that a server should basically treat the same URI without slash as
identifying the same resource. But that's just WebDAV :-)


--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760








-----------------------------------------------------------------------------------
Post ID:2515
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-12 18:05:36
Subject:Re: [rest-discuss] REST and the Web
Message:

I think this is an odd discussion.  REST doesn't "work" or "not work".
The Web works, and REST describes the architectural constraints that
were in part responsible for why it works.  Obviously there are
many other reasons for why the Web was successful, only some of them
technical.

MB

On Tue, Sep 10, 2002 at 02:41:19PM +0100, Vincent D Murphy wrote:
> On Tuesday, Sep 10, 2002, at 06:14 Europe/Dublin, Seairth Jacobs wrote:
> > So, how can people say that "The Web proves that REST works"?
> 
> to be honest, i have always been a bit dubious about that statement as 
> well, given that (among many other things) so many websites use URIs of 
> the form "/articles/showArticle.[pl|jsp|cfm]?articleId=123" instead of 
> simply "/articles/123".
> 
> i don't think the Web (or more precisely the ubiquity of HTTP) proves 
> that REST works.  much of the time HTTP is being used as something 
> else, which i am thus far incapable of labelling.
> 
> that said, i am a firm believer that REST does work, but more because 
> it 'feels right' than because the Web (or anything else) /proves/ that 
> it works.
> 
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2516
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-12 18:46:16
Subject:RE: [rest-discuss] REST and the Web
Message:

"In part responsible" is the key phrase.  If you build a system strictly
in the REST style, you'll be doing something a little different from the
normative web out there.  Another way of saying it: if REST was just a
description of existing web stuff, it wouldn't be useful in guiding the
process of evolving the web.  So REST is some kind of logical extension
of the existing web, incorporating the ideals formed from lessons learned
with the web.

If REST were purely descriptive, this would be an odd discussion.  But we
are attempting to use it prescriptively.  I interpret questions like "does
REST work?" to mean "does REST work prescriptively?".  I think everyone
else does too.

Walden

> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Thursday, September 12, 2002 2:06 PM
> To: Vincent D Murphy
> Cc: Seairth Jacobs; rest-discuss
> Subject: Re: [rest-discuss] REST and the Web
> 
> 
> I think this is an odd discussion.  REST doesn't "work" or "not work".
> The Web works, and REST describes the architectural constraints that
> were in part responsible for why it works.  Obviously there are
> many other reasons for why the Web was successful, only some of them
> technical.
> 
> MB
> 
> On Tue, Sep 10, 2002 at 02:41:19PM +0100, Vincent D Murphy wrote:
> > On Tuesday, Sep 10, 2002, at 06:14 Europe/Dublin, Seairth 
> Jacobs wrote:
> > > So, how can people say that "The Web proves that REST works"?
> > 
> > to be honest, i have always been a bit dubious about that 
> statement as 
> > well, given that (among many other things) so many websites 
> use URIs of 
> > the form "/articles/showArticle.[pl|jsp|cfm]?articleId=123" 
> instead of 
> > simply "/articles/123".
> > 
> > i don't think the Web (or more precisely the ubiquity of 
> HTTP) proves 
> > that REST works.  much of the time HTTP is being used as something 
> > else, which i am thus far incapable of labelling.
> > 
> > that said, i am a firm believer that REST does work, but 
> more because 
> > it 'feels right' than because the Web (or anything else) 
> /proves/ that 
> > it works.
> > 
> > 
> > 
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> > 
> >  
> > 
> > Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 
> 
> 

-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2517
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-12 19:12:09
Subject:Re: [rest-discuss] REST and the Web
Message:

On Thu, Sep 12, 2002 at 02:46:16PM -0400, Mathews, Walden wrote:
> "In part responsible" is the key phrase.

Well, by that I meant the non-technical reasons; the internet was
becoming more accessible before the Web, it was easy and cheap to
author (good tools), it was well lead by a handful of super smart
people, etc..

>  If you build a system strictly
> in the REST style, you'll be doing something a little different from the
> normative web out there.

I don't think so.

>  Another way of saying it: if REST was just a
> description of existing web stuff, it wouldn't be useful in guiding the
> process of evolving the web.  So REST is some kind of logical extension
> of the existing web, incorporating the ideals formed from lessons learned
> with the web.
> 
> If REST were purely descriptive, this would be an odd discussion.  But we
> are attempting to use it prescriptively.  I interpret questions like "does
> REST work?" to mean "does REST work prescriptively?".  I think everyone
> else does too.

I don't attempt to use it prescriptively, though I know it probably
looks this way.  When that happens, it's because there is some desirable
set of properties that I'm trying to achieve, and I know that they can
only reasonably be had with some subset of REST's constraints.

REST is most defintely *descriptive*.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2518
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-12 19:34:25
Subject:RE: [rest-discuss] REST and the Web
Message:


> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Thursday, September 12, 2002 3:12 PM
> To: Mathews, Walden
> Cc: 'Mark Baker'; Vincent D Murphy; Seairth Jacobs; rest-discuss
> Subject: Re: [rest-discuss] REST and the Web
> 
> 
> On Thu, Sep 12, 2002 at 02:46:16PM -0400, Mathews, Walden wrote:
> > "In part responsible" is the key phrase.
> 
> Well, by that I meant the non-technical reasons; the internet was
> becoming more accessible before the Web, it was easy and cheap to
> author (good tools), it was well lead by a handful of super smart
> people, etc..
> 
> >  If you build a system strictly
> > in the REST style, you'll be doing something a little 
> different from the
> > normative web out there.
> 
> I don't think so.

Okay, have a Cookie! :-0

> 
> >  Another way of saying it: if REST was just a
> > description of existing web stuff, it wouldn't be useful in 
> guiding the
> > process of evolving the web.  So REST is some kind of 
> logical extension
> > of the existing web, incorporating the ideals formed from 
> lessons learned
> > with the web.
> > 
> > If REST were purely descriptive, this would be an odd 
> discussion.  But we
> > are attempting to use it prescriptively.  I interpret 
> questions like "does
> > REST work?" to mean "does REST work prescriptively?".  I 
> think everyone
> > else does too.
> 
> I don't attempt to use it prescriptively, though I know it probably
> looks this way.  When that happens, it's because there is 
> some desirable
> set of properties that I'm trying to achieve, and I know that they can
> only reasonably be had with some subset of REST's constraints.

That's a terribly subtle distinction.  There's no question that REST
(via the Fielding paper) doesn't tell you what steps to follow.  In
that sense it's not prescriptive.  But when you talk about "RESTifying"
some service, you're almost certainly following some hidden process
that could easily (?) be documented.  InTheDarkPlace documented such a
process here recently.  But we'll agree in advance that that process
is not REST.

Whether you call that prescriptive or descriptive -- I don't care
what the correct word is -- people are using this as a design guide,
applying it to all sorts of things that didn't start out as hypertext,
so in that context "does it work?" seems quite reasonable (to me).

> 
> REST is most defintely *descriptive*.

Technically, Mark, REST was described in a thesis, but that doesn't
make REST descriptive.  It makes the thesis descriptive.  The thesis
is careful to draw this very distinction, so I thought it appropriate
to drag it out.

Walden







-----------------------------------------------------------------------------------
Post ID:2519
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-12 19:55:22
Subject:Re: [rest-discuss] REST and the Web
Message:

Mark Baker wrote:
>...

>>
>>If REST were purely descriptive, this would be an odd discussion.  But we
>>are attempting to use it prescriptively.  I interpret questions like "does
>>REST work?" to mean "does REST work prescriptively?".  I think everyone
>>else does too.
> 
> 
> I don't attempt to use it prescriptively, though I know it probably
> looks this way.  When that happens, it's because there is some desirable
> set of properties that I'm trying to achieve, and I know that they can
> only reasonably be had with some subset of REST's constraints.

When we tell someone to make their messages stateless so that they can 
improve scalability and reliability, that's a "prescription" to solve 
their (real or potential) "illness" of poor scalability.

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2520
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-12 20:05:45
Subject:Re: [rest-discuss] REST and the Web
Message:

On Thu, Sep 12, 2002 at 12:55:22PM -0700, Paul Prescod wrote:
> > I don't attempt to use it prescriptively, though I know it probably
> > looks this way.  When that happens, it's because there is some desirable
> > set of properties that I'm trying to achieve, and I know that they can
> > only reasonably be had with some subset of REST's constraints.
> 
> When we tell someone to make their messages stateless so that they can 
> improve scalability and reliability, that's a "prescription" to solve 
> their (real or potential) "illness" of poor scalability.

Right, I should have been more careful with my wording.

*I'm* clearly using it prescriptively that way.  But REST (the
style and the dissertation) is not.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2521
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-12 20:59:55
Subject:Re: [rest-discuss] REST and the Web
Message:

Paul Prescod wrote,
> When we tell someone to make their messages stateless so that they
> can improve scalability and reliability, that's a "prescription" to
> solve their (real or potential) "illness" of poor scalability.

Which, I guess, leaves the original question of REST, its relation to 
the actually existing web, and the success of that latter validating 
the former.

The web works, despite the fact that lots of folks don't take their 
medicine. What other technical characteristics of the web account for 
that? Is there a RESTful core that's holding the whole thing together, 
or are there other principles at work? Would those other principles on 
their own be sufficient for a viable web?

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2522
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-12 21:17:35
Subject:Re: [rest-discuss] REST and the Web
Message:

Miles Sabin wrote:
>...
> 
> The web works, despite the fact that lots of folks don't take their 
> medicine.

I think most people take their medicine most of the time. Consider the 
biggest perceived difference between web services of a year ago and the 
REST model. It was: "should there be a predefined method for getting 
information or is it okay for everyone to choose their own methods." It 
is pretty clear that significant parts of the Web would keel over and 
die if we had not standardized on the GET method. What would clicking on 
links do? How would Google work?

Similarly, if the Web didn't have POST then it couldn't support creative 
activities like page authoring, booking flights, discussion etc.

So I see those as irreducible.

> ... What other technical characteristics of the web account for 
> that? Is there a RESTful core that's holding the whole thing together, 
> or are there other principles at work? Would those other principles on 
> their own be sufficient for a viable web?

I don't personally know where REST stops and "web architecture" starts 
so I can't answer that question. I am confident that without the fixed, 
stateless, address-centric interface of HTTP, the Web wouldn't work the 
way we know it today.

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2523
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-12 21:29:40
Subject:Re: [rest-discuss] REST and the Web
Message:

Paul Prescod wrote,
> Miles Sabin wrote:
> >...
> >
> > The web works, despite the fact that lots of folks don't take their
> > medicine.
>
> I think most people take their medicine most of the time.

As Walden said: have a cookie ... or an unsafe GET, or an abused POST. 
Like it or not, they're everywhere.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2524
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-12 22:20:25
Subject:Re: [rest-discuss] REST and the Web
Message:

Miles Sabin wrote:
> Paul Prescod wrote,
> 
>>Miles Sabin wrote:
>>
>>>...
>>>
>>>The web works, despite the fact that lots of folks don't take their
>>>medicine.
>>
>>I think most people take their medicine most of the time.
> 
> 
> As Walden said: have a cookie ... or an unsafe GET, or an abused POST.

What does the fact that someone, somewhere, uses an unsafe GET mean to 
me implementing a REST system? When I read a book on structured 
programming and decide to use it, it doesn't bother me that someone 
elsewhere is using "goto" statements to their own detriment. Most 
idempotent operations on the Web are done with GET. Most non-idempotent 
operations are done with POST. Most cookies are trivial marketing 
spy-ware that have nothing to do with the functionality of the site 
(barring authentication cookies). Most people, most of the time, use Web 
architecture properly whether they know they are doing that or not.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2525
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-12 22:28:52
Subject:Re: [rest-discuss] REST and the Web
Message:

Paul Prescod wrote,
> > As Walden said: have a cookie ... or an unsafe GET, or an abused
> > POST.
>
> What does the fact that someone, somewhere, uses an unsafe GET mean
> to me implementing a REST system?

Nothing at all.

But if you're claiming that the success of web as it is is evidence for 
the architectural merits of REST, then it's a bit awkward if big lumps 
of it aren't particularly RESTful.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2526
Sender:Robert Leftwich <robert@...>
Post Date/Time:2002-09-13 02:13:56
Subject:Re: [rest-discuss] resources and identity
Message:

Kendall Clark has written an article [1] discussing the TAG 'Architectural 
Principles of the World Wide Web' (APW) [2] which adds some clarity to this 
discussion (at least from my perspective). Some of the salient points:

"RFC 2396 fails spectacularly as a definition of "resource". It's wrong to 
commend a definition which doesn't provide any traction (a property, or 
condition, or state) by which one might distinguish between its 
*definiendum*, the thing being defined, in this case, resource, and 
anything else at all. "

"At least two things follow from this criticism. First, it doesn't seem to 
make much practical difference that RFC 2396 and the APW rely on a weird 
definition of "resource". Second, in the problem domain of Web 
specifications and standards, the conceptual boundaries between "resource", 
"identity", "identifier", and "representation" are gerrymandered, 
constantly shifting, and provisional at best."

"According to the APW (more accurately, to my reading of an early draft of 
the APW), a URI identifies one and only one *resource*, unambiguously, and 
the fragment identifier part of an absolute URI reference identifies some 
part of the *representation* of that resource. In effect, URIs have two 
namespaces: one which points to entities with the shared information space 
of the Web, another which points inside the representational space of the 
state of a Web resource. If URIs identify one and only resource, is there a 
parallel expectation that fragment identifiers identity one and only part 
(for lack of a more general word) of a representation? Should we extend the 
URI persistence practice to fragment identifiers, too? Do "cool" fragment 
identifiers change? "

"I take the cash value of the URI-Resource unambiguity principle above to 
mean that the representations of the state of a resource retrieved by, say, 
successive HTTP GET's of the same URI are representations of the state of 
the *same* resource, no matter how different that state may be."


In this light, PUT becomes "setting the *representation* of the state of 
the resource", DELETE "removing the *representation* of  the state of the 
resource" and POST is "supplying a new *representation* of an as yet 
unidentified resource" or more broadly "supplying a *representation* of 
some state that may be of interest (directly or indirectly) to the resource 
or at least that the resource can do something with other than setting, 
deleting or retrieving a representation of the state of itself" !

Robert

[1] http://www.xml.com/pub/a/2002/09/11/deviant.html
[2] http://www.w3.org/TR/webarch/







-----------------------------------------------------------------------------------
Post ID:2527
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-09-13 02:42:15
Subject:Re: [rest-discuss] URI syntax
Message:

> I think Tim Berners-Lee and Roy Fielding disagree on what is appropriate 
> between 1. and 3. IIRC, Basically Tim's position is that "1" identifies 
> the HTTP resource (the W3C's web page) and "3" identifies the "logical 
> concept" (the W3C). I believe that Fielding thinks that 1. identifies 
> the logical concept and it is up to the identifying context to be 
> explicit whether it is talking about a resource or a representation.

Tim's approach seems less robust, but the disagreement is really the 
problem here, as if people publish RDF that makes assertions about the 
following resources:

	http://www.w3.org
	http://www.w3.org/
	http://www.w3.org#
	http://www.w3.org/#
	http://w3.org
	...

...all of which will reach the homepage of the W3C (albeit possibly after
a redirect) and yet these are all syntactically distinct, so logical
statements involving one cannot be used in inferences involving the
others. Problem for RDF, no? And any other mechanism used to describe web
services that depends on URI syntax, which is why I mention it here. It
also brings up the thorny question or URI equivalence again.

> I tend to agree with Vincent that there is no reason in Web architecture 
> to prefer 2. to 1. I guess it doesn't hurt to "hint" that the resource 
> is a container. But if it isn't then it is especially annoying that it 
> is difficult to leave off the slash in most web servers.

Again, the problem is more with the lack of consistency and the problems 
that will create when exact comparisons are required.

Michael







-----------------------------------------------------------------------------------
Post ID:2528
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-13 04:03:19
Subject:Re: [rest-discuss] REST and the Web
Message:


Miles Sabin wrote:

>As Walden said: have a cookie ... or an unsafe GET, or an abused POST. 
>Like it or not, they're everywhere.
>
But I dont think HTTP == REST.  HTTP is one part of an application whose 
architectural style is described by REST.  HTTP is what defines the 
semantics of GET and POST.  REST only says that the command set should 
be small and general and that messages should be stateless.


I think if you look at why people claim the web is successful, you can 
probably relate most of those claims to some principle of a REST-style 
architecture.

For instance, it seems to me that a large part of the web's scalability 
(performance-wise) is related to the pervasiveness of caches and 
proxies.  I don't think caches and proxies would work very well if they 
couln't rely on the majority of messages being stateless.  (Caches are 
great for detecting deviations from REST.)  And, I think caches and 
proxies would be much harder to implement if the set of commands in HTTP 
was much larger than it is.

--Chuck








-----------------------------------------------------------------------------------
Post ID:2529
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-13 04:31:06
Subject:An HTTP/XML API to a search engine
Message:

I found a site (a friend of a friend runs it) that provides free pure-HTTP
access to Web search results in XML.
They serve 2M queries a day and index about 5M base URLs.

http://www.searchhippo.com/webservices.php
http://www.searchhippo.com/partner-httpxml.php

Sample:
http://www.searchhippo.com/qxml.php?q=john+milton


He also has some other nifty XML services:
Get SMS routing info (the email address) for US cell phones.
http://www.searchhippo.com/sms-httpxml.php

Sample:
http://www.searchhippo.com/sms-xml-resolver.php?ToPhone=4254428000








-----------------------------------------------------------------------------------
Post ID:2530
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-13 14:39:22
Subject:RE: [rest-discuss] REST and the Web
Message:

Folks,

My quote (see below) seems to have left its context behind.
Let me please bring it back.  REST (the description of the architecture
style of the same name) describes certain properties of the
"legacy" web, but not others.  For instance, it describes stateless
client-server interaction all the while widely deployed web
technologies like servlet support session state.  (You can add
other examples.)  So REST is *selectively* descriptive, with an
improvement goal espoused by its author.

At the same time, REST seems to describe resources at a level of
conceptualness that perhaps leads implementation by a few steps.  We
trip over little pieces of the HTTP spec that still make resources
sound like documents instead of the concepts behind them.  The
verbatim relationship between PUT and GET representations, e.g..

So, while REST is not *prescriptive* in the sense that it offers
process guidance or method for designing web applications, it's also
not *descriptive* without the above qualifications.  In other words,
there may be a large intersection between REST and the deployed
web in the large, but there are also significant differences (in
the set theory sense of the word -- adds and deletes).

Fielding said that REST emerged through analysis of the web and
proposals to enhance it, and that REST has provided useful guidance
in settling on enhancements.  That in itself tells you that REST
is not *just* a description of what exists.  It also tells you
that REST "works", at least for Fielding.  But Fielding is doing
a job somewhat different than the job we, individually, are
trying to do.

I think that to address the question of whether REST "works" in
the sense of offering you valuable guidance in designing an
application, it's important to ground that in specific problem
scenarios.  We can get lost in theories about idempotence and
where resources end and representations begin, but do those
weaknesses in the description really bring the design to a halt?
I'm as guilty as the next man of attacking on theoretical
grounds only.  So far, my implementations have only benefitted
from keeping REST in mind.

Thanks,

Walden


> -----Original Message-----
> From: Chuck Hinson [mailto:cmhinson@...]
> Sent: Friday, September 13, 2002 12:03 AM
> Cc: rest-discuss
> Subject: Re: [rest-discuss] REST and the Web
> 
> 
> 
> 
> Miles Sabin wrote:
> 
> >As Walden said: have a cookie ... or an unsafe GET, or an 
> abused POST. 
> >Like it or not, they're everywhere.
> >
> But I dont think HTTP == REST.  HTTP is one part of an 
> application whose 
> architectural style is described by REST.  HTTP is what defines the 
> semantics of GET and POST.  REST only says that the command 
> set should 
> be small and general and that messages should be stateless.
> 
> 
> I think if you look at why people claim the web is 
> successful, you can 
> probably relate most of those claims to some principle of a 
> REST-style 
> architecture.
> 
> For instance, it seems to me that a large part of the web's 
> scalability 
> (performance-wise) is related to the pervasiveness of caches and 
> proxies.  I don't think caches and proxies would work very 
> well if they 
> couln't rely on the majority of messages being stateless.  
> (Caches are 
> great for detecting deviations from REST.)  And, I think caches and 
> proxies would be much harder to implement if the set of 
> commands in HTTP 
> was much larger than it is.
> 
> --Chuck
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
> 






-----------------------------------------------------------------------------------
Post ID:2531
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-13 13:25:08
Subject:[fielding@apache.org: Re: Resources always exist]
Message:

So it looks like DELETE should not return 404.  Interesting.

MB

----- Forwarded message from "Roy T. Fielding" <fielding@...> -----

Return-Path: <uri-request@...>
Date: Fri, 13 Sep 2002 11:16:55 +0200
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: uri <uri@...>
To: Paul Prescod <paul@...>
From: "Roy T. Fielding" <fielding@...>
In-Reply-To: <3D80EE67.9070203@...>
Message-Id: <8C03E059-C6F9-11D6-BB1B-000393753936@...>
Content-Transfer-Encoding: 7bit
Subject: Re: Resources always exist
X-Mailing-List: <uri@...> archive/latest/1079
Sender: uri-request@...
List-Id: <uri.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:uri-request@...?subject=unsubscribe>
X-Spam-Status: No, hits=-3.4 required=5.0
	tests=IN_REP_TO
	version=2.30
X-Spam-Level: 


> But the HTTP spec says:
>
> > The DELETE method requests that the origin server delete the resource
> > identified by the Request-URI.
>
> What does "delete the resource" mean if resources always exist? Should 
> DELETE be understood to clear the mapping from resources to 
> representations?

Yes, but as far as the interface is concerned they mean the same thing.
What is the difference between a resource that is DELETEd and later PUT,
versus one that has no mapped representations between those two events?

There are a lot of things not mentioned in the HTTP specification, for
one reason or another unrelated to technology.

....Roy


----- End forwarded message -----

-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2532
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-13 15:47:59
Subject:RE: [rest-discuss] [fielding@apache.org: Re: Resources always exi st]
Message:

Does Roy mean that all resources exist always, even prior to
their identification by the relevant naming authority?  Or does
he mean that once a resource is born, it always exists, even
after it's been deleted?

I think it must be the latter, else we have to ask what the
meaning of "Created" is in response to some PUT or POST.

As an implementation detail, it may be difficult for server software
to keep track of all deleted resources that may have once existed,
given that resource space is effectively infinite.

If someone does a DELETE on a resource that has never existed,
should the server discriminate that case against the case of a
deleted resource?  I don't think so...

Perhaps a better way to think of it is thus:  DELETE is idempotent
in the sense that it describes an end-state of a resource, not
a method.  So, the existence of a resource is not an important
pre-condition for DELETE.  A 200 response to DELETE always means
"okay, it's not mapped (now)".  And who cares how we got to that
state.

Walden


> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Friday, September 13, 2002 9:25 AM
> To: rest-discuss@yahoogroups.com
> Subject: [rest-discuss] [fielding@...: Re: Resources always
> exist]
> 
> 
> So it looks like DELETE should not return 404.  Interesting.
> 
> MB
> 
> ----- Forwarded message from "Roy T. Fielding" 
> <fielding@...> -----
> 
> Return-Path: <uri-request@...>
> Date: Fri, 13 Sep 2002 11:16:55 +0200
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> Mime-Version: 1.0 (Apple Message framework v482)
> Cc: uri <uri@...>
> To: Paul Prescod <paul@...>
> From: "Roy T. Fielding" <fielding@...>
> In-Reply-To: <3D80EE67.9070203@...>
> Message-Id: <8C03E059-C6F9-11D6-BB1B-000393753936@...>
> Content-Transfer-Encoding: 7bit
> Subject: Re: Resources always exist
> X-Mailing-List: <uri@...> archive/latest/1079
> Sender: uri-request@...
> List-Id: <uri.w3.org>
> List-Help: <http://www.w3.org/Mail/>
> List-Unsubscribe: <mailto:uri-request@...?subject=unsubscribe>
> X-Spam-Status: No, hits=-3.4 required=5.0
> 	tests=IN_REP_TO
> 	version=2.30
> X-Spam-Level: 
> 
> 
> > But the HTTP spec says:
> >
> > > The DELETE method requests that the origin server delete 
> the resource
> > > identified by the Request-URI.
> >
> > What does "delete the resource" mean if resources always 
> exist? Should 
> > DELETE be understood to clear the mapping from resources to 
> > representations?
> 
> Yes, but as far as the interface is concerned they mean the 
> same thing.
> What is the difference between a resource that is DELETEd and 
> later PUT,
> versus one that has no mapped representations between those 
> two events?
> 
> There are a lot of things not mentioned in the HTTP specification, for
> one reason or another unrelated to technology.
> 
> ....Roy
> 
> 
> ----- End forwarded message -----
> 
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Home Selling? Try Us!
> http://us.click.yahoo.com/QrPZMC/iTmEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
> 






-----------------------------------------------------------------------------------
Post ID:2533
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-13 16:01:09
Subject:Re: [rest-discuss] [fielding@apache.org: Re: Resources always exi st]
Message:

I don't know (general response, not to any particular point).

It seems there's quite a disconnect between the WebDAV "resource=
representation" view of things, which PUT - and now DELETE -
appear to be intended to support, versus the uniform interface
approach of REST.  I'm positive that our interpretation of GET will
remain unscathed.  I *expect* POST will be fine too, but I'm not
certain.

Anyhow, somebody should write this model down so that an extended
interface could be properly designed to support it.  It could end
with a clutter of new methods like SET, REMOVE, etc.. but should
ultimately be pretty valuable.

I'd be happy to design the interface after the model has been
described, but I don't think I'm the best person to design the
model, since my first stab at my "abstract model" is clearly
lacking in important ways, as this discussion has revealed.

MB

On Fri, Sep 13, 2002 at 11:47:59AM -0400, Mathews, Walden wrote:
> Does Roy mean that all resources exist always, even prior to
> their identification by the relevant naming authority?  Or does
> he mean that once a resource is born, it always exists, even
> after it's been deleted?
> 
> I think it must be the latter, else we have to ask what the
> meaning of "Created" is in response to some PUT or POST.
> 
> As an implementation detail, it may be difficult for server software
> to keep track of all deleted resources that may have once existed,
> given that resource space is effectively infinite.
> 
> If someone does a DELETE on a resource that has never existed,
> should the server discriminate that case against the case of a
> deleted resource?  I don't think so...
> 
> Perhaps a better way to think of it is thus:  DELETE is idempotent
> in the sense that it describes an end-state of a resource, not
> a method.  So, the existence of a resource is not an important
> pre-condition for DELETE.  A 200 response to DELETE always means
> "okay, it's not mapped (now)".  And who cares how we got to that
> state.
> 
> Walden
> 
> 
> > -----Original Message-----
> > From: Mark Baker [mailto:distobj@...]
> > Sent: Friday, September 13, 2002 9:25 AM
> > To: rest-discuss@yahoogroups.com
> > Subject: [rest-discuss] [fielding@...: Re: Resources always
> > exist]
> > 
> > 
> > So it looks like DELETE should not return 404.  Interesting.
> > 
> > MB
> > 
> > ----- Forwarded message from "Roy T. Fielding" 
> > <fielding@...> -----
> > 
> > Return-Path: <uri-request@...>
> > Date: Fri, 13 Sep 2002 11:16:55 +0200
> > Content-Type: text/plain; charset=US-ASCII; format=flowed
> > Mime-Version: 1.0 (Apple Message framework v482)
> > Cc: uri <uri@...>
> > To: Paul Prescod <paul@...>
> > From: "Roy T. Fielding" <fielding@...>
> > In-Reply-To: <3D80EE67.9070203@...>
> > Message-Id: <8C03E059-C6F9-11D6-BB1B-000393753936@...>
> > Content-Transfer-Encoding: 7bit
> > Subject: Re: Resources always exist
> > X-Mailing-List: <uri@...> archive/latest/1079
> > Sender: uri-request@...
> > List-Id: <uri.w3.org>
> > List-Help: <http://www.w3.org/Mail/>
> > List-Unsubscribe: <mailto:uri-request@...?subject=unsubscribe>
> > X-Spam-Status: No, hits=-3.4 required=5.0
> > 	tests=IN_REP_TO
> > 	version=2.30
> > X-Spam-Level: 
> > 
> > 
> > > But the HTTP spec says:
> > >
> > > > The DELETE method requests that the origin server delete 
> > the resource
> > > > identified by the Request-URI.
> > >
> > > What does "delete the resource" mean if resources always 
> > exist? Should 
> > > DELETE be understood to clear the mapping from resources to 
> > > representations?
> > 
> > Yes, but as far as the interface is concerned they mean the 
> > same thing.
> > What is the difference between a resource that is DELETEd and 
> > later PUT,
> > versus one that has no mapped representations between those 
> > two events?
> > 
> > There are a lot of things not mentioned in the HTTP specification, for
> > one reason or another unrelated to technology.
> > 
> > ....Roy
> > 
> > 
> > ----- End forwarded message -----
> > 
> > -- 
> > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> > Ottawa, Ontario, CANADA.               distobj@...
> > http://www.markbaker.ca        http://www.idokorro.com
> > 
> > ------------------------ Yahoo! Groups Sponsor 
> > ---------------------~-->
> > Home Selling? Try Us!
> > http://us.click.yahoo.com/QrPZMC/iTmEAA/MVfIAA/W6uqlB/TM
> > --------------------------------------------------------------
> > -------~->
> > 
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> > 
> >  
> > 
> > Your use of Yahoo! Groups is subject to 
> > http://docs.yahoo.com/info/terms/ 
> > 
> > 

-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2534
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-13 16:24:14
Subject:RE: [rest-discuss] [fielding@apache.org: Re: Resources always exi st]
Message:

I'm very interested in formalizing the model you're talking about,
armed at the start at least with a modeling tool called Alloy,
which I have some limited familiarity with but which happens to
provide the benefit of automated model checking.

I understand that RDF is a more appropriate end goal for
expression and also better known within this group, so even if
initial attempts are done in RDF, I'll try to parallel that
in Alloy for my own personal reaons.

However, I don't feel I have a firm enough handle on what the
model needs to express to go this alone.  So if someone will start
to compile some informal material toward that model, I'll definitely
get involved with its formalization and perhaps also be able to
contribute to its scope.

Where do we start?  Do we take what Mark already has and start
tweaking, or something else?  Does this belong on rest-discuss or
on some other list?  What's the overall level of interest?

Walden

> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Friday, September 13, 2002 12:01 PM
> To: Mathews, Walden
> Cc: 'Mark Baker'; rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] [fielding@...: Re: Resources always
> exi st]
> 
> 
> I don't know (general response, not to any particular point).
> 
> It seems there's quite a disconnect between the WebDAV "resource=
> representation" view of things, which PUT - and now DELETE -
> appear to be intended to support, versus the uniform interface
> approach of REST.  I'm positive that our interpretation of GET will
> remain unscathed.  I *expect* POST will be fine too, but I'm not
> certain.
> 
> Anyhow, somebody should write this model down so that an extended
> interface could be properly designed to support it.  It could end
> with a clutter of new methods like SET, REMOVE, etc.. but should
> ultimately be pretty valuable.
> 
> I'd be happy to design the interface after the model has been
> described, but I don't think I'm the best person to design the
> model, since my first stab at my "abstract model" is clearly
> lacking in important ways, as this discussion has revealed.
> 
> MB
> 
> On Fri, Sep 13, 2002 at 11:47:59AM -0400, Mathews, Walden wrote:
> > Does Roy mean that all resources exist always, even prior to
> > their identification by the relevant naming authority?  Or does
> > he mean that once a resource is born, it always exists, even
> > after it's been deleted?
> > 
> > I think it must be the latter, else we have to ask what the
> > meaning of "Created" is in response to some PUT or POST.
> > 
> > As an implementation detail, it may be difficult for server software
> > to keep track of all deleted resources that may have once existed,
> > given that resource space is effectively infinite.
> > 
> > If someone does a DELETE on a resource that has never existed,
> > should the server discriminate that case against the case of a
> > deleted resource?  I don't think so...
> > 
> > Perhaps a better way to think of it is thus:  DELETE is idempotent
> > in the sense that it describes an end-state of a resource, not
> > a method.  So, the existence of a resource is not an important
> > pre-condition for DELETE.  A 200 response to DELETE always means
> > "okay, it's not mapped (now)".  And who cares how we got to that
> > state.
> > 
> > Walden
> > 
> > 
> > > -----Original Message-----
> > > From: Mark Baker [mailto:distobj@...]
> > > Sent: Friday, September 13, 2002 9:25 AM
> > > To: rest-discuss@yahoogroups.com
> > > Subject: [rest-discuss] [fielding@...: Re: Resources always
> > > exist]
> > > 
> > > 
> > > So it looks like DELETE should not return 404.  Interesting.
> > > 
> > > MB
> > > 
> > > ----- Forwarded message from "Roy T. Fielding" 
> > > <fielding@...> -----
> > > 
> > > Return-Path: <uri-request@...>
> > > Date: Fri, 13 Sep 2002 11:16:55 +0200
> > > Content-Type: text/plain; charset=US-ASCII; format=flowed
> > > Mime-Version: 1.0 (Apple Message framework v482)
> > > Cc: uri <uri@...>
> > > To: Paul Prescod <paul@...>
> > > From: "Roy T. Fielding" <fielding@...>
> > > In-Reply-To: <3D80EE67.9070203@...>
> > > Message-Id: <8C03E059-C6F9-11D6-BB1B-000393753936@...>
> > > Content-Transfer-Encoding: 7bit
> > > Subject: Re: Resources always exist
> > > X-Mailing-List: <uri@...> archive/latest/1079
> > > Sender: uri-request@...
> > > List-Id: <uri.w3.org>
> > > List-Help: <http://www.w3.org/Mail/>
> > > List-Unsubscribe: <mailto:uri-request@...?subject=unsubscribe>
> > > X-Spam-Status: No, hits=-3.4 required=5.0
> > > 	tests=IN_REP_TO
> > > 	version=2.30
> > > X-Spam-Level: 
> > > 
> > > 
> > > > But the HTTP spec says:
> > > >
> > > > > The DELETE method requests that the origin server delete 
> > > the resource
> > > > > identified by the Request-URI.
> > > >
> > > > What does "delete the resource" mean if resources always 
> > > exist? Should 
> > > > DELETE be understood to clear the mapping from resources to 
> > > > representations?
> > > 
> > > Yes, but as far as the interface is concerned they mean the 
> > > same thing.
> > > What is the difference between a resource that is DELETEd and 
> > > later PUT,
> > > versus one that has no mapped representations between those 
> > > two events?
> > > 
> > > There are a lot of things not mentioned in the HTTP 
> specification, for
> > > one reason or another unrelated to technology.
> > > 
> > > ....Roy
> > > 
> > > 
> > > ----- End forwarded message -----
> > > 
> > > -- 
> > > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> > > Ottawa, Ontario, CANADA.               distobj@...
> > > http://www.markbaker.ca        http://www.idokorro.com
> > > 
> > > ------------------------ Yahoo! Groups Sponsor 
> > > ---------------------~-->
> > > Home Selling? Try Us!
> > > http://us.click.yahoo.com/QrPZMC/iTmEAA/MVfIAA/W6uqlB/TM
> > > --------------------------------------------------------------
> > > -------~->
> > > 
> > > To unsubscribe from this group, send an email to:
> > > rest-discuss-unsubscribe@yahoogroups.com
> > > 
> > >  
> > > 
> > > Your use of Yahoo! Groups is subject to 
> > > http://docs.yahoo.com/info/terms/ 
> > > 
> > > 
> 
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
> 






-----------------------------------------------------------------------------------
Post ID:2535
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-13 16:35:06
Subject:formalizing a model (was Re: [fielding@apache.org: Re: Resources always exi st]
Message:

----- Original Message -----
From: "Mathews, Walden" <waldenm@...>
>
> Where do we start?  Do we take what Mark already has and start
> tweaking, or something else?  Does this belong on rest-discuss or
> on some other list?  What's the overall level of interest?
>
> > -----Original Message-----
> > From: Mark Baker [mailto:distobj@...]
> >
> > Anyhow, somebody should write this model down so that an extended
> > interface could be properly designed to support it.  It could end
> > with a clutter of new methods like SET, REMOVE, etc.. but should
> > ultimately be pretty valuable.

What/which model are we talking about here?  Can someone list a few aspects
of what this model is about?  I'm always interested in helping in this sort
of thing, but I am having trouble figuring out what the model is in the
first place.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2536
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-13 16:36:01
Subject:Re: [rest-discuss] [fielding@apache.org: Re: Resources always exist]
Message:

I'm not sure I agree with that.  I do agree that DELETE is invalidating the
mapping (the mapping from representation to resource), not necessarily the
resource.  However, if I were to issue a DELETE on an invalid identifier, I
think it would be legitimate to return a 404.  As RFC2616 notes, you could
also return 410 in this case (if the server bothered to keep track).
Certainly 410 would be more accurate than 404, but either should be allowed.
In this perspective, the server is actually talking about the mapping.  As
Fielding was saying (I think), from the POV of the request, not finding a
resource and not finding a mapping to a resource are just different ways of
saying the same thing.

---
Seairth Jacobs
seairth@...


----- Original Message -----
From: "Mark Baker" <distobj@...>
To: <rest-discuss@yahoogroups.com>
Sent: Friday, September 13, 2002 9:25 AM
Subject: [rest-discuss] [fielding@...: Re: Resources always exist]


> So it looks like DELETE should not return 404.  Interesting.
>
> MB
>
> ----- Forwarded message from "Roy T. Fielding" <fielding@...> -----
>
> Return-Path: <uri-request@...>
> Date: Fri, 13 Sep 2002 11:16:55 +0200
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> Mime-Version: 1.0 (Apple Message framework v482)
> Cc: uri <uri@...>
> To: Paul Prescod <paul@...>
> From: "Roy T. Fielding" <fielding@...>
> In-Reply-To: <3D80EE67.9070203@...>
> Message-Id: <8C03E059-C6F9-11D6-BB1B-000393753936@...>
> Content-Transfer-Encoding: 7bit
> Subject: Re: Resources always exist
> X-Mailing-List: <uri@...> archive/latest/1079
> Sender: uri-request@...
> List-Id: <uri.w3.org>
> List-Help: <http://www.w3.org/Mail/>
> List-Unsubscribe: <mailto:uri-request@...?subject=unsubscribe>
> X-Spam-Status: No, hits=-3.4 required=5.0
> tests=IN_REP_TO
> version=2.30
> X-Spam-Level:
>
>
> > But the HTTP spec says:
> >
> > > The DELETE method requests that the origin server delete the resource
> > > identified by the Request-URI.
> >
> > What does "delete the resource" mean if resources always exist? Should
> > DELETE be understood to clear the mapping from resources to
> > representations?
>
> Yes, but as far as the interface is concerned they mean the same thing.
> What is the difference between a resource that is DELETEd and later PUT,
> versus one that has no mapped representations between those two events?
>
> There are a lot of things not mentioned in the HTTP specification, for
> one reason or another unrelated to technology.
>
> ....Roy
>
>
> ----- End forwarded message -----
>
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>







-----------------------------------------------------------------------------------
Post ID:2537
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-13 16:49:29
Subject:RE: [rest-discuss] [fielding@apache.org: Re: Resources always exi st]
Message:

I'm not sure I agree with THAT.  First, RFC2616 doesn't mention
response code 404 in the context of DELETE, which your statement
below implies.  Second, "The 410 response is primarily intended to
assist the task of web maintenance."  If I DELETE a resource
successfully, then I know that the resource is now unmapped with
respect to representations.  How does it help me further in
the service of web maintenance to get an indication that is was
already unmapped?

Certainly this is different from the question of which is better,
410 or 404, to return from a GET when the resource is unmapped.
RFC2616 seems to be focused on specifying that, not the response
codes for a DELETE.  That's my reading; it's not clear in the spec.

Walden

> -----Original Message-----
> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Friday, September 13, 2002 12:36 PM
> To: rest-discuss
> Subject: Re: [rest-discuss] [fielding@...: Re: Resources always
> exist]
> 
> 
> I'm not sure I agree with that.  I do agree that DELETE is 
> invalidating the
> mapping (the mapping from representation to resource), not 
> necessarily the
> resource.  However, if I were to issue a DELETE on an invalid 
> identifier, I
> think it would be legitimate to return a 404.  As RFC2616 
> notes, you could
> also return 410 in this case (if the server bothered to keep track).
> Certainly 410 would be more accurate than 404, but either 
> should be allowed.
> In this perspective, the server is actually talking about the 
> mapping.  As
> Fielding was saying (I think), from the POV of the request, 
> not finding a
> resource and not finding a mapping to a resource are just 
> different ways of
> saying the same thing.
> 
> ---
> Seairth Jacobs
> seairth@...
> 
> 
> ----- Original Message -----
> From: "Mark Baker" <distobj@...>
> To: <rest-discuss@yahoogroups.com>
> Sent: Friday, September 13, 2002 9:25 AM
> Subject: [rest-discuss] [fielding@...: Re: Resources 
> always exist]
> 
> 
> > So it looks like DELETE should not return 404.  Interesting.
> >
> > MB
> >
> > ----- Forwarded message from "Roy T. Fielding" 
> <fielding@...> -----
> >
> > Return-Path: <uri-request@...>
> > Date: Fri, 13 Sep 2002 11:16:55 +0200
> > Content-Type: text/plain; charset=US-ASCII; format=flowed
> > Mime-Version: 1.0 (Apple Message framework v482)
> > Cc: uri <uri@...>
> > To: Paul Prescod <paul@...>
> > From: "Roy T. Fielding" <fielding@...>
> > In-Reply-To: <3D80EE67.9070203@...>
> > Message-Id: <8C03E059-C6F9-11D6-BB1B-000393753936@...>
> > Content-Transfer-Encoding: 7bit
> > Subject: Re: Resources always exist
> > X-Mailing-List: <uri@...> archive/latest/1079
> > Sender: uri-request@...
> > List-Id: <uri.w3.org>
> > List-Help: <http://www.w3.org/Mail/>
> > List-Unsubscribe: <mailto:uri-request@...?subject=unsubscribe>
> > X-Spam-Status: No, hits=-3.4 required=5.0
> > tests=IN_REP_TO
> > version=2.30
> > X-Spam-Level:
> >
> >
> > > But the HTTP spec says:
> > >
> > > > The DELETE method requests that the origin server 
> delete the resource
> > > > identified by the Request-URI.
> > >
> > > What does "delete the resource" mean if resources always 
> exist? Should
> > > DELETE be understood to clear the mapping from resources to
> > > representations?
> >
> > Yes, but as far as the interface is concerned they mean the 
> same thing.
> > What is the difference between a resource that is DELETEd 
> and later PUT,
> > versus one that has no mapped representations between those 
> two events?
> >
> > There are a lot of things not mentioned in the HTTP 
> specification, for
> > one reason or another unrelated to technology.
> >
> > ....Roy
> >
> >
> > ----- End forwarded message -----
> >
> > --
> > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> > Ottawa, Ontario, CANADA.               distobj@...
> > http://www.markbaker.ca        http://www.idokorro.com
> >
> >
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/
> >
> >
> >
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
> 






-----------------------------------------------------------------------------------
Post ID:2538
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-13 16:54:36
Subject:Existance of Resources (was Re: [fielding@apache.org: Re: Resources always exist])
Message:

----- Original Message -----
From: "Mathews, Walden" <waldenm@...>
>> Does Roy mean that all resources exist always, even prior to
> their identification by the relevant naming authority?  Or does
> he mean that once a resource is born, it always exists, even
> after it's been deleted?
>
> I think it must be the latter, else we have to ask what the
> meaning of "Created" is in response to some PUT or POST.

I look at it this way:

Resources can be seen from two points of view: the client and the server.
>From the server POV, the resource exists exactly as long as the server wants
it to exist.  The server brings it into being and the server destroys it as
well.  I suppose you could think of the server as being omniscient with
respect to the resources it controls.  On the other hand, from the client
POV, the resource only exists as long as it can be identified.  In other
words, the client knows the existance a resource once it has obtained an
identifier that is mapped to that resource.  When the identifier becomes
invalid (via DELETE, for instance), the resource ceases to exist to the
client (regardless of whether the server's POV says it still exist or not).

> As an implementation detail, it may be difficult for server software
> to keep track of all deleted resources that may have once existed,
> given that resource space is effectively infinite.
>
> If someone does a DELETE on a resource that has never existed,
> should the server discriminate that case against the case of a
> deleted resource?  I don't think so...
>
> Perhaps a better way to think of it is thus:  DELETE is idempotent
> in the sense that it describes an end-state of a resource, not
> a method.  So, the existence of a resource is not an important
> pre-condition for DELETE.  A 200 response to DELETE always means
> "okay, it's not mapped (now)".  And who cares how we got to that
> state.

A response of 200 would certainly make the interface less complicated.  I
have to admit that having the server decide between 200, 404, and 410 and
having the client distinguish the responses is potentially unnecessary
overhead.  However, the one thing that 200 (used in this case) does not tell
you is whether the mapping did exist or not.  So, supposing you meant to
delete a mapping and accidentally entered the identifier wrong.  The server
would not tell you that you gave an invalid identifier.  On the other hand,
this could be avoided by performing a GET prior to the DELETE when this was
important.  The trade-off here is whether you increase code and reduce
network traffic by using more than one response, or vice versa.  In the end,
I'd say provide support for both and leave it up to the application-level
semantics to determine which to use.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2539
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-13 17:06:14
Subject:RE: [rest-discuss] Existance of Resources (was Re: [fielding@apac he.org: Re: Resources always exist])
Message:

Seairth Jacobs wrote:

> ... However, the one thing that 200 (used in this 
> case) does not tell
> you is whether the mapping did exist or not.  So, supposing 
> you meant to
> delete a mapping and accidentally entered the identifier 
> wrong.  The server
> would not tell you that you gave an invalid identifier.

I feel most strongly that that problem is out of scope for a
definition of the HTTP protocol.  Think about all the other
undesirable effects that occur when you dereference the wrong
thing and how impossible or infeasible it is to design
recovery from that into a 'transfer' protocol.  I've seen
designs that attempt to go there and they all suck big time.
I work on a system like that now.  It almost chokes on its
own transaction excreta.

Walden 






-----------------------------------------------------------------------------------
Post ID:2540
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-12 18:06:24
Subject:Rediscovering Web Architecture from first principles
Message:

    = Addressing =

The Web is first and foremost a publishing platform. It is used to
publish information and services.

We will start with the question of the best way to publish information.
There are two basic strategies possible: one is to describe uniquely for
each information object how to fetch it. Another is to standardize the
fetching mechanism and instead specify only the minimal information
required to actually do the fetch: an "address".

The older FTP protocol uses the first model. When you wanted someone to 
download something through FTP you would give them instructions about 
how to log into an FTP site, switch to the appropriate directory and get 
the appropriate file. Conversely, HTTP leaves only one free parameter: 
the address. Everything else falls out of that. You do not need to 
choose the method that is used: it is always GET. You do not need to 
decide what server to issue the command to: the address of the 
recommended server is embedded in the address ("Uniform Resource 
identifier", or "URI").

This leads us to the Web principle that all resources should be
identifiable by unique address so that they can be fetched with only GET 
and the address.

    = Uniform Interface =

Standardizing the means of information download is important for
maximizing the number of applications that can download information
without necessarily understanding the semantics of the information they
are downloading. Examples include caching and prefetching
proxies, command line downloading tools, web browsers, spiders and XSLT
engines.

Any architecture that has multiple ways of saying "get me some
information" will experience interoperability problems that the Web
avoids by having a few, globally optimized ways of doing so (basically
HTTP and FTP GET methods).

Because HTTP's GET is used by such a wide variety of tools, it is
necessary that it have very clear semantics. For instance, a GET cannot
be interpreted as signing a user up for a service or a prefetching cache
or spider could sign the user up just by doing its job. Therefore the
Web says that end-users are not responsible for any side effects of GET.
    Services should not use GET in ways that cause side effects.

Let me stress a point made earlier: any architecture that allows every
end-node to choose its own mechanism for delivering information (SOAP
RPC, CORBA, ...) is strictly less powerful and less interoperable than
an architecture that has a single, standardized way to deliver
information because it means that every potential consumer of
information resources must be customized to talk to every publisher of
information. This is an interoperability nightmare.

The concensus on this point is sufficiently strong that the W3C has
extended SOAP 1.2 to support HTTP GET so that it would better take
advantage of the features of web architecture.

    = Hypermedia =

But simply returning named information is not always enough. Often the
client application or human web surfer will not know exactly what
information they need in advance. Essentially they need to be given a
menu of options so that they may choose the appropriate one. For
instance a flight-purchasing agent might be presented with a list of
flights and might choose the "best" one based on a complex algorithm
that depends upon price, flight length and flight time. In this case, we
need an information object (a flight list) that refers to other
information objects (the flights). A data representation that has
references embedded among data is known in Web terminology as "hypermedia".

Listing things is a wonderful way of helping a client navigate to
information because they know exactly what is available and sometimes
knowing the list is as or more important as having access to any 
particular item.

Google is an example of an application that really does not care about
any particular page on your site much, but cares very much about
ensuring that it has a relatively complete list of pages. So hypermedia
is a very important part of web architecture because it allows
discovery. Where possible, information delivered on the Web should be
organized into webs of hyperlinked hypermedia documents.

Because the Web is basically a flat, global address space (modulo
machines behind firewalls etc.), any resource can refer to any other
resource, no matter whether they use the same data representation or
even the same access protocol (e.g. HTTP versus FTP). This promiscuous
connectedness is what makes the Web so great and important!

The great thing about using hypermedia as an organizational model for
information repositories and services is that one process or individual
can direct another process or individual to look at and deal with a
particular resource by address and can choose the appropriate amount of
context. For instance, you can direct a purchase order processing
application to a particular purchase order rather than to a whole
"purchase order application". This is in contrast to dominant web
services methodologies that hide many resources behind a single URI and
therefore makes addressing those individual resources impossible.
Imagine if someone wanted to send you a link to the Wall Street Journal
and required you to always go to the front screen!

    = Queries =

Sometimes the information provider has such a large database of
information that it is not practically (or economically) feasible for it
to deliver to the requestor in total or even to segment into many
hypermedia documents. The requestor needs to specify some reasonable
filter. This is a fallback position because it becomes difficult or
impossible for the requestor to enumerate all of the information items
even if this might be useful or important. Nevertheless, reality
requires that sometimes filtering happen on the server side and the Web
allows this through HTTP URI "query parameters".

The beautiful part of query parameters is that they are expressed as
part of the URI so that all of the tools we've built up for downloading
ordinary hyperdocument resources and lists of hyperdocument resources
can also be used on filtered lists of hyperdocument resources. The only
difference is that in this case, the URI is partially constructed by the
client application, under instructions from the server, rather than
being constructed by the server and being totally opaque to the server.
But once the URI is constructed, it is as bonified a URI as any other
one and may be put into any slot expecting a URI. They can be
"promiscuously connected", cached, downloaded with command line tools,
and so forth.

    = Representations =

As the Web evolves it becomes increasingly clear that the concepts
addressed by URIs and the bits available at those URIs have distinct
lifecycles and properties. "www.theonion.com" is a news magazine. I
cannot predict what bits you will get if you dereference on the day you
read this essay. In order to discuss this distinction, we need words for
the thing that is addressed and the bits you get by going there on a
particular day, with a particular user agent, etc. The concept is known
as a "resource". The bits are known as a "representation".

Representations have media-types. Resources do not. In-so-far as
resources are "typed" (and HTTP has nothing to say about this) you might
say that they are typed by RDF. The distinction between representation
and resource allows us a very powerful form of extensibility and
adaptability. The Web has a feature called content negotiation which
allows resource consumers to ask for the resource in a variety of
different representations. One representation might be WML optimized for
hand-held computers. Another might be XHTML optimized for browsers.
Others might be PDF optimized for printers and RDF optimized for machine
discovery. As new standards come into existence, they can be served as
new representations for the information, enabling evolution of the
resource without backwards compatibility problems.

This is a good point to emphasize something that has been so-far
implicit. There is nothing in the Web architecture which is specific to
interactions with a human being at one end and a machine at the other.
Existing information resources can be made machine-accessible by adding
an XML (or XML/RDF) representation alongside existing HTML
representations. Human beings are one kind of client for web resources.
Machines are another.

    = Services =

So far we have described the Web as an information publishing platform.
But over the years it has also become the world's leading service
publishing platform. There are services for bidding on auctions, booking 
flights, generating insults and anything else you might dream of. The
biggest distinction between publishing information and publishing a
service is that the service may require the service provider and client
working together to generate new resources, change existing resources or
delete resources. In other words the conversation is two-way rather than
one-way.

Now before we go into detail on services I want to point out that an
important sub-task in publishing almost any service is publishing
information either held by or relating to that service. There is a
tendency to forget this when developing services using technologies such
as SOAP and XML-RPC. For instance a part of a stock purchasing service
might include a means to get the stock price. The traditional
SOAP/XML-RPC way to do this is to invent a new method called
getStockPrice. I have already discussed the interoperability limitations
of this model. So the first thing to remember about publishing services
is that whatever you do, do not neglect the information publishing part
of your service. If it can benefit from the web architecture features
described above, use them.

The second important thing to remember about publishing services is that
publishing information is crucial for the flexibility, reliability and
scalability of your service. Let's deal with each of these in turn.
Imagine a service that allows the client and server to work together to
generate a purchase order. Now they need to decide what to do with the
generated purchase order. One option is that each of them can give the
order a unique identifier (e.g. "PO number") and maintain a local copy
of it. This arrangement makes it difficult to bring third parties into
the conversation and to utilize URI-aware tools like spiders, caches,
inferencers and XSLT transformation engines. It would be better to give
the purchase order its own URI. Generally, if there is information that
is of interest to both or all participants in a conversation, that
information should be given a URI so that new participants can be easily
brought in after the fact.

Another aspect of flexibility is allowing a variety of different kinds
of clients. As long as the purchase order has a URI, the client can
decide how stateful or stateless it should be. If it wants to keep a
copy of the purchase order it can (more robust and paranoid clients
will). But if it wants to let the server manage it, it can merely keep
the URI and refresh from the server when it needs information. In a case
where the server is allowed to unilaterally change the information
resource (i.e. not a purchase order), the client can always get the
latest version of the resource using a GET.

Emphasizing the information publishing portion of your service is also
important for reliability reasons. Continuing with the purchase order
example, consider what would happen if the client party missed a message
or had its state corrupted during the communication. As long as all
relevant information has been exposed on the server as URIs, it could
rebuild its state with nothing more than the URI representing the
resource. Conversely, in situations where the state of the conversation
is implicit, one lost message can throw the client irreconcilably out of
sync with the server. Of course if the service consumer somehow loses
the URI for the thing it is talking about (e.g. the purchase order URI)
then you are in trouble. But even then you can use discovery and query
techniques to re-establish contact. For this and other reasons, resource
discovery should always be an important part of service design.

Finally there is the issue of scalability. It is often the case that
once an information resource has been created, a representation of it is
retrieved many times. Even a purchase order may be read over and over
again by internal and external auditors and order fulfillment systems.
Using standard web techniques, these representations can be cached.

So far, I've tried to show how information publishing is a crucial part
of all service publishing projects and thus to show that the service
publishing problem is an _extension_ of the information publishing
problem, not a different problem altogether. Next we will describe how
we can extend the web architecture into service publishing.

   = Resource construction and mutation =

Consider a service like buying sneakers. There are three reasons that we
need to move beyond the GET-based web we have described. First, we will
want to create purchase orders, so we need a way to create objects.
Second, we need information to flow from the customer to the service
provider rather than vice versa. Third, we need to allow the "side
effect" of actually shipping the shoes.

The HTTP method designed for creating and mutating objects, with
possible side effects, is POST. POST is neither more nor less powerful
than GET. It is just different. GET's safety (side-effect-freeness)
means that clients have extreme flexibility in structuring applications
that rely heavily on GET. In particular, GET allows very "declarative"
applications that say what needs to be done but does not provide any
instructions on how to do it. For instance if an XSLT stylesheet needs
to deal with an XML element inside of a web resource it can retrieve
that document once, or ten times, or a hundred times, at its own
discretion. It might choose to do it once to optimize for bandwidth or a
hundred times to optimize for client-side memory space. If the XSLT is
using multiple documents, it can also choose the order that it retreives
them at its own discretion.

But if you do need side-effects then you need to give up some of GETs
advantages. Then you need POST. Because POST invocations may have side 
effects, you must be very careful about the order in which you invoke 
POST methods. You need to add the shoes to the shopping cart before you 
checkout of the online store and not vice versa.

POST has another related strength/weakness. The input to GET is very 
simple: basically just an address. The Web infrastructure strongly 
encourages you to move retrievable information into an addressable URI. 
But when the service provider and client are working together to create 
new resources or modify existing ones, they both need to contribute 
information. This requires a higher level of coordination which makes 
POST-based integration more difficult than GET-based integration. But 
this is the price of solving the more difficult problem of building 
information resources rather than simply delivering them.

POST and GET work together in important ways. Using GET-based navigation 
you can find the service you want to invoke. It could even report its 
quality of service characteristics, terms and conditions and so forth. 
Then you use POST to invoke it. This will usually either mutate or 
create a resource. This resource has a URI that you can use GET to 
retrieve whenever you need it. You can also refer third parties at the 
resource via its URI and they can GET it. There is no need to coordinate 
who GETs first or how many times you GET because GET is safe and idempotent.

POST can handle any operation which changes client-side state in a 
manner that would be inappropriate for GET. But there are two operations 
that have pretty clear semantics that can be separated out from the mass 
of POST-based actions. Sometimes you have a URI and you want to 
overwrite its content. For instance you load a document into your word 
processor, make a few changes and want to save it back. Or you are 
maintaining a stock quote service and it is your job to udpdate the 
quotes as the most recently quoted price change. PUT allows these. The 
other operation is DELETE for destroying resources (i.e. making them 
into 404s).










-----------------------------------------------------------------------------------
Post ID:2541
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-13 21:13:22
Subject:RE: [rest-discuss] Rediscovering Web Architecture from first pri nciples
Message:

Paul,

Stayed late at my desk on a Friday afternoon to read all the
way through.  Nicely done, especially the part that explains
why we need both resources and representations.  Very clear.

Walden

> -----Original Message-----
> From: Paul Prescod [mailto:paul@...]
> Sent: Thursday, September 12, 2002 2:06 PM
> To: rest-discuss@yahoogroups.com
> Subject: [rest-discuss] Rediscovering Web Architecture from first
> principles
> 
> 
>     = Addressing =
> 
> The Web is first and foremost a publishing platform. It is used to
> publish information and services.
> 
> We will start with the question of the best way to publish 
> information.
> There are two basic strategies possible: one is to describe 
> uniquely for
> each information object how to fetch it. Another is to standardize the
> fetching mechanism and instead specify only the minimal information
> required to actually do the fetch: an "address".
> 
> The older FTP protocol uses the first model. When you wanted 
> someone to 
> download something through FTP you would give them instructions about 
> how to log into an FTP site, switch to the appropriate 
> directory and get 
> the appropriate file. Conversely, HTTP leaves only one free 
> parameter: 
> the address. Everything else falls out of that. You do not need to 
> choose the method that is used: it is always GET. You do not need to 
> decide what server to issue the command to: the address of the 
> recommended server is embedded in the address ("Uniform Resource 
> identifier", or "URI").
> 
> This leads us to the Web principle that all resources should be
> identifiable by unique address so that they can be fetched 
> with only GET 
> and the address.
> 
>     = Uniform Interface =
> 
> Standardizing the means of information download is important for
> maximizing the number of applications that can download information
> without necessarily understanding the semantics of the 
> information they
> are downloading. Examples include caching and prefetching
> proxies, command line downloading tools, web browsers, 
> spiders and XSLT
> engines.
> 
> Any architecture that has multiple ways of saying "get me some
> information" will experience interoperability problems that the Web
> avoids by having a few, globally optimized ways of doing so (basically
> HTTP and FTP GET methods).
> 
> Because HTTP's GET is used by such a wide variety of tools, it is
> necessary that it have very clear semantics. For instance, a 
> GET cannot
> be interpreted as signing a user up for a service or a 
> prefetching cache
> or spider could sign the user up just by doing its job. Therefore the
> Web says that end-users are not responsible for any side 
> effects of GET.
>     Services should not use GET in ways that cause side effects.
> 
> Let me stress a point made earlier: any architecture that allows every
> end-node to choose its own mechanism for delivering information (SOAP
> RPC, CORBA, ...) is strictly less powerful and less interoperable than
> an architecture that has a single, standardized way to deliver
> information because it means that every potential consumer of
> information resources must be customized to talk to every publisher of
> information. This is an interoperability nightmare.
> 
> The concensus on this point is sufficiently strong that the W3C has
> extended SOAP 1.2 to support HTTP GET so that it would better take
> advantage of the features of web architecture.
> 
>     = Hypermedia =
> 
> But simply returning named information is not always enough. Often the
> client application or human web surfer will not know exactly what
> information they need in advance. Essentially they need to be given a
> menu of options so that they may choose the appropriate one. For
> instance a flight-purchasing agent might be presented with a list of
> flights and might choose the "best" one based on a complex algorithm
> that depends upon price, flight length and flight time. In 
> this case, we
> need an information object (a flight list) that refers to other
> information objects (the flights). A data representation that has
> references embedded among data is known in Web terminology as 
> "hypermedia".
> 
> Listing things is a wonderful way of helping a client navigate to
> information because they know exactly what is available and sometimes
> knowing the list is as or more important as having access to any 
> particular item.
> 
> Google is an example of an application that really does not care about
> any particular page on your site much, but cares very much about
> ensuring that it has a relatively complete list of pages. So 
> hypermedia
> is a very important part of web architecture because it allows
> discovery. Where possible, information delivered on the Web should be
> organized into webs of hyperlinked hypermedia documents.
> 
> Because the Web is basically a flat, global address space (modulo
> machines behind firewalls etc.), any resource can refer to any other
> resource, no matter whether they use the same data representation or
> even the same access protocol (e.g. HTTP versus FTP). This promiscuous
> connectedness is what makes the Web so great and important!
> 
> The great thing about using hypermedia as an organizational model for
> information repositories and services is that one process or 
> individual
> can direct another process or individual to look at and deal with a
> particular resource by address and can choose the appropriate 
> amount of
> context. For instance, you can direct a purchase order processing
> application to a particular purchase order rather than to a whole
> "purchase order application". This is in contrast to dominant web
> services methodologies that hide many resources behind a 
> single URI and
> therefore makes addressing those individual resources impossible.
> Imagine if someone wanted to send you a link to the Wall 
> Street Journal
> and required you to always go to the front screen!
> 
>     = Queries =
> 
> Sometimes the information provider has such a large database of
> information that it is not practically (or economically) 
> feasible for it
> to deliver to the requestor in total or even to segment into many
> hypermedia documents. The requestor needs to specify some reasonable
> filter. This is a fallback position because it becomes difficult or
> impossible for the requestor to enumerate all of the information items
> even if this might be useful or important. Nevertheless, reality
> requires that sometimes filtering happen on the server side 
> and the Web
> allows this through HTTP URI "query parameters".
> 
> The beautiful part of query parameters is that they are expressed as
> part of the URI so that all of the tools we've built up for 
> downloading
> ordinary hyperdocument resources and lists of hyperdocument resources
> can also be used on filtered lists of hyperdocument 
> resources. The only
> difference is that in this case, the URI is partially 
> constructed by the
> client application, under instructions from the server, rather than
> being constructed by the server and being totally opaque to 
> the server.
> But once the URI is constructed, it is as bonified a URI as any other
> one and may be put into any slot expecting a URI. They can be
> "promiscuously connected", cached, downloaded with command line tools,
> and so forth.
> 
>     = Representations =
> 
> As the Web evolves it becomes increasingly clear that the concepts
> addressed by URIs and the bits available at those URIs have distinct
> lifecycles and properties. "www.theonion.com" is a news magazine. I
> cannot predict what bits you will get if you dereference on 
> the day you
> read this essay. In order to discuss this distinction, we 
> need words for
> the thing that is addressed and the bits you get by going there on a
> particular day, with a particular user agent, etc. The 
> concept is known
> as a "resource". The bits are known as a "representation".
> 
> Representations have media-types. Resources do not. In-so-far as
> resources are "typed" (and HTTP has nothing to say about 
> this) you might
> say that they are typed by RDF. The distinction between representation
> and resource allows us a very powerful form of extensibility and
> adaptability. The Web has a feature called content negotiation which
> allows resource consumers to ask for the resource in a variety of
> different representations. One representation might be WML 
> optimized for
> hand-held computers. Another might be XHTML optimized for browsers.
> Others might be PDF optimized for printers and RDF optimized 
> for machine
> discovery. As new standards come into existence, they can be served as
> new representations for the information, enabling evolution of the
> resource without backwards compatibility problems.
> 
> This is a good point to emphasize something that has been so-far
> implicit. There is nothing in the Web architecture which is 
> specific to
> interactions with a human being at one end and a machine at the other.
> Existing information resources can be made machine-accessible 
> by adding
> an XML (or XML/RDF) representation alongside existing HTML
> representations. Human beings are one kind of client for web 
> resources.
> Machines are another.
> 
>     = Services =
> 
> So far we have described the Web as an information publishing 
> platform.
> But over the years it has also become the world's leading service
> publishing platform. There are services for bidding on 
> auctions, booking 
> flights, generating insults and anything else you might dream of. The
> biggest distinction between publishing information and publishing a
> service is that the service may require the service provider 
> and client
> working together to generate new resources, change existing 
> resources or
> delete resources. In other words the conversation is two-way 
> rather than
> one-way.
> 
> Now before we go into detail on services I want to point out that an
> important sub-task in publishing almost any service is publishing
> information either held by or relating to that service. There is a
> tendency to forget this when developing services using 
> technologies such
> as SOAP and XML-RPC. For instance a part of a stock purchasing service
> might include a means to get the stock price. The traditional
> SOAP/XML-RPC way to do this is to invent a new method called
> getStockPrice. I have already discussed the interoperability 
> limitations
> of this model. So the first thing to remember about 
> publishing services
> is that whatever you do, do not neglect the information 
> publishing part
> of your service. If it can benefit from the web architecture features
> described above, use them.
> 
> The second important thing to remember about publishing 
> services is that
> publishing information is crucial for the flexibility, reliability and
> scalability of your service. Let's deal with each of these in turn.
> Imagine a service that allows the client and server to work 
> together to
> generate a purchase order. Now they need to decide what to do with the
> generated purchase order. One option is that each of them can give the
> order a unique identifier (e.g. "PO number") and maintain a local copy
> of it. This arrangement makes it difficult to bring third parties into
> the conversation and to utilize URI-aware tools like spiders, caches,
> inferencers and XSLT transformation engines. It would be 
> better to give
> the purchase order its own URI. Generally, if there is 
> information that
> is of interest to both or all participants in a conversation, that
> information should be given a URI so that new participants 
> can be easily
> brought in after the fact.
> 
> Another aspect of flexibility is allowing a variety of different kinds
> of clients. As long as the purchase order has a URI, the client can
> decide how stateful or stateless it should be. If it wants to keep a
> copy of the purchase order it can (more robust and paranoid clients
> will). But if it wants to let the server manage it, it can merely keep
> the URI and refresh from the server when it needs 
> information. In a case
> where the server is allowed to unilaterally change the information
> resource (i.e. not a purchase order), the client can always get the
> latest version of the resource using a GET.
> 
> Emphasizing the information publishing portion of your service is also
> important for reliability reasons. Continuing with the purchase order
> example, consider what would happen if the client party 
> missed a message
> or had its state corrupted during the communication. As long as all
> relevant information has been exposed on the server as URIs, it could
> rebuild its state with nothing more than the URI representing the
> resource. Conversely, in situations where the state of the 
> conversation
> is implicit, one lost message can throw the client 
> irreconcilably out of
> sync with the server. Of course if the service consumer somehow loses
> the URI for the thing it is talking about (e.g. the purchase 
> order URI)
> then you are in trouble. But even then you can use discovery and query
> techniques to re-establish contact. For this and other 
> reasons, resource
> discovery should always be an important part of service design.
> 
> Finally there is the issue of scalability. It is often the case that
> once an information resource has been created, a 
> representation of it is
> retrieved many times. Even a purchase order may be read over and over
> again by internal and external auditors and order fulfillment systems.
> Using standard web techniques, these representations can be cached.
> 
> So far, I've tried to show how information publishing is a 
> crucial part
> of all service publishing projects and thus to show that the service
> publishing problem is an _extension_ of the information publishing
> problem, not a different problem altogether. Next we will describe how
> we can extend the web architecture into service publishing.
> 
>    = Resource construction and mutation =
> 
> Consider a service like buying sneakers. There are three 
> reasons that we
> need to move beyond the GET-based web we have described. 
> First, we will
> want to create purchase orders, so we need a way to create objects.
> Second, we need information to flow from the customer to the service
> provider rather than vice versa. Third, we need to allow the "side
> effect" of actually shipping the shoes.
> 
> The HTTP method designed for creating and mutating objects, with
> possible side effects, is POST. POST is neither more nor less powerful
> than GET. It is just different. GET's safety (side-effect-freeness)
> means that clients have extreme flexibility in structuring 
> applications
> that rely heavily on GET. In particular, GET allows very "declarative"
> applications that say what needs to be done but does not provide any
> instructions on how to do it. For instance if an XSLT stylesheet needs
> to deal with an XML element inside of a web resource it can retrieve
> that document once, or ten times, or a hundred times, at its own
> discretion. It might choose to do it once to optimize for 
> bandwidth or a
> hundred times to optimize for client-side memory space. If the XSLT is
> using multiple documents, it can also choose the order that 
> it retreives
> them at its own discretion.
> 
> But if you do need side-effects then you need to give up some of GETs
> advantages. Then you need POST. Because POST invocations may 
> have side 
> effects, you must be very careful about the order in which you invoke 
> POST methods. You need to add the shoes to the shopping cart 
> before you 
> checkout of the online store and not vice versa.
> 
> POST has another related strength/weakness. The input to GET is very 
> simple: basically just an address. The Web infrastructure strongly 
> encourages you to move retrievable information into an 
> addressable URI. 
> But when the service provider and client are working together 
> to create 
> new resources or modify existing ones, they both need to contribute 
> information. This requires a higher level of coordination which makes 
> POST-based integration more difficult than GET-based integration. But 
> this is the price of solving the more difficult problem of building 
> information resources rather than simply delivering them.
> 
> POST and GET work together in important ways. Using GET-based 
> navigation 
> you can find the service you want to invoke. It could even report its 
> quality of service characteristics, terms and conditions and 
> so forth. 
> Then you use POST to invoke it. This will usually either mutate or 
> create a resource. This resource has a URI that you can use GET to 
> retrieve whenever you need it. You can also refer third 
> parties at the 
> resource via its URI and they can GET it. There is no need to 
> coordinate 
> who GETs first or how many times you GET because GET is safe 
> and idempotent.
> 
> POST can handle any operation which changes client-side state in a 
> manner that would be inappropriate for GET. But there are two 
> operations 
> that have pretty clear semantics that can be separated out 
> from the mass 
> of POST-based actions. Sometimes you have a URI and you want to 
> overwrite its content. For instance you load a document into 
> your word 
> processor, make a few changes and want to save it back. Or you are 
> maintaining a stock quote service and it is your job to udpdate the 
> quotes as the most recently quoted price change. PUT allows 
> these. The 
> other operation is DELETE for destroying resources (i.e. making them 
> into 404s).
> 
> 
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Plan to Sell a Home?
> http://us.click.yahoo.com/J2SnNA/y.lEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2542
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-09-13 21:46:03
Subject:Re: [rest-discuss] Rediscovering Web Architecture from first principles
Message:

On Thursday, Sep 12, 2002, at 19:06 Europe/Dublin, Paul Prescod wrote:
> [snip]

bravo!

i'm glad i stopped playing wolf to check my email now.  it's time to 
curl up by the fire and do some RESTful meditation.

i especially like the last section, on resource creation/mutation.  the 
idea that service publishing is an extension of information publishing 
is also intriguing.

thank you paul.







-----------------------------------------------------------------------------------
Post ID:2543
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-14 03:46:06
Subject:Re: [rest-discuss] Rediscovering Web Architecture from first principles
Message:

First, excellent summary.  There wasn't a single thing I found to disagree
with.  :~)

Second, you indicate something towards the end of the post that, if I
understand you correctly, mirrors a thought I have been having lately...

From: "Paul Prescod" <paul@...>
>
> [deleted]
>
>    = Resource construction and mutation =
>
> [deleted]
>
> POST can handle any operation which changes client-side state in a
> manner that would be inappropriate for GET. But there are two operations
> that have pretty clear semantics that can be separated out from the mass
> of POST-based actions. Sometimes you have a URI and you want to
> overwrite its content. For instance you load a document into your word
> processor, make a few changes and want to save it back. Or you are
> maintaining a stock quote service and it is your job to udpdate the
> quotes as the most recently quoted price change. PUT allows these. The
> other operation is DELETE for destroying resources (i.e. making them
> into 404s).

You mention using PUT to update a resource, but not to create one.  In fact,
the only mention of creating a resource is by the use of POST.  However, the
HTTP specs state the ability to create a resource with PUT.  But I am
beginning to wonder if the use of PUT in this manner is less RESTful.  I see
two scenarios when using POST and PUT, the first being the way HTTP allows
and the second being the artificially contstrained (but still perfectly
legal) way that I am beginning to lean towards.

Standard HTTP Usage of POST and PUT:

1) POST:
    a) Request URI points to an existing resource that will be mutated by
the contents of the request entity.
    b) Request URI points to an existing resource that will use the contents
of the request entity to create a new resource.
2) PUT:
    a) Request URI points to an existing resource that will be entirely
replaced by the contents of the request entity (at least from the client's
perspective).
    b) Request URI does not point to an existing resource, in which case the
server creates a new resource from the request entity that is pointed to by
the request URI.


Constrained Usage of POST and PUT:

1) POST:
    a) Request URI points to an existing resource that will be mutated by
the contents of the request entity.
    b) Request URI points to an existing resource that will use the contents
of the request entity to create a new resource.  This is the *only* method
to create a new resource.  If the client wants the new resource to be
created with a specific URI associated with it, this can be passed in the
entity itself (though I wonder about using the Location header in the
request).
2) PUT:
    a) Request URI points to an existing resource that will be entirely
replace by the contents of the request entity (at least from the client's
perspective).
    b) There is no option (b).  PUT is never used to create a new resource.


And here is why I am taking this view:  Using PUT to create a resource with
a request URI just doesn't make sense.  In all other verbs (GET, POST, and
DELETE), the URI must be valid and point to a resource.  This makes sense.
You are accessing a resource and you need a valid identifier to do it.  But
for PUT, this is only required part of the time.  In some cases, you can use
PUT with an *invalid* URI (i.e. does not identify a resource) as if it were
valid.  By using the constrained view, resources can still be created while
simplifying the rules about URI usage at the same time.

So, is this a view you were expressing?  Is this view more consistant with
REST (simplified interface)?  Or is this just a personal preference and not
any more or less RESTful than the "traditional" usage of the verbs?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2544
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-09-14 06:25:43
Subject:Re: Rediscovering Web Architecture from first principles
Message:

Seairth,


Yeah ,I definitely think you should use POST to create resources and 
never PUT (though the RFC says differently). There are many reasons 
why you want to do this:

1) The client should be explicitly aware of resource creation. When 
the client PUTs a resource they have no way of actually knowing 
whether they're simply updating a resource or creating a brand new 
resource. These are two very different things and you should force 
the client to acknowledge the distinction using POST.

2) Because of the principle of URI opacity, it's in poor taste to 
let the client assign URIs to new resources. Only the server should 
know about URI construction.

3) 90%+ of the time when a new resource is created (eg a purchase 
order, user, document, order) you rely on the database to assign a 
unique ID of the resource. Then, the URL you assign to that resource 
includes the ID or a hash of the id (eg /purchase-
orders/po321343, /users/hash(social-security-#), /orders/332-43-
43523) etc. If you use PUT you rarely can enforce this interface.

4) Load balancing. When new resources are created you might want to 
spread them out among many different servers particularly if these 
are temporary resources. If you use PUT you can't do this because 
the client decides which machine will contain the resource (or at 
least process the creation request). This is often a bad idea.

5) It is very easy to enforce security when POST is used against a 
single URI for resource creation.

6) I think the RFC is just being flexible. AFAIK, POST as always 
meant APPEND TO DOCUMENT/PROCESS DOCUMENT and PUT as always meant 
WRITE. 

So, for hopefully the last time, I'd say use POST to mean resource 
creation and PUT to mean update.

- itdp
 
--- In rest-discuss@y..., "Seairth Jacobs" <seairth@s...> wrote:
> First, excellent summary.  There wasn't a single thing I found to 
disagree
> with.  :~)
> 
> Second, you indicate something towards the end of the post that, 
if I
> understand you correctly, mirrors a thought I have been having 
lately...
> 
> From: "Paul Prescod" <paul@p...>
> >
> > [deleted]
> >
> >    = Resource construction and mutation =
> >
> > [deleted]
> >
> > POST can handle any operation which changes client-side state in 
a
> > manner that would be inappropriate for GET. But there are two 
operations
> > that have pretty clear semantics that can be separated out from 
the mass
> > of POST-based actions. Sometimes you have a URI and you want to
> > overwrite its content. For instance you load a document into 
your word
> > processor, make a few changes and want to save it back. Or you 
are
> > maintaining a stock quote service and it is your job to udpdate 
the
> > quotes as the most recently quoted price change. PUT allows 
these. The
> > other operation is DELETE for destroying resources (i.e. making 
them
> > into 404s).
> 
> You mention using PUT to update a resource, but not to create 
one.  In fact,
> the only mention of creating a resource is by the use of POST.  
However, the
> HTTP specs state the ability to create a resource with PUT.  But I 
am
> beginning to wonder if the use of PUT in this manner is less 
RESTful.  I see
> two scenarios when using POST and PUT, the first being the way 
HTTP allows
> and the second being the artificially contstrained (but still 
perfectly
> legal) way that I am beginning to lean towards.
> 
> Standard HTTP Usage of POST and PUT:
> 
> 1) POST:
>     a) Request URI points to an existing resource that will be 
mutated by
> the contents of the request entity.
>     b) Request URI points to an existing resource that will use 
the contents
> of the request entity to create a new resource.
> 2) PUT:
>     a) Request URI points to an existing resource that will be 
entirely
> replaced by the contents of the request entity (at least from the 
client's
> perspective).
>     b) Request URI does not point to an existing resource, in 
which case the
> server creates a new resource from the request entity that is 
pointed to by
> the request URI.
> 
> 
> Constrained Usage of POST and PUT:
> 
> 1) POST:
>     a) Request URI points to an existing resource that will be 
mutated by
> the contents of the request entity.
>     b) Request URI points to an existing resource that will use 
the contents
> of the request entity to create a new resource.  This is the 
*only* method
> to create a new resource.  If the client wants the new resource to 
be
> created with a specific URI associated with it, this can be passed 
in the
> entity itself (though I wonder about using the Location header in 
the
> request).
> 2) PUT:
>     a) Request URI points to an existing resource that will be 
entirely
> replace by the contents of the request entity (at least from the 
client's
> perspective).
>     b) There is no option (b).  PUT is never used to create a new 
resource.
> 
> 
> And here is why I am taking this view:  Using PUT to create a 
resource with
> a request URI just doesn't make sense.  In all other verbs (GET, 
POST, and
> DELETE), the URI must be valid and point to a resource.  This 
makes sense.
> You are accessing a resource and you need a valid identifier to do 
it.  But
> for PUT, this is only required part of the time.  In some cases, 
you can use
> PUT with an *invalid* URI (i.e. does not identify a resource) as 
if it were
> valid.  By using the constrained view, resources can still be 
created while
> simplifying the rules about URI usage at the same time.
> 
> So, is this a view you were expressing?  Is this view more 
consistant with
> REST (simplified interface)?  Or is this just a personal 
preference and not
> any more or less RESTful than the "traditional" usage of the verbs?
> 
> ---
> Seairth Jacobs
> seairth@s...







-----------------------------------------------------------------------------------
Post ID:2545
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-14 06:59:40
Subject:Re: [rest-discuss] Re: Rediscovering Web Architecture from first principles
Message:

----- Original Message -----
From: "inthedarkplace" <inthedarkplace@...>

>
> 1) The client should be explicitly aware of resource creation. When
> the client PUTs a resource they have no way of actually knowing
> whether they're simply updating a resource or creating a brand new
> resource. These are two very different things and you should force
> the client to acknowledge the distinction using POST.
Why? If I only ever POST to uri1 to update the resource, isn't that the same
as PUT to uri1, only obscured?

>
> 2) Because of the principle of URI opacity, it's in poor taste to
> let the client assign URIs to new resources.
I don't understand that reasoning. Opacity to me means that you can't
examing a portion of a URI to infer its meaning or usage - there has to be
some other out-of-band communication to do that. I don't see how it is
related to which side generates the URI.

> Only the server should know about URI construction.
I strongly disagree.

>
> 3) 90%+ of the time when a new resource is created (eg a purchase
> order, user, document, order) you rely on the database to assign a
> unique ID of the resource.
Not in my systems. I tend to go for longevity and scalability rather than
trivially relying on database ids.
If you need to map external ids to storage ids, then add a column for the
'public identifier'. That's why email addresses aren't numbers and haven't
been since CompuServe went out of business.

> Then, the URL you assign to that resource
> includes the ID or a hash of the id (eg /purchase-
> orders/po321343, /users/hash(social-security-#), /orders/332-43-
> 43523) etc. If you use PUT you rarely can enforce this interface.
And when you blow out your database and re-created it, all the IDs are
regenerated... hmm...

>
> 4) Load balancing. When new resources are created you might want to
> spread them out among many different servers particularly if these
> are temporary resources. If you use PUT you can't do this because
> the client decides which machine will contain the resource (or at
> least process the creation request). This is often a bad idea.
There are lots of ways to coordinate the client and server addressing to
achieve this.
You could just randomly respond with a redirect to a different machine and
the client should re-try the request at the new location.

>
> 5) It is very easy to enforce security when POST is used against a
> single URI for resource creation.

>
> 6) I think the RFC is just being flexible. AFAIK, POST as always
> meant APPEND TO DOCUMENT/PROCESS DOCUMENT and PUT as always meant
> WRITE.

>
> So, for hopefully the last time, I'd say use POST to mean resource
> creation and PUT to mean update.
Ahh... you aren't saying /never/ use PUT, just use it for only updates...








-----------------------------------------------------------------------------------
Post ID:2546
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-09-14 16:57:58
Subject:WSDL not RESTful?
Message:

The <part> child of <message> has types of W3C schema datatypes -- nothing
about documents per se. Seems not very RESTful. 

Or would a GET request not fall into the category of a WSDL "message" and
so the portType, binding, and service elements would define a RESTful web
service?


Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.goose-works.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2547
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-14 17:29:29
Subject:Re: [rest-discuss] Re: Rediscovering Web Architecture from first principles
Message:

From: "inthedarkplace" <inthedarkplace@...>
>
> Yeah ,I definitely think you should use POST to create resources and
> never PUT (though the RFC says differently). There are many reasons
> why you want to do this:
>
> 1) The client should be explicitly aware of resource creation. When
> the client PUTs a resource they have no way of actually knowing
> whether they're simply updating a resource or creating a brand new
> resource. These are two very different things and you should force
> the client to acknowledge the distinction using POST.

Umm.  I thought the difference between a 200 response for updating of an
existing resource and a 201 response indicating the creation of a new
resource dealt with that.  I am not trying to argue for the use of PUT, mind
you.  I'm just not sure that your statement is true.

> 2) Because of the principle of URI opacity, it's in poor taste to
> let the client assign URIs to new resources. Only the server should
> know about URI construction.

With the exception of Query Strings, of course.  Beyond that, I mostly
agree... more on this in a separate post...

> 6) I think the RFC is just being flexible. AFAIK, POST as always
> meant APPEND TO DOCUMENT/PROCESS DOCUMENT and PUT as always meant
> WRITE.

I think also that the RFC is carrying around some old "static hypertext
document" baggage.  In that context (and ignoring REST for the moment), it
would make sense to have a verb that allowed easy maintenance of html files
sitting on a remote server.  The only reason PUT didn't catch was due to the
existing, well established FTP network and tools.  There was no incentive to
switch to PUT, add security headaches to the HTTP server, etc. when FTP
already provided that without changing a thing...

> So, for hopefully the last time, I'd say use POST to mean resource
> creation and PUT to mean update.

Clarification... POST can also be used to update an existing resource.  The
difference(s) between a POST and PUT update are:

1) POST does not directly cause the resource to be updated, while PUT does.
yes, I know that neither actually does it directly, bit we conceptually
think of them being indirect and direct (respectively).
2) POST is meant to mutate, or partially update, a resource while PUT is
meant to entirely replace the resource.  yes, it would be possible for POST
to effectively perform a replace as well.

I have had some thoughts on this too... again, I'll elaborate in a follow-up
message...

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2548
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-14 19:01:06
Subject:REST without PUT and other things...
Message:

In a recent post [1], I was asking about performing resource creation with
POST only.  My conclusion has been that this is a good thing.  What's more,
as I was falling asleep last night, additional thoughts occurred to me that
I now feel the need to share with the list.  Tell me what you think...


I contend that PUT does not fit well with the REST model.  First, there is
the issue of resource creation.  PUT is allowed to submit a "non-existing"
request-URI as if it did exist.  This request-URI has no identity whatsoever
(not even with the request-entity that will become the new resource).  From
my ever-evolving understanding of REST, allowing the usage of URIs in this
manner is just plain wrong.  I absolutely agree with this regardless of
REST.  As I recently mentioned [1], I feel that using POST to create all
resources is just as effective and keeps the URI rules simple.

Second, there is the issue of resource update.  PUT is designed to only
replace an entire resource.  It is not capable of updating only a part of
the resource.  Not only is this very limited in terms of functionality, but
POST can do the same thing!  So, why have a separate PUT verb when POST
would work as well?  I can't think of a single good reason.

Suppose, when working within the REST model, we were to entirely ignore PUT.
When using HTTP, the only verbs that would be recognized would be:

    GET : safe, idempotent retrieval of an existing resource
    POST: update of existing resource / creation of new resource.
    DELETE: deletion of existing resource.

GET is a no-brainer here.  We all pretty much agree how it should and show
not be used.

POST is now taking on the responsibility that PUT provided (not any more
than it does now, really).  To clarify POST "new"
responsibilities/capabilities:

1) POST may request the creation of a new resource.  If you want POST to act
like PUT, all you need to do is pass the URI that you would like to have the
new resource located at.  This could be done in the request-entity, but I
suggest instead using the "Location:" header (yes, I know it's a response
header in the spec [2:14.30]).  This would allow a POST like the following:

    POST existing-URI-path
    Location: new-URI

    <entity>

The server would be able to use the request-URI to appropriately act upon
the request, and it may then choose to honor the requested Location or not
just as it would with a PUT's request-URI. The difference here is that the
request-URI must *always* exist, which is not the case for PUT.

2) POST may request that a resource be updated.  This could be done in a
couple different ways:
    a) The request-URI is a resource responsible for updating other
resources, where the resource knows enough context from the request to
update the appropriate resource.  This could include the use of the Location
request header as well.
    b) The request-URI is the resource that is to be updated.  This
particular method is most like PUT.  However, unlike PUT it would still be
possible for the resource to be partially updated in this case.



DELETE still works like it does now.  However, it should be noted that usage
of DELETE doesn't necessarily delete the actual resource.  It definitely
invalidates the relationship between the request-URI and it's currently
associated resource (thereby making *appear* as if the resource is deleted
to the client), but whether the actual resource goes entirely away is up to
the server only.  I am of the mind that DELETE should return the following:

200,202,204: If the URI was valid and the request is accepted (as stated in
the spec [2:9.7]).
404: If the URI is invalid and the server does not know if it used to point
at a resource.
410: If the URI is invalid and the server knows that it used to point at a
resource.

This does mean that DELETE would not be strictly idempotent, but the client
could still act as if it were (i.e. treat all responses as the same as 200).



Part of the reason for suggesting that PUT should be depricated when working
in the REST model is due to the REST model itself.  REST specifically talks
of simple, uniform interfaces.  As is evident from threads on this list,
having both a PUT and a POST is not a simple, uniform interface.  As I see
it, within the context of REST, POST is necessary, while PUT is optional.
Getting rid of PUT provides a simple, uniform interface as REST mentions.

An objection that I have seen in recent posts that will undoubtedly be
brought back up due to my usage of POST above is the ability to POST an
update to the resource directly.  To some, this may be considered a
violation of the proper use of POST, where the request-entity is considered
to be subordinate to the resource.  To me, I see no conflict here.  Take the
directory-file example mentioned in the spec [2:9.5].  If you were to POST a
"file" to a "directory", this would also update the directory itself (since
the file is part of the directory resource).  Any resource update could be
viewed within the same light (update of a subordinate is update of itself as
well).  And I don't see anything in the HTTP spec that says a subordinate
must be accessible independently of the parent resource.

Also, some (or maybe all) of you may be disagreeing with my usage of
"Location" above.  However, this makes perfect sense to me.  Usage of
Location in a POST request allows all of the functionality of PUT without
having to embed any additional data in the request-entity itself.  Further,
by use Location instead of the request-URI to indicate a new URI, we ensure
that only existing URIs may be used for a request-URI.  This also adresses
the ability for a client to be able to construct URIs.  A client could
construct a new string that will become a URI and place it in the Location
header.  The server could then act on it independent of the actual
request-URI.  Therefore, the request-URI still stays opaque without losing
any capabilities from the client's POV.


[1] http://groups.yahoo.com/group/rest-discuss/message/2543
[2] http://www.ietf.org/rfc/rfc2616.txt


---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2549
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-09-14 21:02:06
Subject:Re: REST without PUT and other things...
Message:

Searith,

There's absolutely no reason to ignore PUT. PUT is very good at what 
it does and it makes little sense to overload POST to mean update. 
In fact, I'd say using POST to mean UPDATE is a violation of REST 
because it suggests that there are user-visible, side-effects to 
simple updates which 99.9% of the time there are not -- this is why 
PUT is idempotent and POST is not.

Further, your suggestion to use POST for limited updates isn't the 
optimal solution 90% of the time. Coarse-grained messaging (which I 
think is one of the fundamentals of REST) has proven to be more 
scalable and it drastically simplifies the code that both the server 
and the client must deal with. Further it makes all types of things 
easier when you're dealing with whole resources.

Also your suggestion that DELETE return 4xx codes doesn't really 
jive with the definition of DELETE. I think Fielding has commented 
on this, and also it just makes sense, but DELETE should always 
return a 2xx if the server can guarantee that no resource exists at 
the given URL at the time of request. It's perfectly fine to DELETE 
something that's already not there and this is partially why DELETE 
is idempotent: whether you DELETE something 1 time or a thousand 
times the resource is still not there at the end of the request 
sequence.

- itdp

--- In rest-discuss@y..., "Seairth Jacobs" <seairth@s...> wrote:
> In a recent post [1], I was asking about performing resource 
creation with
> POST only.  My conclusion has been that this is a good thing.  
What's more,
> as I was falling asleep last night, additional thoughts occurred 
to me that
> I now feel the need to share with the list.  Tell me what you 
think...
> 
> 
> I contend that PUT does not fit well with the REST model.  First, 
there is
> the issue of resource creation.  PUT is allowed to submit a "non-
existing"
> request-URI as if it did exist.  This request-URI has no identity 
whatsoever
> (not even with the request-entity that will become the new 
resource).  From
> my ever-evolving understanding of REST, allowing the usage of URIs 
in this
> manner is just plain wrong.  I absolutely agree with this 
regardless of
> REST.  As I recently mentioned [1], I feel that using POST to 
create all
> resources is just as effective and keeps the URI rules simple.
> 
> Second, there is the issue of resource update.  PUT is designed to 
only
> replace an entire resource.  It is not capable of updating only a 
part of
> the resource.  Not only is this very limited in terms of 
functionality, but
> POST can do the same thing!  So, why have a separate PUT verb when 
POST
> would work as well?  I can't think of a single good reason.
> 
> Suppose, when working within the REST model, we were to entirely 
ignore PUT.
> When using HTTP, the only verbs that would be recognized would be:
> 
>     GET : safe, idempotent retrieval of an existing resource
>     POST: update of existing resource / creation of new resource.
>     DELETE: deletion of existing resource.
> 
> GET is a no-brainer here.  We all pretty much agree how it should 
and show
> not be used.
> 
> POST is now taking on the responsibility that PUT provided (not 
any more
> than it does now, really).  To clarify POST "new"
> responsibilities/capabilities:
> 
> 1) POST may request the creation of a new resource.  If you want 
POST to act
> like PUT, all you need to do is pass the URI that you would like 
to have the
> new resource located at.  This could be done in the request-
entity, but I
> suggest instead using the "Location:" header (yes, I know it's a 
response
> header in the spec [2:14.30]).  This would allow a POST like the 
following:
> 
>     POST existing-URI-path
>     Location: new-URI
> 
>     <entity>
> 
> The server would be able to use the request-URI to appropriately 
act upon
> the request, and it may then choose to honor the requested 
Location or not
> just as it would with a PUT's request-URI. The difference here is 
that the
> request-URI must *always* exist, which is not the case for PUT.
> 
> 2) POST may request that a resource be updated.  This could be 
done in a
> couple different ways:
>     a) The request-URI is a resource responsible for updating other
> resources, where the resource knows enough context from the 
request to
> update the appropriate resource.  This could include the use of 
the Location
> request header as well.
>     b) The request-URI is the resource that is to be updated.  This
> particular method is most like PUT.  However, unlike PUT it would 
still be
> possible for the resource to be partially updated in this case.
> 
> 
> 
> DELETE still works like it does now.  However, it should be noted 
that usage
> of DELETE doesn't necessarily delete the actual resource.  It 
definitely
> invalidates the relationship between the request-URI and it's 
currently
> associated resource (thereby making *appear* as if the resource is 
deleted
> to the client), but whether the actual resource goes entirely away 
is up to
> the server only.  I am of the mind that DELETE should return the 
following:
> 
> 200,202,204: If the URI was valid and the request is accepted (as 
stated in
> the spec [2:9.7]).
> 404: If the URI is invalid and the server does not know if it used 
to point
> at a resource.
> 410: If the URI is invalid and the server knows that it used to 
point at a
> resource.
> 
> This does mean that DELETE would not be strictly idempotent, but 
the client
> could still act as if it were (i.e. treat all responses as the 
same as 200).
> 
> 
> 
> Part of the reason for suggesting that PUT should be depricated 
when working
> in the REST model is due to the REST model itself.  REST 
specifically talks
> of simple, uniform interfaces.  As is evident from threads on this 
list,
> having both a PUT and a POST is not a simple, uniform interface.  
As I see
> it, within the context of REST, POST is necessary, while PUT is 
optional.
> Getting rid of PUT provides a simple, uniform interface as REST 
mentions.
> 
> An objection that I have seen in recent posts that will 
undoubtedly be
> brought back up due to my usage of POST above is the ability to 
POST an
> update to the resource directly.  To some, this may be considered a
> violation of the proper use of POST, where the request-entity is 
considered
> to be subordinate to the resource.  To me, I see no conflict 
here.  Take the
> directory-file example mentioned in the spec [2:9.5].  If you were 
to POST a
> "file" to a "directory", this would also update the directory 
itself (since
> the file is part of the directory resource).  Any resource update 
could be
> viewed within the same light (update of a subordinate is update of 
itself as
> well).  And I don't see anything in the HTTP spec that says a 
subordinate
> must be accessible independently of the parent resource.
> 
> Also, some (or maybe all) of you may be disagreeing with my usage 
of
> "Location" above.  However, this makes perfect sense to me.  Usage 
of
> Location in a POST request allows all of the functionality of PUT 
without
> having to embed any additional data in the request-entity itself.  
Further,
> by use Location instead of the request-URI to indicate a new URI, 
we ensure
> that only existing URIs may be used for a request-URI.  This also 
adresses
> the ability for a client to be able to construct URIs.  A client 
could
> construct a new string that will become a URI and place it in the 
Location
> header.  The server could then act on it independent of the actual
> request-URI.  Therefore, the request-URI still stays opaque 
without losing
> any capabilities from the client's POV.
> 
> 
> [1] http://groups.yahoo.com/group/rest-discuss/message/2543
> [2] http://www.ietf.org/rfc/rfc2616.txt
> 
> 
> ---
> Seairth Jacobs
> seairth@s...







-----------------------------------------------------------------------------------
Post ID:2550
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-09-14 21:17:26
Subject:Re: [rest-discuss] Rediscovering Web Architecture from first principles
Message:

Well, I will join the general chorus of praise for this fine piece.
There is one point that bothers me, though:

On Thu, Sep 12, 2002 at 11:06:24AM -0700, Paul Prescod wrote:

> quotes as the most recently quoted price change. PUT allows these. The 
> other operation is DELETE for destroying resources (i.e. making them 
> into 404s).

Must they be 404s instead of, say, 302s? To me this is very unfriendly;
there are already far too many URIs that have ceased to point to
anything for no very good reason.

Regardless of what Fielding or RFC2616 may say (though the latter is
silent as far as I can tell), I'm with Jakob Nielsen on this: in
principle, maintainers of web resources should never knowingly remove
them (or allow them to be removed) without providing a reasonable
redirect or substitute.

-- 
Matt Gushee
Englewood, Colorado, USA
mgushee@...
http://www.havenrock.com/






-----------------------------------------------------------------------------------
Post ID:2551
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-15 01:37:53
Subject:Updating part of a resource (was Re: REST without PUT and other things...)
Message:

From: "inthedarkplace" <inthedarkplace@...>
>
> There's absolutely no reason to ignore PUT. PUT is very good at what
> it does and it makes little sense to overload POST to mean update.
> In fact, I'd say using POST to mean UPDATE is a violation of REST
> because it suggests that there are user-visible, side-effects to
> simple updates which 99.9% of the time there are not -- this is why
> PUT is idempotent and POST is not.
>
> Further, your suggestion to use POST for limited updates isn't the
> optimal solution 90% of the time. Coarse-grained messaging (which I
> think is one of the fundamentals of REST) has proven to be more
> scalable and it drastically simplifies the code that both the server
> and the client must deal with. Further it makes all types of things
> easier when you're dealing with whole resources.

So POST should not be used to update a resource and PUT can only update a
resource by replacing it, then how do you update only a part of a resource?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2552
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-09-15 02:46:01
Subject:Updating part of a resource (was Re: REST without PUT and other things...)
Message:

Seairth,

I think the point is you shouldn't be doing partial updates of a 
resource. Partial updates is very non-RESTful. Even if a user just 
wants to update their email address they should still have to upload 
all their other information. Remember, you're transferring resources 
not resource fragments or resource parameters. Your idea of using 
POST for partial updates seems a bit too RPC-like and it'd only 
complicate most systems. Also in general you don't want to send fine-
grained messages such as 'change my email address'. The SOAP people 
are just discovering this [see 
http://www.fawcette.com/xmlmag/2002_06/magazine/departments/endtag/] 
but it's one of the fundamental tenets of REST.

Also the partial update problem isn't really a problem per se since 
most people aren't dealing with obscenely large resources. If a 
resource is obscenely large and there's a strong case for partial 
updates then there's nothing technically wrong with using POST to 
implement partial update.

Also, as a last note, there's nothing that says the user has to 
upload the entire resource when using PUT or that the server is not 
allowed to perform processing on the PUT entity body. The server 
still has final say over what is actually PUT'ed to the URL.

- itdp

--- In rest-discuss@y..., "Seairth Jacobs" <seairth@s...> wrote:
> From: "inthedarkplace" <inthedarkplace@y...>
> >
> > There's absolutely no reason to ignore PUT. PUT is very good at 
what
> > it does and it makes little sense to overload POST to mean 
update.
> > In fact, I'd say using POST to mean UPDATE is a violation of REST
> > because it suggests that there are user-visible, side-effects to
> > simple updates which 99.9% of the time there are not -- this is 
why
> > PUT is idempotent and POST is not.
> >
> > Further, your suggestion to use POST for limited updates isn't 
the
> > optimal solution 90% of the time. Coarse-grained messaging 
(which I
> > think is one of the fundamentals of REST) has proven to be more
> > scalable and it drastically simplifies the code that both the 
server
> > and the client must deal with. Further it makes all types of 
things
> > easier when you're dealing with whole resources.
> 
> So POST should not be used to update a resource and PUT can only 
update a
> resource by replacing it, then how do you update only a part of a 
resource?
> 
> ---
> Seairth Jacobs
> seairth@s...







-----------------------------------------------------------------------------------
Post ID:2553
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-15 03:46:02
Subject:Re: [rest-discuss] Updating part of a resource (was Re: REST without PUT and other things...)
Message:

From: "inthedarkplace" <inthedarkplace@...>
>
> I think the point is you shouldn't be doing partial updates of a
> resource. Partial updates is very non-RESTful. Even if a user just
> wants to update their email address they should still have to upload
> all their other information. Remember, you're transferring resources
> not resource fragments or resource parameters. Your idea of using
> POST for partial updates seems a bit too RPC-like and it'd only
> complicate most systems. Also in general you don't want to send fine-
> grained messages such as 'change my email address'. The SOAP people
> are just discovering this [see
> http://www.fawcette.com/xmlmag/2002_06/magazine/departments/endtag/]
> but it's one of the fundamental tenets of REST.

Would it be acceptible to ask the server for a URI that represented the part
of the resource you want to update and treat it as if it's a true resource?

> Also, as a last note, there's nothing that says the user has to
> upload the entire resource when using PUT or that the server is not
> allowed to perform processing on the PUT entity body. The server
> still has final say over what is actually PUT'ed to the URL.

I'm not sure I agree with that.  From the rfc:

    "If the Request-URI refers to an already existing resource, the
    enclosed entity SHOULD be considered as a modified version
    of the one residing on the origin server."

Now, I realize that it says "SHOULD" and not "MUST".  But that's still
saying that using PUT in any other way is strongly discouraged.


---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2554
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-15 06:01:14
Subject:Re: [rest-discuss] Re: REST without PUT and other things...
Message:

inthedarkplace wrote:
> Searith,
> 
> There's absolutely no reason to ignore PUT. 

I agree.

 > PUT is very good at what
> it does and it makes little sense to overload POST to mean update. 
> In fact, I'd say using POST to mean UPDATE is a violation of REST 
> because it suggests that there are user-visible, side-effects to 
> simple updates which 99.9% of the time there are not -- this is why 
> PUT is idempotent and POST is not.

Side-effects are one thing. Idempotency is another. I think that PUT 
will have side effects, but idempotent ones. For instance if I have a 
resource representing the list of titles of documents of pages on my 
site, PUT-ting to a document will change the list as a side-effect. But 
changing the resource over and over again will not have any different 
effect than doing it once. So it is idempotent.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2555
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-15 19:58:55
Subject:Re: [rest-discuss] WSDL not RESTful?
Message:

Sam Hunting wrote:
> The <part> child of <message> has types of W3C schema datatypes -- nothing
> about documents per se. Seems not very RESTful. 
> 
> Or would a GET request not fall into the category of a WSDL "message" and
> so the portType, binding, and service elements would define a RESTful web
> service?

WSDL is not RESTful because it does not support hypertext as the engine 
of application space:

  * http://lists.w3.org/Archives/Public/www-tag/2002Sep/0086.html

  Paul Prescod









-----------------------------------------------------------------------------------
Post ID:2556
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-09-15 20:15:21
Subject:Re: [rest-discuss] WSDL not RESTful?
Message:

[paul prescod]
> WSDL is not RESTful because it does not support hypertext as the engine 
> of application space:
> 
>   * http://lists.w3.org/Archives/Public/www-tag/2002Sep/0086.html

Got it. Thanks.  That's the closest to a one-line description of REST as
I've heard ... 

Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.goose-works.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2557
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-15 20:19:14
Subject:Re: [rest-discuss] REST without PUT and other things...
Message:

Seairth Jacobs wrote:
>...

> 
> I contend that PUT does not fit well with the REST model.  First, there is
> the issue of resource creation.  PUT is allowed to submit a "non-existing"
> request-URI as if it did exist.  This request-URI has no identity whatsoever
> (not even with the request-entity that will become the new resource).  From
> my ever-evolving understanding of REST, allowing the usage of URIs in this
> manner is just plain wrong.  I absolutely agree with this regardless of
> REST.  As I recently mentioned [1], I feel that using POST to create all
> resources is just as effective and keeps the URI rules simple.

It would simplify the rule that the client should never invent URIs 
except for query strings. But it would complicate content-management 
applications where the human end-user is choosing mmenonic URIs.

> Second, there is the issue of resource update.  PUT is designed to only
> replace an entire resource.  It is not capable of updating only a part of
> the resource. 

There are two orthogonal issues here. One is "I want to save bandwidth 
and only send a diff of what's changed since yesterday." I think we 
could argue that both PUT and GET should allow this and in fact there is 
an unfinished proposal floating around. This is still appropriate for 
PUT because it is just an optimization of sending the whole resource. 
It's a conceptual overwrite that happens to be optimized.

The second issue is: "I know I want to change a particular element. I 
don't know or care about the state of other surrounding elements." 
That's where you use POST because it is a conceptual mutation and 
optimization is irrelevant.

> ... Not only is this very limited in terms of functionality, but
> POST can do the same thing!  So, why have a separate PUT verb when POST
> would work as well?  I can't think of a single good reason.

I disagree. If anything, I would go in the opposite direction. I would 
say that POST has too many meanings (sometimes it mutates a resource, 
sometimes it totally overwrites it, sometimes it creates a resource, 
sometimes it even has no side-effects at all). It is better to split 
these out into independent methods so that you know exactly what is 
going to happen when you invoke a method on a server. PUT is a little 
like "copy" on a command line. You know that after you invoke it what 
you will end up with. POST is more like invoking a program. What happens 
depends on the program.

Also, PUT's idempotency is important:

  * http://www.prescod.net/reliable_http.html
 > ...
> Part of the reason for suggesting that PUT should be depricated when working
> in the REST model is due to the REST model itself.  REST specifically talks
> of simple, uniform interfaces.  As is evident from threads on this list,
> having both a PUT and a POST is not a simple, uniform interface.  As I see
> it, within the context of REST, POST is necessary, while PUT is optional.
> Getting rid of PUT provides a simple, uniform interface as REST mentions.

Uniformity of interface is very important. Simplicity is much less 
important. I wouldn't mind an HTTP with 15 methods. As long as every 
HTTP client and server in the world understood those 15 methods, and 
every resource had a reasonable answer for every one of them, that would 
be a "uniform interface". The point is that clients and servers should 
not have to negotiate the meaning of the interfaces out of band. But we 
often DO have to negotiate the meaning of POST. So to me, more methods 
would do a better job of living up to the potential of REST, rather than 
fewer. (for instance I would love to see WATCH, NOTIFY, etc.)

> Also, some (or maybe all) of you may be disagreeing with my usage of
> "Location" above.  However, this makes perfect sense to me.  Usage of
> Location in a POST request allows all of the functionality of PUT without
> having to embed any additional data in the request-entity itself.  Further,
> by use Location instead of the request-URI to indicate a new URI, we ensure
> that only existing URIs may be used for a request-URI.  This also adresses
> the ability for a client to be able to construct URIs.  A client could
> construct a new string that will become a URI and place it in the Location
> header.  The server could then act on it independent of the actual
> request-URI.  Therefore, the request-URI still stays opaque without losing
> any capabilities from the client's POV.

But what does the request-URI *mean*? What is its relationship to the 
Location URI? It seems irrelevant which points me back to PUT with its 
single URI.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2558
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-15 21:24:35
Subject:Re: [rest-discuss] Updating part of a resource (was Re: REST without PUT and other things...)
Message:

inthedarkplace wrote:
> ...

> Also in general you don't want to send fine-
> grained messages such as 'change my email address'. 


I think you're both right. If you are going to change a bunch of values 
then you should do that in a batch rather than sending just the email 
address and then just the person's name and then, etc.

But if ALL you want to do is change the email address, I see nothing 
wrong with doing that.

> ... The SOAP people 
> are just discovering this [see 
> http://www.fawcette.com/xmlmag/2002_06/magazine/departments/endtag/] 
> but it's one of the fundamental tenets of REST.

Thanks for sending this on. I just wrote about it on my intermittently 
maintained Weblog:

http://www.blogstream.com/pauls/1032124150

> ... 
> Also, as a last note, there's nothing that says the user has to 
> upload the entire resource when using PUT or that the server is not 
> allowed to perform processing on the PUT entity body. The server 
> still has final say over what is actually PUT'ed to the URL.

I believe there is some debate on this issue. It could stand 
clarification in a future version of HTTP or something like that.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2559
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-15 21:26:19
Subject:REST presentation
Message:

I gave a presentation last week to the WSAWG, basically comparing REST
to some other architectural styles.

http://www.markbaker.ca/2002/08/Rest/

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2560
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-15 21:53:09
Subject:Re: [rest-discuss] Updating part of a resource (was Re: REST without PUT and other things...)
Message:

Paul Prescod wrote:
> Thanks for sending this on. I just wrote about it on my intermittently 
> maintained Weblog:
> 
> http://www.blogstream.com/pauls/1032124150

Sorry, the article ID changed:


http://www.blogstream.com/pauls/1032125477/index_html

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2561
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-09-15 22:04:17
Subject:Re: [rest-discuss] REST presentation
Message:

On Sun, 15 Sep 2002, Mark Baker wrote:

> I gave a presentation last week to the WSAWG, basically comparing REST
> to some other architectural styles.
> 
> http://www.markbaker.ca/2002/08/Rest/

DO you see a strong overlap between applications or systems that would use
these different architectural styles? For example if under REST "hypertext
is the engine of application state", a tuple-space application's state
might well be determined by URIs being put up into the tuple space, with
documents being taken down from the tuple space and returned to the larger
system.

Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.goose-works.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2562
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-16 00:58:17
Subject:Re: [rest-discuss] REST presentation
Message:

On Sun, Sep 15, 2002 at 06:04:17PM -0400, Sam Hunting wrote:
> On Sun, 15 Sep 2002, Mark Baker wrote:
> 
> > I gave a presentation last week to the WSAWG, basically comparing REST
> > to some other architectural styles.
> > 
> > http://www.markbaker.ca/2002/08/Rest/
> 
> DO you see a strong overlap between applications or systems that would use
> these different architectural styles?

There's some overlap, for sure.  Between OO-RPC - which is basically the Web
services style - and REST, there's definitely a *lot* of overlap.

> For example if under REST "hypertext
> is the engine of application state", a tuple-space application's state
> might well be determined by URIs being put up into the tuple space, with
> documents being taken down from the tuple space and returned to the larger
> system.

I don't think that's a great example, but I'm all for thinking about
new constraints which could be added to REST to induce new useful
properties, such as Rohit's work on ALIN.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2563
Sender:"borkazoid" <beau@...>
Post Date/Time:2002-09-16 02:34:49
Subject:Re: New version of XooMLe available
Message:

> 2) Please don't use XML-based errors. It's very annoying to go 
> through all the trouble of parsing an XML document just to discover 
> it contains no useful information. HTTP has a rich set of built in 
> response codes you should use.

mmm, I was debating this myself, in the end I opted for XML because I 
actually found it easier to work with than HTTP codes. I am coding 
from a PHP background, so maybe I'm missing some functionality that 
others are taking for granted, but it's actually a lot easier to 
parse a response document and check it for errors than it is to 
manipulate an HTTP header (although it does introduce some 
unfortunate overheads in the XML tags etc). Who do other people feel 
about this? Would people prefer to use HTTP headers to determine 
errors?

>     2.2) Similarly, the behavior you expose tends to be made 
> redundant by HTTP. For example, your method doGetCachedPage simply 
> returns the HTML of the cached page straight from google. Rather 
than 
> doing this, I'd suggest issuing an HTTP Redirect to the client so 
> they can retrieve the cached page themselves.

doGetCachedPage actually cleans up the document a little bit before 
sending it to the client. When returned directly from Google's cache, 
the page has the Google header on it (the same as if you view a 
cached page from Google.com), this is removed before sending the page 
back to the XooMLe client.

> 3) This is trivial but I don't really see the need for the top-
level 
> XML element 'doGoogleSearchResponse' since that's a bit verb-like. 
> Having 'GoogleSearchResult' as the root seems cleaner to me. Also, 
> since XML is case-sensitive and since ppl will be writing xslts to 
> handle Xoomle responses I'd suggest being consistent with your 
naming 
> convention. Since you're using camel-casing it seems 
> like 'GoogleSearchResult' should be 'googleSearchResult'.

That one wasn't my personal choice. In developing the XML response 
document, what I have actually done is to just take the SOAP envelope 
that is returned, then strip it down to something simpler. I suppose 
I should have taken out that additional element (and I left 
their "case"ing as-was as well), but I left it in because that's what 
was there to start with, so the XML-version is a lightweight (but 
very similar structure-wise) version of the SOAP version.

> 1) How do I pass the 'site:' restriction to Xoomle? Is this just 
> something the Google SOAP api forbids?

you should be able to do this as normal - for example, go to 
http://www.dentedreality.com.au/xoomle/search/ and 
enter "site:dentedreality.com.au xoomle" and it will return pages 
containing "xoomle" from my domain only :)

> 2) Is there any way to expose the directories offered by the Google 
> Directory?

directory information is offered (where available) within each 
resultElement in the reponse document. i.e. Search for "information 
architecture" and in the first resultElement 
(doGoogleSearchResponse//GoogleSearchResult//resultElements//item
[0]//directoryCategory//fullyViewableName) there is the 
value "Top/Reference/Knowledge_Management/Information_Architecture" 
which is used by Google to create a link to their Groups directory 
(They do a search and replace of "/" for " > " for the visible name 
of the link, and link to 
http://directory.google.com/<fullyViewableName>)

> 3) Can you explain more about how max results work? 

maxResults is a restriction that Google uses to determine how many 
results to return on a particular query. i.e. you set maxResults=3 
and it will only return 3 results (incidentally, if you set 
start=10&maxResults=3, it will give results 10-13 of the total result 
set). In the Google API, maxResults is limited to a maximum 
(maxMaxResults?? :P) of 10. XooMLe "cheats" this limit by allowing 
you to specify (for eaxmple) maxResults=30. The way it does this is 
by seeing that you want more than 10, it then gets the first 10, if 
the estimatedTotalResultsCount is over 10, then it gets the next 10 
(and so on and so on) until it has the number of results you asked 
for. It then compiles these all into one response document, and sends 
it all back to you. BE AWARE that this counts as 3 queries 
(decrements your daily limit of 1000 by 3) even though from your end 
you only do one query, since XooMLe obviously has to do 3 queries on 
your behalf. As a side note, the searchTime element is summed based 
on the amount of time each query took, so it is still accurate, 
although will be higher than if Google allowed the larger single 
request obviously.

> 4) What do the plain-text spelling suggestions response look like? 
> Are you sure you don't want to return an XML document instead?

Try it out - http://www.dentedreality.com.au/xoomle/spell/
They just have the standard headers, then the plain text response. If 
you parse the source of the URL required to get a reponse, then it 
will have nothing but the suggestion in it.

Ok, there we go, hope that answers some questions and indicates my 
intentions :) Thanks a lot for your feedback, I really appreciate it. 
This is a large learning experience for me, and I hope some other 
people are learning some things and finding something useful along 
the way as well :)

Regards,

Beau







-----------------------------------------------------------------------------------
Post ID:2564
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-16 11:31:13
Subject:RooDolF
Message:

I don't know if I mentioned this before, but I helped a guy develop an
RDF/HTTP wrapper for the Google SOAP API;

http://nutria.cs.tu-berlin.de/roodolf/

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2565
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-16 14:09:32
Subject:RE: [rest-discuss] REST without PUT and other things...
Message:

> There are two orthogonal issues here. One is "I want to save 
> bandwidth 
> and only send a diff of what's changed since yesterday." I think we 
> could argue that both PUT and GET should allow this and in 
> fact there is 
> an unfinished proposal floating around. This is still appropriate for 
> PUT because it is just an optimization of sending the whole resource. 
> It's a conceptual overwrite that happens to be optimized.
> 
> The second issue is: "I know I want to change a particular element. I 
> don't know or care about the state of other surrounding elements." 
> That's where you use POST because it is a conceptual mutation and 
> optimization is irrelevant.

Even squinting hard I just can't seem to find the difference between
these.  In both cases we are only concerned with a discrete subset of the
resource's state, for whatever reason.  I think your analysis below
that says PUT is like COPY while POST is like invoking a program makes
more sense.  If I want to COPY over all or part of resource state, I
use PUT (no matter what I think of this in terms of optimization), and
if I want a program to take control of applying some new information
to an old resource, then I use POST.  Understood that the server will
do as it please in either case, but in the COPY mode, the client is
requesting a specific limited overlay behavior, while in the PROGRAM
mode, it is saying "you decide what to do with this".


> I disagree. If anything, I would go in the opposite 
> direction. I would 
> say that POST has too many meanings (sometimes it mutates a resource, 
> sometimes it totally overwrites it, sometimes it creates a resource, 
> sometimes it even has no side-effects at all). It is better to split 
> these out into independent methods so that you know exactly what is 
> going to happen when you invoke a method on a server. PUT is a little 
> like "copy" on a command line. You know that after you invoke it what 
> you will end up with. POST is more like invoking a program. 
> What happens 
> depends on the program.
[snip]

> Uniformity of interface is very important. Simplicity is much less 
> important. I wouldn't mind an HTTP with 15 methods. As long as every 
> HTTP client and server in the world understood those 15 methods, and 
> every resource had a reasonable answer for every one of them, 
> that would 
> be a "uniform interface". The point is that clients and 
> servers should 
> not have to negotiate the meaning of the interfaces out of 
> band. But we 
> often DO have to negotiate the meaning of POST. So to me, 
> more methods 
> would do a better job of living up to the potential of REST, 
> rather than 
> fewer. (for instance I would love to see WATCH, NOTIFY, etc.)

I agree with this, and would like to echo from a paragraph or two
above that methods that intend to create new resources would be
a nice improvement.  Right now, creation is implicit through both
PUT and POST.*  There is still the argument that the server knows
best how to manage its information base, but that doesn't invalidate
the idea that clients should be able to express the HINT that
they would like resources created.

* Creation is implicit on the request side, while it's supposed
to be explicit on the result side, via 302 Created.  Above, I'm
talking about the request side.

> 
> 






-----------------------------------------------------------------------------------
Post ID:2566
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-16 14:19:35
Subject:Client-composed URI
Message:

Paul,

In your "first principles" posting of last Friday, there was
an interesting bit on queries and how the client can, by following
instructions from the server, participate in the composition of
query-extended URI.

I want to ask a general question about how this should work, independent
of HTML and current browser technology, where I understand its
working well enough.

Making no assumptions about the format of the entities, what can
be said about a standard for providing (server) and following (client)
instructions for extending URI with query parameters?

Here's my real-life example from a current project.  A Portfolio
resource (let's say it's at URI: "/Portfolio") undergoes changes, but
can be retrieved via "as of" snapshots.  The client does not care
exactly when the Portfolio changed; it only needs to know "what was
my Portfolio as-of 2002-09-16 end-of-business?".  The server may
choose to impose the convention of appending a simple yyyymmdd
encoding of the 'as-is' parameter, thusly: "/Portfolio/20020916".
How does it encode instructions for the client to do this in some
standard way, barring HTML as a specific solution?  Does Xforms
address this problem?

Would there be any particular reason to prefer
"/Portfolio?asof=20020916" or some other encoding over the one
above?

Walden






-----------------------------------------------------------------------------------
Post ID:2567
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-16 17:00:54
Subject:Re: [rest-discuss] Client-composed URI
Message:

Mathews, Walden wrote:
> Paul,
> 
> In your "first principles" posting of last Friday, there was
> an interesting bit on queries and how the client can, by following
> instructions from the server, participate in the composition of
> query-extended URI.
> 
> I want to ask a general question about how this should work, independent
> of HTML and current browser technology, where I understand its
> working well enough.
> 
> Making no assumptions about the format of the entities, what can
> be said about a standard for providing (server) and following (client)
> instructions for extending URI with query parameters?

WSDL and WRDL both have facilities to allow this.

> Here's my real-life example from a current project.  A Portfolio
> resource (let's say it's at URI: "/Portfolio") undergoes changes, but
> can be retrieved via "as of" snapshots.  The client does not care
> exactly when the Portfolio changed; it only needs to know "what was
> my Portfolio as-of 2002-09-16 end-of-business?".  The server may
> choose to impose the convention of appending a simple yyyymmdd
> encoding of the 'as-is' parameter, thusly: "/Portfolio/20020916".
> How does it encode instructions for the client to do this in some
> standard way, barring HTML as a specific solution?  Does Xforms
> address this problem?

Yes, XForms supports query construction. WSDL and WRDL are design-time 
standards. XForms is a runtime standard. So it depends on which you 
want. But if you are doing it at runtime, then consider using a 
hyperlink instead. It requires less client-side knowledge to navigate a 
hyperlink.

> Would there be any particular reason to prefer
> "/Portfolio?asof=20020916" or some other encoding over the one
> above?

There are two resources:

/Portfolio
/Portfolio/20020916

Common wisdom (Jeff Bone would say "dogma") in the Web architecture 
world is that the client should not construct the URI for latter from 
the former. Basically if you tell the client to do that, then you are 
committing to that exact naming scheme forever. For instance someone 
could make a hyperlink today to a document that will come into existence 
in 2003. On the other hand, if you put in a level of indirection between 
the resources then the client is told that you reserve the right to 
change your naming convention any time. Here's how you do that:

-->
GET /Portfolio?asof=20020916

<--
200 OK
<resource asof="20020916" href="/Portfolio/20020916"/>

Then client applications dereference through that query to get at the 
concrete resource associated with a particular date. The query language 
could be arbitrarily complex. As in:

-->
GET /Portfolio?from=20020913;to=20020918

<--
200 OK
<resources>
<resource asof="20020913" href="/Portfolio/20020913"/>
<resource asof="20020914" href="/Portfolio/20020914"/>
<resource asof="20020914" href="/Portfolio/20020915"/>
<resource asof="20020914" href="/Portfolio/20020916"/>
</resources>

Admittedly the indirection has costs. But essentially your "contract" is 
now only to maintain the indirection service, not to keep the same URI 
naming scheme forever. Your successor might appreciate the freedom. The 
same might go for anyone implementing duplicates of your service 
elsewhere in the world. Maybe they want to serve portfolio snapshots 
through ftp: or from a seperate server @....

That said, you can achieve a similar effect using redirect status codes. 
  I think that the difference is in the contract you are signing up for.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2568
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-09-16 17:13:42
Subject:Re: [rest-discuss] REST presentation
Message:

> > On Sun, 15 Sep 2002, Mark Baker wrote:
> > 
> > > I gave a presentation last week to the WSAWG, basically comparing REST
> > > to some other architectural styles.
> > > 
> > > http://www.markbaker.ca/2002/08/Rest/
> > 
> > DO you see a strong overlap between applications or systems that would use
> > these different architectural styles?
> 
> There's some overlap, for sure.  Between OO-RPC - which is basically the Web
> services style - and REST, there's definitely a *lot* of overlap.
> 
> > For example if under REST "hypertext
> > is the engine of application state", a tuple-space application's state
> > might well be determined by URIs being put up into the tuple space, with
> > documents being taken down from the tuple space and returned to the larger
> > system.
> 
> I don't think that's a great example, but I'm all for thinking about
> new constraints which could be added to REST to induce new useful
> properties, such as Rohit's work on ALIN.

One might wish to gain the benefits distributed processing (eg, through
tuple space), and even of the http protocol, without necessarity using
http VERBs -- particularly where the process is "atomic." See Jeff Bone's
"Dining Philosophers" discussion at

    http://www.xent.com/pipermail/fork/2001-August/002923.html

<quote>
The lesson is pretty clear:  it's always a bad idea to manage
transactions (i.e., attempt to guarantee atomicity of a sequence of
actions, *even if this is made possible by the underlying communication
model*) non-locally.  Whenever possible --- and it's always possible ---
atomic sequences of interactions should be managed by intermediate objects
local to the resources being locked and manipulated;  it's trivial to
encapsulate transactions into a single atomic exchange, and exposing those
encapsulations as first class entities is generally a pretty good idea.  
And it certainly fits with the REST model of the world.  MUCH more so, in
fact, than RPC
</quote>

So the set of tasks that REST *should* do is a subset of the tasks that
REST *can* do.

So my example may or may not be "great", but I'm not sure whether you mean
its lack of greatness lies in being a poor illustration of REST
principles, or whether you think it's just one more bad idea. Can you
elucidate? Thanks.

Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.goose-works.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2569
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-16 17:21:39
Subject:Re: [rest-discuss] Client-composed URI
Message:

From: "Paul Prescod" <paul@...>
>
> There are two resources:
>
> /Portfolio
> /Portfolio/20020916
>
> Common wisdom (Jeff Bone would say "dogma") in the Web architecture
> world is that the client should not construct the URI for latter from
> the former. Basically if you tell the client to do that, then you are
> committing to that exact naming scheme forever. For instance someone
> could make a hyperlink today to a document that will come into existence
> in 2003. On the other hand, if you put in a level of indirection between
> the resources then the client is told that you reserve the right to
> change your naming convention any time. Here's how you do that:
>
> -->
> GET /Portfolio?asof=20020916
>
> <--
> 200 OK
> <resource asof="20020916" href="/Portfolio/20020916"/>
>
> Then client applications dereference through that query to get at the
> concrete resource associated with a particular date.

I recently noticed the Content-Location header in the HTTP.  Could this be
used for such a purpose?  Instead of requiring redirection (which means
additional network traffic), you could return the expected response pluse
the header:

-->
GET /Portfolio?asof=20020916

<--
200 OK
Content-Location: /Protfolio/20020916

<response-entity here>


I know this would not work for the complex query example you gave, but in
the case where you are querying for a single resource... maybe?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2570
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-16 17:46:21
Subject:Re: [rest-discuss] Client-composed URI
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> -->
> GET /Portfolio?from=20020913;to=20020918
>
> <--
> 200 OK
> <resources>
> <resource asof="20020913" href="/Portfolio/20020913"/>
> <resource asof="20020914" href="/Portfolio/20020914"/>
> <resource asof="20020914" href="/Portfolio/20020915"/>
> <resource asof="20020914" href="/Portfolio/20020916"/>
> </resources>
>
Wouldn't the client need to know as much information to /deconstruct/ the
data as it would to /construct/ the URIs? Both have 'asof' as a nifty name,
and both have '20020914',etc as the syntax and value space for that name.








-----------------------------------------------------------------------------------
Post ID:2571
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-16 19:43:25
Subject:RE: [rest-discuss] Client-composed URI
Message:

Paul Prescod wrote:

> But if you are doing it at runtime, then consider using a 
> hyperlink instead. It requires less client-side knowledge to 
> navigate a hyperlink.

That would have been my first choice, but there seem to be
infinitely many of them, as in your description before of resources
so large they can only be addressed reasonably through search
parameters.  I think this is the same, because 'as of' is
not constrained to any particular time segment or time granularity
(even though I indicated business-day granularity before).

Maybe I don't understand what you mean by "consider using a
hyperlink instead."

> Common wisdom (Jeff Bone would say "dogma") in the Web architecture 
> world is that the client should not construct the URI for latter from 
> the former. Basically if you tell the client to do that, then you are 
> committing to that exact naming scheme forever.

What if the client is following a set of (dynamic) instructions
from the server on how to construct such a URL?  If the naming
scheme changes, then so does the instructions.


> For instance someone 
> could make a hyperlink today to a document that will come 
> into existence 
> in 2003. On the other hand, if you put in a level of 
> indirection between 
> the resources then the client is told that you reserve the right to 
> change your naming convention any time. Here's how you do that:
> 
> -->
> GET /Portfolio?asof=20020916
> 
> <--
> 200 OK
> <resource asof="20020916" href="/Portfolio/20020916"/>

Okay, I get the indirection bit, but along the way I wondered
how the client knew how to do that GET.  Did I tell her how to
format that?

> 
> Then client applications dereference through that query to get at the 
> concrete resource associated with a particular date. The 
> query language 
> could be arbitrarily complex. As in:
> 
> -->
> GET /Portfolio?from=20020913;to=20020918
> 
> <--
> 200 OK
> <resources>
> <resource asof="20020913" href="/Portfolio/20020913"/>
> <resource asof="20020914" href="/Portfolio/20020914"/>
> <resource asof="20020914" href="/Portfolio/20020915"/>
> <resource asof="20020914" href="/Portfolio/20020916"/>
> </resources>
> 
> Admittedly the indirection has costs. But essentially your 
> "contract" is 
> now only to maintain the indirection service, not to keep the 
> same URI 
> naming scheme forever. Your successor might appreciate the 
> freedom. The 
> same might go for anyone implementing duplicates of your service 
> elsewhere in the world. Maybe they want to serve portfolio snapshots 
> through ftp: or from a seperate server @....

Hmmm.  I think you're still assuming that there is a finite
number of these resources and that given the right question,
the server can dish up a finite set of references for getting
at them.  Time ain't like that.

While asking the original question, I realized that a better
application design on the server side keeps a versioning history
and so could offer a list of versions as you have above. 
Unfortunately, the legacy app hiding behind my web service
wasn't that smart. 8-(

Walden






-----------------------------------------------------------------------------------
Post ID:2572
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-16 21:16:44
Subject:Re: [rest-discuss] Client-composed URI
Message:

S. Mike Dierken wrote:
> ----- Original Message -----
> From: "Paul Prescod" <paul@...>
> 
>>-->
>>GET /Portfolio?from=20020913;to=20020918
>>
>><--
>>200 OK
>><resources>
>><resource asof="20020913" href="/Portfolio/20020913"/>
>><resource asof="20020914" href="/Portfolio/20020914"/>
>><resource asof="20020914" href="/Portfolio/20020915"/>
>><resource asof="20020914" href="/Portfolio/20020916"/>
>></resources>
>>
> Wouldn't the client need to know as much information to /deconstruct/ the
> data as it would to /construct/ the URIs? Both have 'asof' as a nifty name,
> and both have '20020914',etc as the syntax and value space for that name.

There are two reasons I think not. First, there are some clients that 
don't care about the meaning of asof and will just blindly chase down 
all of the links. Great: we've enabled a different kind of application 
to do something useful. Whereas constructing URIs requires the knowledge 
that you shouldn't try to construct URIs into the future or the distant 
past.

Second, I think that between the client that understands none of the 
semantics except hyperlinking (e.g. Google) and the client that 
understands everything there can be clients that use semantic 
technologies to understand *some things*. For instance maybe I don't 
know what a portfolio is but I know what a "date-versioned document" is 
and I know how to retreive and organize "date-versioned documents". It's 
pretty easy in the semweb technologies to define the type 
"data-versioned document" and subtype it to get to "date-versioned 
portfolio." I don't know how to do that with query construction 
technologies.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2573
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-16 21:43:16
Subject:Re: [rest-discuss] Client-composed URI
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

>
> There are two reasons I think not. First, there are some clients that
> don't care about the meaning of asof and will just blindly chase down
> all of the links. Great: we've enabled a different kind of application
> to do something useful.
But I don't get paid to deliver a different kind of application. (Okay...
right now I don't get paid at all...)
Explicit links are fine - and they do have the nice property of
opaque/low-intelligence retrievals.
But for the main use-case of getting a particular portfolio, the client
still needs to know which link is the right link. And that requires knowing
(in your example) the name 'asof' and the value '20020914'. The client pops
these two data items into a function and out pops a URI. Either
algorithmically constructed or retrieved via a lookup - not much difference,
except that transferring lookup tables isn't all that scalable and doesn't
reduce coupling.


> Whereas constructing URIs requires the knowledge
> that you shouldn't try to construct URIs into the future or the distant
> past.
That is a 'nice-to-have' not a 'need-to-have'.

>
> Second, I think that between the client that understands none of the
> semantics except hyperlinking (e.g. Google) and the client that
> understands everything there can be clients that use semantic
> technologies to understand *some things*. For instance maybe I don't
> know what a portfolio is but I know what a "date-versioned document" is
> and I know how to retreive and organize "date-versioned documents".
How would the client "know how to retrieve 'date-versioned documents'"?
Isn't that what we are talking about?

> It's pretty easy in the semweb technologies to define the type
> "data-versioned document" and subtype it to get to "date-versioned
> portfolio." I don't know how to do that with query construction
> technologies.
Knowing the type/meaning is not the same as knowing how to retrieve the
information. The 'query contruction technologies' is the 'how to retrieve'
part. The semweb technologies you mentioned don't talk about it. You just
essentially said 'assume I know how to retrieve one'...








-----------------------------------------------------------------------------------
Post ID:2574
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-09-16 21:56:26
Subject:Re: Client-composed URI
Message:

Walden,

The way I usually solve this problem is to do as paul says except:

- Use the HTTP 302 Found status code to redirect the client. In 
other words, the client queries the portfolio resource by saying 
GET /Portfolio/?asof=2343232 and the server responds with HTTP 302 
Found and in the Location header put the URL of the resource. If you 
have multiple resources that might be returned then do the same 
thing with the vanillar 200 OK.

- itdp

--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
> Mathews, Walden wrote:
> > Paul,
> > 
> > In your "first principles" posting of last Friday, there was
> > an interesting bit on queries and how the client can, by 
following
> > instructions from the server, participate in the composition of
> > query-extended URI.
> > 
> > I want to ask a general question about how this should work, 
independent
> > of HTML and current browser technology, where I understand its
> > working well enough.
> > 
> > Making no assumptions about the format of the entities, what can
> > be said about a standard for providing (server) and following 
(client)
> > instructions for extending URI with query parameters?
> 
> WSDL and WRDL both have facilities to allow this.
> 
> > Here's my real-life example from a current project.  A Portfolio
> > resource (let's say it's at URI: "/Portfolio") undergoes 
changes, but
> > can be retrieved via "as of" snapshots.  The client does not care
> > exactly when the Portfolio changed; it only needs to know "what 
was
> > my Portfolio as-of 2002-09-16 end-of-business?".  The server may
> > choose to impose the convention of appending a simple yyyymmdd
> > encoding of the 'as-is' parameter, thusly: "/Portfolio/20020916".
> > How does it encode instructions for the client to do this in some
> > standard way, barring HTML as a specific solution?  Does Xforms
> > address this problem?
> 
> Yes, XForms supports query construction. WSDL and WRDL are design-
time 
> standards. XForms is a runtime standard. So it depends on which 
you 
> want. But if you are doing it at runtime, then consider using a 
> hyperlink instead. It requires less client-side knowledge to 
navigate a 
> hyperlink.
> 
> > Would there be any particular reason to prefer
> > "/Portfolio?asof=20020916" or some other encoding over the one
> > above?
> 
> There are two resources:
> 
> /Portfolio
> /Portfolio/20020916
> 
> Common wisdom (Jeff Bone would say "dogma") in the Web 
architecture 
> world is that the client should not construct the URI for latter 
from 
> the former. Basically if you tell the client to do that, then you 
are 
> committing to that exact naming scheme forever. For instance 
someone 
> could make a hyperlink today to a document that will come into 
existence 
> in 2003. On the other hand, if you put in a level of indirection 
between 
> the resources then the client is told that you reserve the right 
to 
> change your naming convention any time. Here's how you do that:
> 
> -->
> GET /Portfolio?asof=20020916
> 
> <--
> 200 OK
> <resource asof="20020916" href="/Portfolio/20020916"/>
> 
> Then client applications dereference through that query to get at 
the 
> concrete resource associated with a particular date. The query 
language 
> could be arbitrarily complex. As in:
> 
> -->
> GET /Portfolio?from=20020913;to=20020918
> 
> <--
> 200 OK
> <resources>
> <resource asof="20020913" href="/Portfolio/20020913"/>
> <resource asof="20020914" href="/Portfolio/20020914"/>
> <resource asof="20020914" href="/Portfolio/20020915"/>
> <resource asof="20020914" href="/Portfolio/20020916"/>
> </resources>
> 
> Admittedly the indirection has costs. But essentially 
your "contract" is 
> now only to maintain the indirection service, not to keep the same 
URI 
> naming scheme forever. Your successor might appreciate the 
freedom. The 
> same might go for anyone implementing duplicates of your service 
> elsewhere in the world. Maybe they want to serve portfolio 
snapshots 
> through ftp: or from a seperate server @....
> 
> That said, you can achieve a similar effect using redirect status 
codes. 
>   I think that the difference is in the contract you are signing 
up for.
> 
>   Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2575
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-17 00:14:44
Subject:Re: [rest-discuss] Client-composed URI
Message:

S. Mike Dierken wrote:
 >...
 >
 > But I don't get paid to deliver a different kind of application. (Okay...
 > right now I don't get paid at all...)
 > Explicit links are fine - and they do have the nice property of
 > opaque/low-intelligence retrievals.

To me, one of the central goals of REST is to allow new applications to
be created later that I didn't foresee in the beginning. That's a big
part of my definition of "loose coupling".

 > But for the main use-case of getting a particular portfolio, the client
 > still needs to know which link is the right link. And that requires 
knowing
 > (in your example) the name 'asof' and the value '20020914'.

Yes, in the most tightly bound scenario where the client knows
everything interesting about the server and is specifically coded to
work with that particular type of server and its datatyhpes, there is no 
difference. But  then in that case I could also just as easily use SOAP, 
CORBA or ASN.1. It's allowing the other applications that is of interest 
to me and where I think REST can contribute.

 > .... The client pops
 > these two data items into a function and out pops a URI. Either
 > algorithmically constructed or retrieved via a lookup - not much 
difference,
 > except that transferring lookup tables isn't all that scalable and 
doesn't
 > reduce coupling.

Obviously I disagree on the latter point.

 >>Whereas constructing URIs requires the knowledge
 >>that you shouldn't try to construct URIs into the future or the distant
 >>past.
 >
 > That is a 'nice-to-have' not a 'need-to-have'.

If it prevents your client from hanging indefinately, it is a
"need-to-have". Basically the list version gives the client more
information than the query version. It says not only "you can try to get
data at this URI" but also: "Here are URIs that are guaranteed to work
and URIs that you don't see here are likely not to work." My philosophy
is for the server to always give as much extra information to the client
as is reasonably possible. To me that loosens binding.

 >...
 > How would the client "know how to retrieve 'date-versioned documents'"?
 > Isn't that what we are talking about?

No, we're talking about specifically date-versioned portfolios not the
more generic concept of date-versioned resources. I'm trying to
introduce the notion of subtyping. Subtyping on the Web is well-defined
for graphs of links, but not for queries (though that is perhaps doable
-- nobody has thought it through).

 >...
 >
 > Knowing the type/meaning is not the same as knowing how to retrieve the
 > information. The 'query contruction technologies' is the 'how to 
retrieve'
 > part. The semweb technologies you mentioned don't talk about it. You just
 > essentially said 'assume I know how to retrieve one'...

Basically you see a URI, you invoke GET. The question is how do I filter 
to certain dates. I already pretty much know how to do that right now 
using the N3 implementation CWM (presuming the data is somehow 
interperable as RDF). Of course saving the documents to the local hard 
disk is a side-effect that is outside the scope of N3.

But anyhow, the part I could do in N3 is: "Start with this URI which is 
a list of 'date-versioned resources'. By definition each one has a date. 
Get the ones that are less than 5 days old (some hand waving around date 
functions here...). Then dereference each of them and parse them as RDF. 
Then look for a 'VersionType' property and return me the set where the 
'VersionType' is "Major", not "Minor".'

Although it sounds like I am telling it the order of operations of 
course I wouldn't really. It could do a depth-first search for relevant 
data or get them all and then filter, based on its own best judgement.

The N3 "query" will automatically work with any subtype of 
"date-versioned-resource" including "date-versioned purchase order" or 
"date-versioned home page" or "date-versioned portfolio." It will also 
work with any resource that N3 knows how to interpret *as* a 
date-versioned resource using some inferencing rules that may rename or 
compute properties.

As in object oriented programming, subtyping is usually only valuable in 
the long run, not for the very first project you apply it to. It's when 
you end up with many subtypes of the same thing that you get economies 
of scale.

   Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2576
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-17 00:38:47
Subject:Re: [rest-discuss] Client-composed URI
Message:

Mathews, Walden wrote:
>...
> What if the client is following a set of (dynamic) instructions
> from the server on how to construct such a URL?  If the naming
> scheme changes, then so does the instructions.

Then you have to rename all of your old resources to follow the scheme, 
right? My point is that the naming convention for your new resources 
should not be constrained by history nor vice versa. And anyhow, except 
for web browsers, most web app client software is not really written to 
discover parameters at runtime.

>...
> Okay, I get the indirection bit, but along the way I wondered
> how the client knew how to do that GET.  Did I tell her how to
> format that?

Yes, using something like WSDL or WRDL or XForms. In retrospect I was 
wrong to say that XForms MUST be used at runtime. There's no reason it 
isn't also useful at design time. I'll have to think about this aspect 
of XForms more...

 >...
> Hmmm.  I think you're still assuming that there is a finite
> number of these resources and that given the right question,
> the server can dish up a finite set of references for getting
> at them.  Time ain't like that.

Surely your app is not interested in all of eternity. There are a finite 
number of changes that happen.

> While asking the original question, I realized that a better
> application design on the server side keeps a versioning history
> and so could offer a list of versions as you have above. 
> Unfortunately, the legacy app hiding behind my web service
> wasn't that smart. 8-(

It must have a version history internally or how can it answer the 
question of "what was the value on this date?" But if you say that the 
version history is externally unavailable then I believe you. That's too 
bad: it constrains your design.

Anyhow, it doesn't change the point about how to deine query interfaces. 
If you want to adhere closely to Web architecture, you should do some 
kind of indirect/redirect through the query so that the resource 
relationships are not name-based.

It might be a valid engineering choice to short-circuit the 
query-redirect for simplicity or performance reasons. If so, I'd suggest 
still to use query params rather than slashes for compatibility with 
today's Web and with languages like HTML, WRDL and XForms.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2577
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-17 04:32:05
Subject:Re: [rest-discuss] Client-composed URI
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

>
>  > But for the main use-case of getting a particular portfolio, the client
>  > still needs to know which link is the right link. And that requires
> knowing
>  > (in your example) the name 'asof' and the value '20020914'.
>
> Yes, in the most tightly bound scenario where the client knows
> everything interesting about the server and is specifically coded to
> work with that particular type of server and its datatyhpes, there is no
> difference.
Nobody but you said the client knows everything interesting about the
server.
All I'm pointing out is that the client needs to know the same amount of
information in both approaches.
A client that generates a URI via an algorithm knows only as much as a
date-versioned aware client.
Since the algorithmic approach has no innate bounds (in this example) you
may want to surface them and make them explicit - but that is not my point
and I don't care one way or the other at this time. The lookup based
approach has no need for this, but it also does not provide or have access
to that semantic information (of the allowable/exising bounds) either.

> But  then in that case I could also just as easily use SOAP,
> CORBA or ASN.1. It's allowing the other applications that is of interest
> to me and where I think REST can contribute.

>
>  > .... The client pops
>  > these two data items into a function and out pops a URI. Either
>  > algorithmically constructed or retrieved via a lookup - not much
> difference,
>  > except that transferring lookup tables isn't all that scalable and
> doesn't
>  > reduce coupling.
>
> Obviously I disagree on the latter point.
If both approaches have a dependency on exactly the same information then
the coupling is exactly the same.

>
>  >>Whereas constructing URIs requires the knowledge
>  >>that you shouldn't try to construct URIs into the future or the distant
>  >>past.
>  >
>  > That is a 'nice-to-have' not a 'need-to-have'.
>
> If it prevents your client from hanging indefinately, it is a
> "need-to-have".
If the resources have nearly infinite granularity then the lookup table will
hang the client and avoiding a hyperlinking approach is also required.
Looks like we are stuck. Can't get there from here.


> Basically the list version gives the client more
> information than the query version. It says not only "you can try to get
> data at this URI" but also: "Here are URIs that are guaranteed to work
> and URIs that you don't see here are likely not to work."
A list does not say the second part. If it did, then the list would have to
be a full and not partial list. Which isn't scalable in my opinion - very
large data sets would choke even the copious bandwidth we have today.

> My philosophy
> is for the server to always give as much extra information to the client
> as is reasonably possible. To me that loosens binding.
Earlier you said that the algorithmic approach would need to know the
constraints (boundary, past/future, etc.) Since this is extra information
that is provided to the client, isn't this an example of what you consider
'loosened coupling'?


>
>  >...
>  > How would the client "know how to retrieve 'date-versioned documents'"?
>  > Isn't that what we are talking about?
>
> No, we're talking about specifically date-versioned portfolios not the
> more generic concept of date-versioned resources. I'm trying to
> introduce the notion of subtyping. Subtyping on the Web is well-defined
> for graphs of links, but not for queries (though that is perhaps doable
> -- nobody has thought it through).
>
>  >...
>  >
>  > Knowing the type/meaning is not the same as knowing how to retrieve the
>  > information. The 'query contruction technologies' is the 'how to
> retrieve'
>  > part. The semweb technologies you mentioned don't talk about it. You
just
>  > essentially said 'assume I know how to retrieve one'...
>
> Basically you see a URI, you invoke GET. The question is how do I filter
> to certain dates. I already pretty much know how to do that right now
> using the N3 implementation CWM (presuming the data is somehow
> interperable as RDF). Of course saving the documents to the local hard
> disk is a side-effect that is outside the scope of N3.
Sorry... too many acronyms. Can you provide an example?

Sounds like you are advocating retrieving a (possibly very large) lookup
table and doing local queries. The 'filter to certain dates' is an operation
upon that local data - and that filter would need the same input data as a
client-composed URI (namely 'asof' and the date
syntax/value-space/meaning/whatever).

>
> But anyhow, the part I could do in N3 is: "Start with this URI which is
> a list of 'date-versioned resources'. By definition each one has a date.
> Get the ones that are less than 5 days old (some hand waving around date
> functions here...).
I think I'm beginning to glimpse what you are getting at. The same
information ('asof' and dates) is used to crawl local content (retrieved
from a generic uri), rather than to directly address a remote resource... is
that correct?

> Then dereference each of them and parse them as RDF.
> Then look for a 'VersionType' property and return me the set where the
> 'VersionType' is "Major", not "Minor".'
>
> Although it sounds like I am telling it the order of operations of
> course I wouldn't really. It could do a depth-first search for relevant
> data or get them all and then filter, based on its own best judgement.
>
> The N3 "query" will automatically work with any subtype of
> "date-versioned-resource" including "date-versioned purchase order" or
> "date-versioned home page" or "date-versioned portfolio." It will also
> work with any resource that N3 knows how to interpret *as* a
> date-versioned resource using some inferencing rules that may rename or
> compute properties.
Queries (which is a form of addressing) performed upon local content
content, rather than queries turned into addresses and remote content
accessed directly.

>
> As in object oriented programming, subtyping is usually only valuable in
> the long run, not for the very first project you apply it to. It's when
> you end up with many subtypes of the same thing that you get economies
> of scale.
The same re-application probably would not work with composed URIs out of
the box. But if you've got content-manipulation approaches (arch forms, name
mapping, etc.) executed on the client, then I supposed that same slot could
be filled with mappings of the declarative rules for generating URIs also.








-----------------------------------------------------------------------------------
Post ID:2578
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-17 04:34:14
Subject:Re: [rest-discuss] Client-composed URI
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

>
> Anyhow, it doesn't change the point about how to deine query interfaces.
> If you want to adhere closely to Web architecture, you should do some
> kind of indirect/redirect through the query so that the resource
> relationships are not name-based.
Does this mean converting query based URIs into path-based URI? If URI are
opaque, what does it matter?






-----------------------------------------------------------------------------------
Post ID:2579
Sender:"firepipe_au" <michael@...>
Post Date/Time:2002-09-17 04:30:34
Subject:PUT and FTP legacy
Message:

Just some thoughts on PUT/POST and query strings

Seairth mentioned the baggage of FTP in the HTTP RFC.  I tend to 
agree that PUT looks suspiciously to me like PUT <file>.  Harkening 
back to FTP, a server administrator can easily set up an area (let's 
call it /incoming/) where users can dump files without security 
clearance.  If one user PUTs a file called "my_worm.exe", there is 
nothing stopping another user PUTting a different file with exactly 
the same name, overwriting the first.  The FTP server will not 
complain, because it's a non-privileged area.  PUT is idempotent in 
this case: great.

Point 1:
I can't see how this can work on an HTTP server.  You need to set up 
that non-privileged area to protect /your/ documents from being 
overwritten. If you are setting up a non-privileged area, that 
implies that all of your other areas a privileged, which is almost 
never the case.  PUT (in this simple and I believe originally 
intended FTP sense) in this instance creates a really massive 
overhead of creating authentication schemes for everywhere but some 
public space.  You don't have any of your own processors working 
behind the scenes here, so you've got to rely on your server 
software's authentication schemes, which may or may not allow you to 
restrict a PUT operation while allowing GETs (couldn't find such a 
thing with Apache, for instance) on any particular area.

Point 2:
Then again, GET on its own isn't particularly useful for Web services 
until you start adding query strings onto the end of it.  If PUT is 
in some senses the 'reverse' operation of GET, why haven't I seen 
anyone mention the possibility of

PUT http://www.server.org/processor?name=Babs+Jensen&phone=88889999 
HTTP/1.1

Doesn't this make PUT an idempotent operation?  When I do

GET http://www.server.org/processor?name=Babs+Jensen&phone=88889999 
HTTP/1.1

I should get

200 OK
name=Babs Jensen
phone=88889999

If I am to expect PUT/GET symmetry as Paul would have it.  Though I 
don't think he would disagree with making

GET http://www.server.org/processor?name=Babs+Jensen HTTP/1.1

200 OK
name=Babs Jensen
phone=88889999

also available, as a different representation of the state of Babs 
(because the first GET isn't particularly useful to me as a client).

Incidentally, I should expect that POST in this situation:

POST http://www.server.org/processor HTTP/1.1
Content-type: text/plain
Content-length: 30

name=Babs Jensen
phone=88889999

Would result in subsequest GETs producing

200 OK
name=Babs Jensen
phone=88889999
name=Babs Jensen
phone=88889999

or something of the sort, as it's not idempotent.


The crux:
To take yourself beyond the capabilities of your vanilla web server 
installation, you need URIs with the query string for GETs and PUTs.  
Furthermore, the presence of "?" in your URI implies the use of extra 
processing that will require discovery for usage.  POST always 
implies the presence of such a processor.

I can see why PUT hasn't really caught on, considering the security 
problems it seems to present.  But by using the query string with 
PUT, I believe I have solved my problem of non-privileged areas: now 
the Web server can trivially identify the difference between copying 
a file (generally a no-no without explicitly saying its OK) and 
passing some parameters to an add-on processor (which should know 
what it's doing).
Of course, I can envision one nasty problem with this: the limitation 
on the length of query strings.  It would require that your processor 
would never allow its parameter name-value pairs to exceed that 
limit, although this may encourage more modular designs.

Is this a useful way of looking at it?  Can I also not use a 201 
Created response for PUT <file> and a 205 Reset Content for PUT 
<processor with query string>? (OK, so it looks like 205 wasn't 
really intended for such a thing, but it still implies modification 
over creation).










-----------------------------------------------------------------------------------
Post ID:2580
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-17 04:50:38
Subject:Re: [rest-discuss] PUT and FTP legacy
Message:

----- Original Message -----
From: "firepipe_au" <michael@...>

> If PUT is
> in some senses the 'reverse' operation of GET, why haven't I seen
> anyone mention the possibility of
>
> PUT http://www.server.org/processor?name=Babs+Jensen&phone=88889999
> HTTP/1.1
>
> Doesn't this make PUT an idempotent operation?
PUT is already idempotent. Multiple requests result in the same thing as a
single request.

> When I do
>
> GET http://www.server.org/processor?name=Babs+Jensen&phone=88889999
> HTTP/1.1
>
> I should get
>
> 200 OK
> name=Babs Jensen
> phone=88889999
Depends on what was PUT in the first request... was there supposed to be an
entity body there?

Is there some point to putting the data in query strings rather than in the
body?

>
> If I am to expect PUT/GET symmetry as Paul would have it.  Though I
> don't think he would disagree with making
>
> GET http://www.server.org/processor?name=Babs+Jensen HTTP/1.1
>
> 200 OK
> name=Babs Jensen
> phone=88889999
>
> also available, as a different representation of the state of Babs
> (because the first GET isn't particularly useful to me as a client).
>
> Incidentally, I should expect that POST in this situation:
>
> POST http://www.server.org/processor HTTP/1.1
> Content-type: text/plain
> Content-length: 30
>
> name=Babs Jensen
> phone=88889999
>
> Would result in subsequest GETs producing
>
> 200 OK
> name=Babs Jensen
> phone=88889999
> name=Babs Jensen
> phone=88889999
>
> or something of the sort, as it's not idempotent.
Depends on how the server implements it.







-----------------------------------------------------------------------------------
Post ID:2581
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-09-17 08:02:14
Subject:RE: [rest-discuss] REST without PUT and other things...
Message:

> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Saturday, September 14, 2002 9:01 PM
> To: rest-discuss
> Subject: [rest-discuss] REST without PUT and other things...
>
>
> In a recent post [1], I was asking about performing resource creation with
> POST only.  My conclusion has been that this is a good thing.
> What's more,
> as I was falling asleep last night, additional thoughts occurred
> to me that
> I now feel the need to share with the list.  Tell me what you think...
>
>
> I contend that PUT does not fit well with the REST model.  First, there is
> the issue of resource creation.  PUT is allowed to submit a "non-existing"
> request-URI as if it did exist.  This request-URI has no identity
> whatsoever
> (not even with the request-entity that will become the new
> resource).  From
> my ever-evolving understanding of REST, allowing the usage of URIs in this
> manner is just plain wrong.  I absolutely agree with this regardless of
> REST.  As I recently mentioned [1], I feel that using POST to create all
> resources is just as effective and keeps the URI rules simple.

IMHO,

the URI exists all the time. It just isn't mapped to a particular resource.

Keep in mind that *one* usage of HTTP is *authoring* of web sites, and
that's where PUT is already heavy usage (through WebDAV/Microsoft
Webfolders/IIS/Apache moddav), and I don't see any problem with that (a part
from how to handle authoring of varying resources, as recently discussed on
the URI mailing list).

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760







-----------------------------------------------------------------------------------
Post ID:2582
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-17 13:40:22
Subject:RE: [rest-discuss] Client-composed URI
Message:

 >...
> > What if the client is following a set of (dynamic) instructions
> > from the server on how to construct such a URL?  If the naming
> > scheme changes, then so does the instructions.
> 
> Then you have to rename all of your old resources to follow 
> the scheme, 
> right? My point is that the naming convention for your new resources 
> should not be constrained by history nor vice versa. And 
> anyhow, except 
> for web browsers, most web app client software is not really 
> written to 
> discover parameters at runtime.

Yes, and it clarifies that part of your "first principles" essay
in that instructions for formatting query URI is not enough to keep
query stuff extensible.  Indirection is needed.  Is that a second
principle?


> 
> >...
> > Okay, I get the indirection bit, but along the way I wondered
> > how the client knew how to do that GET.  Did I tell her how to
> > format that?
> 
> Yes, using something like WSDL or WRDL or XForms. In retrospect I was 
> wrong to say that XForms MUST be used at runtime. There's no 
> reason it 
> isn't also useful at design time. I'll have to think about 
> this aspect 
> of XForms more...

Here's what I want to happen.  Client does GET on /Portfolios/123 and
gets back two things

	(1) default representation (as of now) of portfolio 123
	(2) Xforms form for requesting other version of portfolio 123

By filling in a date field in the form and following (or invoking)
standard Xforms protocol, a search URI is synthesized according to
server sytax rules and a GET performed on that...

Sounds reasonable?

>  >...
> > Hmmm.  I think you're still assuming that there is a finite
> > number of these resources and that given the right question,
> > the server can dish up a finite set of references for getting
> > at them.  Time ain't like that.
> 
> Surely your app is not interested in all of eternity. There 
> are a finite 
> number of changes that happen.

If you saw this app, you'd understand that it's interested in
all of eternity.  It's the one I referred to somewhere as choking
on its own transaction excreta.

But no, it's not interested in a timeline that extends infinitely
in both directions, but it is interested in a time segment that
has infinitely many moments on it.  That's because it maintains
big bags of transactions, but no versions, so to find the 'as of'
state, it has to go back to genesis and run history forward.

This has been a worthwhile exchange for me.  I was thinking last
week of writing a proposal for "Versioned Portfolio" design enhancement.
This adds fuel to the fire.  If Portfolio were adequagely versioned,
the query stuff would fall away entirely.
 
> It might be a valid engineering choice to short-circuit the 
> query-redirect for simplicity or performance reasons. If so, 
> I'd suggest 
> still to use query params rather than slashes for compatibility with 
> today's Web and with languages like HTML, WRDL and XForms.

OK.


Walden






-----------------------------------------------------------------------------------
Post ID:2583
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-17 13:53:16
Subject:Re: [rest-discuss] REST presentation
Message:

On Mon, Sep 16, 2002 at 01:13:42PM -0400, Sam Hunting wrote:
> So my example may or may not be "great", but I'm not sure whether you mean
> its lack of greatness lies in being a poor illustration of REST
> principles, or whether you think it's just one more bad idea. Can you
> elucidate? Thanks.

The latter.  At least that's my first impression.

I *do* believe there's new and useful systems yet to be developed that
improve upon REST.  But I believe that they will happen primarily as
extensions, i.e. with *additional* constraints added, not existing
constraints relaxed or removed.

I believe that the Web has changed the way we look at all forms of
distributed computing, and has done it for all time - at least
until something else as disruptive comes along.  But that won't be
for quite a while, since it itself still has many more years of
room for innovation left in it.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2584
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-17 13:57:22
Subject:RE: [rest-discuss] Re: Client-composed URI
Message:


> -----Original Message-----
> From: inthedarkplace [mailto:inthedarkplace@...]
> Sent: Monday, September 16, 2002 5:56 PM
> To: rest-discuss@yahoogroups.com
> Subject: [rest-discuss] Re: Client-composed URI
> 
> 
> Walden,
> 
> The way I usually solve this problem is to do as paul says except:
> 
> - Use the HTTP 302 Found status code to redirect the client. In 
> other words, the client queries the portfolio resource by saying 
> GET /Portfolio/?asof=2343232 and the server responds with HTTP 302 
> Found and in the Location header put the URL of the resource. If you 
> have multiple resources that might be returned then do the same 
> thing with the vanillar 200 OK.
> 
> - itdp

Don't you mean "verniller"?  And doesn't 302 mean kind of the
reverse of what you're using it for here?

Thanks,
Walden






-----------------------------------------------------------------------------------
Post ID:2585
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-17 14:04:25
Subject:Re: [rest-discuss] formalizing a model (was Re: [fielding@apache.org: Re: Resources always exi st]
Message:

On Fri, Sep 13, 2002 at 12:35:06PM -0400, Seairth Jacobs wrote:
> What/which model are we talking about here?  Can someone list a few aspects
> of what this model is about?  I'm always interested in helping in this sort
> of thing, but I am having trouble figuring out what the model is in the
> first place.

Stuff like the existential details of resources and the relationship to
its representations.  Then we could take that, and build a set of
methods that would be slightly more general than PUT/DELETE (I've said
that I believe GET is axiomatic, and likely POST too).

PUT/DELETE, as defined in 2616, seem to be optimized for the "web
authoring" use case, which while mappable to the kinds of things we
talk about doing with REST, have some quirks that make some things
awkward.  As an example, SOAP can't use PUT because of the assumption of
PUT that the body is data-to-be-stored rather than a
representation-to-be-set.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2586
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-17 14:05:47
Subject:Existance of URIs (was Re: REST without PUT and other things...)
Message:

From: "Julian Reschke" <julian.reschke@...>
>
> IMHO,
>
> the URI exists all the time. It just isn't mapped to a particular
resource.


I have a hard time agreeing to this statement.  Sure, if you want to get
philosophical about the existence of URIs, one could argue that there is an
infinite number of URIs in existence.  But in practice, this view just does
not work (at least for me).  To illustrate, think of written language.  If
you were to encounter the following word:

        vocabulary

you would know what it meant.  You recognize this as a word.  You can map
the word to its meaning (the resource).  In fact, I can give you any word
and you can come up with its meaning because they *all* have mappings to a
meaning.

However, if you were to encounter:

        twipperty

what would you say it is?  It has no meaning (no mapping to a resource).  Is
it a word?  Of course not!  Will it eventually be a word?  Maybe.  But that
does not make it a word right now.

In the same way, just because you encounter something that *looks* like a
URI does not mean it's a URI.  Does that mean that examples where we see:

    http://example.com/

are not URIs?  No, these *are* URIs because they are mapped to examples in
the message.  Sure, you cannot resolve it with HTTP, but that doesn't make
it any less of a URI.  In fact, most of the time we encounter URIs in mail,
news, etc. messages, they *are* URIs because of their conceptual mappings.

But then we get to HTTP.  In HTTP, a string that looks like a URI should
never be considered an actual URI until it is mapped to a resource (just as
you would not consider "twipperty" a word until it was mapped to a meaning).
HTTP follows that rule everywhere except in *one* place: PUT.  In all other
instances, if a given URI-like string does not map to a resource, the server
returns an error telling you so.  But when you use PUT, you can actually
pass a URI-like string that might be accepted and treated like a URI by the
server.

For instance, suppose the following sequence:

GET /twipperty
PUT /twipperty

In the above example, "/twipperty" is a URI-like string, not an actual URI.
As a result, the server returns a 404 (as expected) to the first request and
a 200 (as expected) to the second request.  But if PUT was treating
"/twipperty" like an actual URI in the second request, why didn't it treat
it like one in the first request?  Simply put, because it wasn't a URI in
the first request.  It looked like one, but that didn't automatically make
it one.


Now, I am not trying to argue here that PUT is bad.  In light of other
conversations, I am still debating the value of PUT, though I do see what
Paul Prescod, et al. are saying about it.  All I am saying here is that I
think it a bad idea to act as if anything that looks like a URI actually
*is* a URI (as is evident from the ever ongoing debates over the XML
Namespace rec). Using PUT to make a non-URI into a URI by treating it as if
it were a URI already just causes confusion.

I much more like the idea of using POST to request that a URI-like string be
made into an actual URI and associated to a resource.  PUT can still be used
to update the resource through the URI, but only once the mapping exists
(and therefore the URI exists as well).  Actually, as Paul points out, POST
is a bit overloaded here.  I wouldn't mind instead a CREATE verb or
something like it that would do what I suggest with the POST.  For instance:


-->
CREATE /existingpath
Location: /existingpath/twipperty

<--
201 Created
Location: /existingpath/twipperty


This way, URIs do not exist until they have a mapping.  Period.



You can have strings that look like URIs that aren't, but you can also have
strings that look like words that aren't as well.  My four year old daughter
has no problem with understanding when something isn't a word.  Why should
URIs be any different?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2587
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-09-17 14:15:05
Subject:RE: [rest-discuss] Existance of URIs (was Re: REST without PUT and other things...)
Message:

Searth,

I really have problems following your argumentation.

RFC2616 clearly says that

1) PUT can be applied to existing resources or used to create new resources,

2) POST can only be applied to existing resources (yes, creation of a new
resource can be a side effect, but the request resource for OST must exist
in the first place), and that

3) 404 means "The server has not found anything matching the Request-URI.".

Do you really want to change all this?

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760







-----------------------------------------------------------------------------------
Post ID:2588
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-17 14:23:50
Subject:Re: [rest-discuss] Client-composed URI
Message:

S. Mike Dierken wrote:
>...

> Nobody but you said the client knows everything interesting about the
> server.
> All I'm pointing out is that the client needs to know the same amount of
> information in both approaches.

No. *One kind* of client needs to know the same amount of information in 
both approaches. *Other kinds of clients* will be enabled by an approach 
that gives more information (like "here's the list of entities 
available") rather than less information (like "guess an entity and I'll 
tell you if it is available"). The first approach enables things like 
Google to exist and the latter prevents them.

>...
> If both approaches have a dependency on exactly the same information then
> the coupling is exactly the same.

But they don't. See above.

>...
> If the resources have nearly infinite granularity then the lookup table will
> hang the client and avoiding a hyperlinking approach is also required.
> Looks like we are stuck. Can't get there from here.

As the question was originally posed, there was per-day granularity.

>...
> A list does not say the second part. If it did, then the list would have to
> be a full and not partial list. Which isn't scalable in my opinion - very
> large data sets would choke even the copious bandwidth we have today.

Paul says:

 > Sometimes the information provider has such a large database of
 > information that it is not practically (or economically) feasible for it
 > to deliver to the requestor in total or even to segment into many
 > hypermedia documents. The requestor needs to specify some reasonable
 > filter. This is a fallback position because it becomes difficult or
 > impossible for the requestor to enumerate all of the information items
 > even if this might be useful or important. Nevertheless, reality
 > requires that sometimes filtering happen on the server side and the
 > Web allows this through HTTP URI "query parameters".

http://groups.yahoo.com/group/rest-discuss/message/2540

 > ...
> Earlier you said that the algorithmic approach would need to know the
> constraints (boundary, past/future, etc.) Since this is extra information
> that is provided to the client, isn't this an example of what you consider
> 'loosened coupling'?

Providing extra information at runtime loosens coupling by making the 
service more discoverable for clients that were not designed 
specifically to work with the data. Providing extra information at 
design time makes it easier to use the service but doesn't loosen 
coupling. If you have a way of presenting the boundary information at 
runtime, in a way that can be handled by a domain-insensitive client 
like Google, then sure, throw it in. But I don't really have such a 
description language available.

>...
> Sounds like you are advocating retrieving a (possibly very large) lookup
> table and doing local queries. 

I think you need to choose between the approach of having the server do 
the filtering or having the client doing the filtering based on a 
variety of factors including size of data sets and extent to which the 
client is under your control. If the data size is reasonable and the 
client is NOT under your control then the list-version is strongly 
superior to the query version. In other parts of the quadrant you might 
want to pair the list version WITH the query version (and let the client 
choose the most appropriate for them)


> ... The 'filter to certain dates' is an operation
> upon that local data - and that filter would need the same input data as a
> client-composed URI (namely 'asof' and the date
> syntax/value-space/meaning/whatever).

But

  a) the filter allows subtyping and remapping so that can be extended 
in a purely declarative way to handle sites that rename their "asof" to 
"asofdate". If those sites publish the renaming as RDF, I won't have to 
touch my client application to have it work with this new data 
representation.

  b) the filter knows the complete scope of the information available to 
it. That's "extra information" that you don't get when all you can do is 
guess and query.

>>But anyhow, the part I could do in N3 is: "Start with this URI which is
>>a list of 'date-versioned resources'. By definition each one has a date.
>>Get the ones that are less than 5 days old (some hand waving around date
>>functions here...).
> 
> I think I'm beginning to glimpse what you are getting at. The same
> information ('asof' and dates) is used to crawl local content (retrieved
> from a generic uri), rather than to directly address a remote resource... is
> that correct?

I don't think of it as local versus remote. I think of it as having an 
agent filter the information based on declarative expressions (probably 
locally, for implementation reasons) versus having a black box with a 
predefined query and no way to get information that is not available 
through that query (like "how often did this information change"). The 
content is not local in the sense that I don't do a big recursive "wget" 
before I start applying the filter. Rather I point the filter at a URI 
and it gets what it needs and hopefully never bothers to download things 
that are obviously NOT what it needs. (which suggests that you want to 
carefully consider the design of the index document)

>...
> The same re-application probably would not work with composed URIs out of
> the box. But if you've got content-manipulation approaches (arch forms, name
> mapping, etc.) executed on the client, then I supposed that same slot could
> be filled with mappings of the declarative rules for generating URIs also.

Maybe. Nevertheless, if the resource you provide are enumerable then a 
legitimate question for a client application to ask is "how do I 
enumerate them." You can't predict whether this will be important to 
some client or not. So I advise that if the resources are enumerable and 
if you have the development where-with-all, you should expose an 
interface that allows enumeration perhaps alongside one that allows 
queries as an optimization.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2589
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-17 14:40:55
Subject:Re: [rest-discuss] Existance of URIs (was Re: REST without PUT and other things...)
Message:

From: "Julian Reschke" <julian.reschke@...>
>
> I really have problems following your argumentation.
>
> RFC2616 clearly says that
>
> 1) PUT can be applied to existing resources or used to create new
resources,
>
> 2) POST can only be applied to existing resources (yes, creation of a new
> resource can be a side effect, but the request resource for OST must exist
> in the first place), and that
>
> 3) 404 means "The server has not found anything matching the
Request-URI.".
>
> Do you really want to change all this?

I am not changing anything (though I wouldn't mind change for the better).
I am saying not to use PUT to create mappings between URIs and resources.  I
think it's perfectly valid to use POST to create a resource.  I think it's
perfectly valid to treat 404 as "this is not a valid URI."  I think it's
perfectly valid to use PUT to update a resource using a valid URI (one that
already has a mapping to the resource being updated).  I just don't think
that PUT is consistent with the way the rest of the verbs work when one is
attempting to create a mapping with it.  That's all.

Oh, and taking the view I expressed in the prior post also allows URIs to be
thought of more simply (at least for me).

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2590
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-09-17 14:48:50
Subject:RE: [rest-discuss] Existance of URIs (was Re: REST without PUT and other things...)
Message:

> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Tuesday, September 17, 2002 4:41 PM
> To: rest-discuss
> Subject: Re: [rest-discuss] Existance of URIs (was Re: REST without PUT
> and other things...)
> ...
> already has a mapping to the resource being updated).  I just don't think
> that PUT is consistent with the way the rest of the verbs work when one is
> attempting to create a mapping with it.  That's all.
> ..

I have trouble seeing how WebDAV is supposed to work if I can't use PUT to
create a new resource. I think WebDAV (metadata aside) is a very good
example for a REST-ful HTTP extension, it's deployed and it works.

How would you do authoring of new resources just with POST?

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760







-----------------------------------------------------------------------------------
Post ID:2591
Sender:=?iso-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-09-17 15:00:03
Subject:RE: [rest-discuss] [fielding@apache.org: Re: Resources always exi st]
Message:

> From: Mark Baker [mailto:distobj@...]
> 
> It seems there's quite a disconnect between the WebDAV "resource= 
> representation" view of things, which PUT - and now DELETE - appear to

> be intended to support, versus the uniform interface approach of REST.

Mark,

Sure there is, but you can't lay blame at WebDAV's door; HTTP 1.1 has
this view simply because it has this method. In a world where resources
are synonymous with documents (or files or records or any entity in
computer accessible storage), DELETE makes sense. In a world where
resources can reside outside computers and their storage, DELETE doesn't
make much sense, at least not until Stephen King writes a story called
Web Browser of the Gods.

So, as strawman text, appended onto 9.7:

   The DELETE method requests that the origin server delete the resource
   identified by the Request-URI. This method MAY be overridden by human
   intervention (or other means) on the origin server. The client cannot
   be guaranteed that the operation has been carried out, even if the
   status code returned from the origin server indicates that the action
   has been completed successfully. However, the server SHOULD NOT
   indicate success unless, at the time the response is given, it
   intends to delete the resource or move it to an inaccessible
   location. **In cases where the resource in question can not sensibly
be 
   deleted (for example the resource is in fact a physical object) the 
   origin server should return 501, not implemented (see section
10.5.4).**

where 501 is the server error used to indicate it is incapable of
performing the request. Creating a new error code for this case is about
as useful as dividing the resources in two.

Bill de hra 
--
Propylon
www.propylon.com 







-----------------------------------------------------------------------------------
Post ID:2592
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-17 15:18:49
Subject:Blaming WebDAV
Message:

On Tue, Sep 17, 2002 at 04:00:03PM +0100, Bill de h�ra wrote:
> > It seems there's quite a disconnect between the WebDAV "resource= 
> > representation" view of things, which PUT - and now DELETE - appear to
> 
> > be intended to support, versus the uniform interface approach of REST.
> 
> Mark,
> 
> Sure there is, but you can't lay blame at WebDAV's door;

I'm not laying blame.  WebDAV had a problem to solve, and it solved it
pretty darn well ... modulo "dav:", and PROPFIND.

I'm just saying that we could use some HTTP and WebDAV like features
that didn't have the builtin resource=representation assumption in them.
That doesn't mean that having tools that do make that assumption is
bad, though when we have the new tools it might be nice to recast the
old stuff in those terms.  For example, when we figure out the details
of the "SET" method, we can define an extension such that it can be used
for doing operations semantically equivalent to PUT.

> HTTP 1.1 has
> this view simply because it has this method. In a world where resources
> are synonymous with documents (or files or records or any entity in
> computer accessible storage), DELETE makes sense. In a world where
> resources can reside outside computers and their storage, DELETE doesn't
> make much sense, at least not until Stephen King writes a story called
> Web Browser of the Gods.

You can ask to DELETE a person if you want.  The issue is, are you
allowed?  I suggest that 403 is the best response to such a request,
rather than 501.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2593
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-17 15:31:05
Subject:Re: [rest-discuss] Existance of URIs
Message:

From: "Julian Reschke" <julian.reschke@...>
>
> I have trouble seeing how WebDAV is supposed to work if I can't use PUT to
> create a new resource. I think WebDAV (metadata aside) is a very good
> example for a REST-ful HTTP extension, it's deployed and it works.

I do not know enough about WebDAV to argue one way or another on its usage
of PUT in this manner.  Because existing applications do use PUT in this
manner does not change my mind about it.

> How would you do authoring of new resources just with POST?

POST to the resource's container.  There is *always* a container.  Of
course, the feature that is lost (at the HTTP) level by using POST instead
of PUT is the ability to specify what you want the new URI to be once the
resource is created.  As I have suggested, using the "Location" header would
allow the same functionality.  However, since Location (as a response
header) points to valid URIs, it may be more appropriate to use a different
(probably new) header to provide the same functionality.

Of course, I would prefer to have a CREATE verb that was responsible for
resource creation instead of overloading POST (though this isn't strictly
adding any more functionality to POST than already exists).  But that isn't
going to happen any time soon.  :)


---
Seairth Jacobs
seairth@...








-----------------------------------------------------------------------------------
Post ID:2594
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-09-17 15:35:36
Subject:RE: [rest-discuss] Existance of URIs
Message:

> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Tuesday, September 17, 2002 5:31 PM
> To: rest-discuss
> Subject: Re: [rest-discuss] Existance of URIs
> ..
> Of course, I would prefer to have a CREATE verb that was responsible for
> resource creation instead of overloading POST (though this isn't strictly
> adding any more functionality to POST than already exists).  But 
> that isn't
> going to happen any time soon.  :)

I really have trouble following you.

How would CREATE be different from what PUT does now?

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 







-----------------------------------------------------------------------------------
Post ID:2595
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-17 15:43:25
Subject:Re: [rest-discuss] Blaming WebDAV
Message:

From: "Mark Baker" <distobj@...>
>
> On Tue, Sep 17, 2002 at 04:00:03PM +0100, Bill de h�ra wrote:
>
> > HTTP 1.1 has
> > this view simply because it has this method. In a world where resources
> > are synonymous with documents (or files or records or any entity in
> > computer accessible storage), DELETE makes sense. In a world where
> > resources can reside outside computers and their storage, DELETE doesn't
> > make much sense, at least not until Stephen King writes a story called
> > Web Browser of the Gods.
>
> You can ask to DELETE a person if you want.  The issue is, are you
> allowed?  I suggest that 403 is the best response to such a request,
> rather than 501.

On the other hand, if you were to treat DELETE as a method to invalidate the
mapping of a URI to its resource, then this would not be as much an issue.
For instance, I have two names I answer to:  Seairth and Jake (old college
nickname).  If I were to DELETE "Jake", I am not deleting myself.  All I am
doing is invalidating the mapping between "Jake" and myself.  If there were
people in the world who only knew me as Jake and only knew how to find by by
that name,  I would effectively be deleted to those people.  In reality, I
live on as Seairth only.  Were it possible to DELETE *all* names I have
(Proper name, SSN, Resident @ address, etc.), then I would effectively cease
to exist to everyone (since no one was capable of finding me anymore).

I think that DELETE can work in all circumstances as only as we change our
focus on what we are really deleting.  This view should not change the way
things work, but it should allow us to understand and accept DELETE in a
more universal manner...  I think... :)

---
Seairth Jacobs
seairth@...








-----------------------------------------------------------------------------------
Post ID:2596
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-17 16:32:10
Subject:Re: [rest-discuss] Client-composed URI
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> Paul says:
>
>  > Sometimes the information provider has such a large database of
>  > information that it is not practically (or economically) feasible for
it
>  > to deliver to the requestor in total or even to segment into many
>  > hypermedia documents. The requestor needs to specify some reasonable
>  > filter. This is a fallback position because it becomes difficult or
>  > impossible for the requestor to enumerate all of the information items
>  > even if this might be useful or important. Nevertheless, reality
>  > requires that sometimes filtering happen on the server side and the
>  > Web allows this through HTTP URI "query parameters".
>
> http://groups.yahoo.com/group/rest-discuss/message/2540

Okay, great. So I shouldn't construct a URI using query parameters, unless
the data is large and then the workaround is to construct a URI using query
parameters. Got it.








-----------------------------------------------------------------------------------
Post ID:2597
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-09-17 16:42:26
Subject:Re: [rest-discuss] Existance of URIs
Message:

>>How would you do authoring of new resources just with POST?
> 
> 
> POST to the resource's container.  There is *always* a container.  Of
> course, the feature that is lost (at the HTTP) level by using POST instead

That's the approach we've taken.  It was too hard to design security 
policies around objects (resources) that didn't exist yet.  So instead 
of using PUT, we chose POST into an existing collection resource.  Works 
great for us.

Seth







-----------------------------------------------------------------------------------
Post ID:2598
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-17 16:50:22
Subject:Re: [rest-discuss] Client-composed URI
Message:

>
> > ... The 'filter to certain dates' is an operation
> > upon that local data - and that filter would need the same input data as
a
> > client-composed URI (namely 'asof' and the date
> > syntax/value-space/meaning/whatever).
>
> But
>
>   a) the filter allows subtyping and remapping so that can be extended
> in a purely declarative way to handle sites that rename their "asof" to
> "asofdate". If those sites publish the renaming as RDF, I won't have to
> touch my client application to have it work with this new data
> representation.
If the filtering algorithm has access to subtyping and remapping, then a
declarative format for creating the URI with query parameters can also have
access to the same sort of functionality. The site publishes the renaming
and the client doesn't have to be adjusted.

>
>   b) the filter knows the complete scope of the information available to
> it. That's "extra information" that you don't get when all you can do is
> guess and query.
If the data set is reasonably large, it will probably be chunked & so it
doesn't know the complete scope of information. That scope is implied and
not explicit. Unless the representation of that resource says 'this is a
portion of available information and there are more bits here and here'.


> >...
> > The same re-application probably would not work with composed URIs out
of
> > the box. But if you've got content-manipulation approaches (arch forms,
name
> > mapping, etc.) executed on the client, then I supposed that same slot
could
> > be filled with mappings of the declarative rules for generating URIs
also.
>
> Maybe. Nevertheless, if the resource you provide are enumerable then a
> legitimate question for a client application to ask is "how do I
> enumerate them." You can't predict whether this will be important to
> some client or not. So I advise that if the resources are enumerable and
> if you have the development where-with-all, you should expose an
> interface that allows enumeration perhaps alongside one that allows
> queries as an optimization.
Now we're talking... I'm all for discovery via enumeration, but I want to
explore what reasonable approaches are when enumeration is not practical.







-----------------------------------------------------------------------------------
Post ID:2599
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-17 16:51:10
Subject:Re: [rest-discuss] Client-composed URI
Message:

> No. *One kind* of client needs to know the same amount of information in
> both approaches. *Other kinds of clients* will be enabled by an approach
> that gives more information (like "here's the list of entities
> available") rather than less information (like "guess an entity and I'll
> tell you if it is available"). The first approach enables things like
> Google to exist and the latter prevents them.

But if the first approach /prevents/ the main application from working, it
isn't a solution at all.






-----------------------------------------------------------------------------------
Post ID:2600
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-17 17:31:59
Subject:Basic Verbs (was Re: Existance of URIs)
Message:

(note:  this may work into the "Formalizing a model" thread)

From: "Julian Reschke" <julian.reschke@...>
>
> I really have trouble following you.
>
> How would CREATE be different from what PUT does now?

I come from a database programming background.  Strictly speaking, I started
off with "local" relational database technologies.  But over the years I
have broadened my conceptual view of databases to be any group of resources
that are retrievable by an identifier.  This could be a key value in a RDBMS
table or an HTTP URL on the web.  It's all the same to me...

To me there are four basic operations (verbs) that can occur against a
database:

ADD    (e.g. SQL INSERT)
EDIT    (e.g. SQL UPDATE)
DELETE (e.g. SQL DELETE)
GET    (e.g. SQL SELECT)

Until working with REST, I had still conceptualized the above verbs as doing
physical things to the resources themselves.  The identifiers were
second-hand citizens to the data, being nothing more than a convenient way
to access a resource.  However, as I begin to understand REST more and more,
I have started seeing these verbs in a different light.

Instead of verbs that act on a resource, I see them as verbs that act on
whatever the identifier is mapped to (which we tend to conceptualize as a
resource).  When I say ADD, what I would have been saying in the past (from
my rdbms pov):

    Take this data and make a record/resource which is identifiable by it's
key.

Now I would say:

    Take the key and map the data to it.

Likewise, EDIT would be the same:

    Take the key and update the data that is mapped to it.

DELETE would be:

    Take the key and remove the mapping to the data.

GET would be:

    Take the key and return the data that is mapped to it.


In RDBMS, these are still perfectly valid statements, if not a bit "oddly
worded".  When I turn around and look at URIs and Resources (as discussed on
this list), it still makes perfect sense to use the above verbs.  The URI is
the key and the Resource is the data.


If you want to map them to HTTP verbs, you might end up with something like
the following:

ADD -> POST
EDIT -> PUT
DELETE -> DELETE
GET -> GET

Of course, these are not perfect matches.  As we know, POST can do more than
just create a new URI<->Resource mapping.  We also know that PUT do more
than just an EDIT.  At the same time, EDIT in RDBMS systems allows a partial
edit, which PUT does not (put any arguments to this statement in a different
thread, please). DELETE and GET are about the only things that actually work
more or less the same.

So does this mean that the ADD, EDIT, DELETE, GET model is wrong?  I don't
think so.  I think that the HTTP POST, PUT, DELETE, GET model is ambiguous
and could be improved to adopt the other model.  This is where CREATE came
in.  In this case, CREATE is identical to ADD.  So, suppose we had this
model instead:

ADD -> CREATE
EDIT -> PUT
DELETE -> DELETE
GET -> GET

Now, we are a bit closer.  But this leaves out POST.  Sort of.  POST can be
used for all sorts of things.  However, if we were to relax PUTs
course-grained update requirements, POST would not have to be used for that.
Since CREATE is dedicated to the creation of the URI<->Resource mappings,
POST would not have to be used for that either.  In the end, POST becomes
nothing more than a generic RPC mechanism.  Interestingly, some SQL servers
actually have the same thing:  EXEC.  When you need to submit data to a
server and there is no visible side effect (i.e. none of the four other
verbs are happening), that's when you use POST.

So, let's add one more verb to the mix:

ADD -> CREATE
EDIT -> PUT
DELETE -> DELETE
GET -> GET
EXEC -> POST

In the end, I see this as a cleaner, less ambiguous set of verbs than the
current HTTP verbs.  I am sure you will disagree with me.  :)  But that's
fine.  There are certainly questions that need answering such as how these
new (variations) verbs deal with "safety", "idempotency", caching, etc.  But
I would be willing to tackle those issues if I knew that there were others
that saw this as I did (or at least were open to the possibility).  :)

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2601
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-17 18:07:25
Subject:Re: [rest-discuss] Client-composed URI
Message:

S. Mike Dierken wrote:
>>No. *One kind* of client needs to know the same amount of information in
>>both approaches. *Other kinds of clients* will be enabled by an approach
>>that gives more information (like "here's the list of entities
>>available") rather than less information (like "guess an entity and I'll
>>tell you if it is available"). The first approach enables things like
>>Google to exist and the latter prevents them.
> 
> 
> But if the first approach /prevents/ the main application from working, it
> isn't a solution at all.

Obviously. As I understood the problem originally (daily snapshots of 
information resources) a listing would work. As I understand it now, 
infinitely divisible time-based snapshots, the listing would not work.

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2602
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-17 18:16:14
Subject:Re: [rest-discuss] Client-composed URI
Message:

S. Mike Dierken wrote:
>...
> 
> If the filtering algorithm has access to subtyping and remapping, then a
> declarative format for creating the URI with query parameters can also have
> access to the same sort of functionality. The site publishes the renaming
> and the client doesn't have to be adjusted.

There isn't a filtering algorithm. There is a declarative "filter" like 
a SQL select statement but expressed in terms of semantic web 
technologies, resolved through web dereferences and typically executed 
on the client side.

Maybe the semantic web technologies could be extended to support query 
parameter renaming and subtyping: I don't personally know whether the 
concept fits naturally into the formalisms underlying the semantic web 
or not. I only know what exists now. I know how to do property renaming 
and subtyping. I don't know how to do parameter renaming or even 
parameter construction -- except as standard string manipulation.

>...
> If the data set is reasonably large, it will probably be chunked & so it
> doesn't know the complete scope of information. That scope is implied and
> not explicit. Unless the representation of that resource says 'this is a
> portion of available information and there are more bits here and here'.

Sounds like a good use for hypertext!

> Now we're talking... I'm all for discovery via enumeration, but I want to
> explore what reasonable approaches are when enumeration is not practical.

Query parameters! Nobody ever said that enumeration is always practical. 
That's why query parameters exist.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2603
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-17 18:29:13
Subject:Re: [rest-discuss] Client-composed URI
Message:

S. Mike Dierken wrote:
> ----- Original Message -----
>...
> 
> 
> Okay, great. So I shouldn't construct a URI using query parameters, unless
> the data is large and then the workaround is to construct a URI using query
> parameters. Got it.

That's basically my position although someday it might be worth drilling 
down more into what it means for the data to be large. Arbitrarily large 
data sets can be broken down into bite-sized fractions but then you get 
into latency issues (like trying to navigate YahooGroups, 10 messages 
per page). Plus you can get into situations where the server can answer 
a question in O(X) time but the client can only answer in O(Y) where Y 
is greater than X. For instance asking Google to find the intersection 
"Mike" and "Dierken" is going to be much faster than doing it on the 
client even if bandwidth and latency were free because Google's indexes 
are set up that way.

Still, given infinte development resources, I think that people out 
there could make good use of a Google service that listed all words that 
co-occur with some particular word. Linguists would love it!

Also, as a purely theoretical, rather than practical point, I will 
mention that it is possible to design a hypertext interface even to a 
nano-second indexed data set. At the top level you could list all 
milleniums that data is available for. At the level below you could list 
all centuries. At the level below you could list all decades. And on 
down to nanoseconds. Ideally you would filter out "uninteresting" time 
periods where nothing happened. The latency on such a data 
representation would probably be killer, however.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2604
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-09-17 18:21:09
Subject:RE: [rest-discuss] Basic Verbs (was Re: Existance of URIs)
Message:

Searth,

as far as I understand, you don't like the fact that PUThttp maps both to
INSERTsql and UPDATEsql. That's a fact of how HTTP is designed.

Could you please explain why this is an *actual* problem (besides the fact
that we don't have a one-to-one mapping from HTTP verbs to database
operations)?

Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> -----Original Message-----
> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Tuesday, September 17, 2002 7:32 PM
> To: rest-discuss
> Subject: [rest-discuss] Basic Verbs (was Re: Existance of URIs)
>
>
> (note:  this may work into the "Formalizing a model" thread)
>
> From: "Julian Reschke" <julian.reschke@...>
> >
> > I really have trouble following you.
> >
> > How would CREATE be different from what PUT does now?
>
> I come from a database programming background.  Strictly
> speaking, I started
> off with "local" relational database technologies.  But over the years I
> have broadened my conceptual view of databases to be any group of
> resources
> that are retrievable by an identifier.  This could be a key value
> in a RDBMS
> table or an HTTP URL on the web.  It's all the same to me...
>
> To me there are four basic operations (verbs) that can occur against a
> database:
>
> ADD    (e.g. SQL INSERT)
> EDIT    (e.g. SQL UPDATE)
> DELETE (e.g. SQL DELETE)
> GET    (e.g. SQL SELECT)
>
> Until working with REST, I had still conceptualized the above
> verbs as doing
> physical things to the resources themselves.  The identifiers were
> second-hand citizens to the data, being nothing more than a convenient way
> to access a resource.  However, as I begin to understand REST
> more and more,
> I have started seeing these verbs in a different light.
>
> Instead of verbs that act on a resource, I see them as verbs that act on
> whatever the identifier is mapped to (which we tend to conceptualize as a
> resource).  When I say ADD, what I would have been saying in the
> past (from
> my rdbms pov):
>
>     Take this data and make a record/resource which is
> identifiable by it's
> key.
>
> Now I would say:
>
>     Take the key and map the data to it.
>
> Likewise, EDIT would be the same:
>
>     Take the key and update the data that is mapped to it.
>
> DELETE would be:
>
>     Take the key and remove the mapping to the data.
>
> GET would be:
>
>     Take the key and return the data that is mapped to it.
>
>
> In RDBMS, these are still perfectly valid statements, if not a bit "oddly
> worded".  When I turn around and look at URIs and Resources (as
> discussed on
> this list), it still makes perfect sense to use the above verbs.
> The URI is
> the key and the Resource is the data.
>
>
> If you want to map them to HTTP verbs, you might end up with
> something like
> the following:
>
> ADD -> POST
> EDIT -> PUT
> DELETE -> DELETE
> GET -> GET
>
> Of course, these are not perfect matches.  As we know, POST can
> do more than
> just create a new URI<->Resource mapping.  We also know that PUT do more
> than just an EDIT.  At the same time, EDIT in RDBMS systems
> allows a partial
> edit, which PUT does not (put any arguments to this statement in
> a different
> thread, please). DELETE and GET are about the only things that
> actually work
> more or less the same.
>
> So does this mean that the ADD, EDIT, DELETE, GET model is wrong?  I don't
> think so.  I think that the HTTP POST, PUT, DELETE, GET model is ambiguous
> and could be improved to adopt the other model.  This is where CREATE came
> in.  In this case, CREATE is identical to ADD.  So, suppose we had this
> model instead:
>
> ADD -> CREATE
> EDIT -> PUT
> DELETE -> DELETE
> GET -> GET
>
> Now, we are a bit closer.  But this leaves out POST.  Sort of.
> POST can be
> used for all sorts of things.  However, if we were to relax PUTs
> course-grained update requirements, POST would not have to be
> used for that.
> Since CREATE is dedicated to the creation of the URI<->Resource mappings,
> POST would not have to be used for that either.  In the end, POST becomes
> nothing more than a generic RPC mechanism.  Interestingly, some
> SQL servers
> actually have the same thing:  EXEC.  When you need to submit data to a
> server and there is no visible side effect (i.e. none of the four other
> verbs are happening), that's when you use POST.
>
> So, let's add one more verb to the mix:
>
> ADD -> CREATE
> EDIT -> PUT
> DELETE -> DELETE
> GET -> GET
> EXEC -> POST
>
> In the end, I see this as a cleaner, less ambiguous set of verbs than the
> current HTTP verbs.  I am sure you will disagree with me.  :)  But that's
> fine.  There are certainly questions that need answering such as how these
> new (variations) verbs deal with "safety", "idempotency",
> caching, etc.  But
> I would be willing to tackle those issues if I knew that there were others
> that saw this as I did (or at least were open to the possibility).  :)
>
> ---
> Seairth Jacobs
> seairth@...
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:2605
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-17 18:40:36
Subject:RE: [rest-discuss] Basic Verbs (was Re: Existance of URIs)
Message:

I've seen just about an equal number of cases while programming
applications in which

	a) the application cares about the existence of an
		object, but doesn't care whether it existed
		before or has to be created.  For languages with
		explicit creation, you end up coding like
	
		object = find()
		if (!object)
			object = new object()
		...
		object.dothings();

	b) the application only cares about having a new
		instance of something, even if an old copy exists
		with similar or identical values.  For languages
		with implicit creation (HTTP), you end up coding
		like

		POST /Container HTTP/1.1 <object>...</object>
		if response.code != CREATED
			throw up hands in despair


Each has its moments, though.

Walden ;-)

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@...]
> Sent: Tuesday, September 17, 2002 2:21 PM
> To: Seairth Jacobs; rest-discuss
> Subject: RE: [rest-discuss] Basic Verbs (was Re: Existance of URIs)
> 
> 
> Searth,
> 
> as far as I understand, you don't like the fact that PUThttp 
> maps both to
> INSERTsql and UPDATEsql. That's a fact of how HTTP is designed.
> 
> Could you please explain why this is an *actual* problem 
> (besides the fact
> that we don't have a one-to-one mapping from HTTP verbs to database
> operations)?
> 
> Julian
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
> > -----Original Message-----
> > From: Seairth Jacobs [mailto:seairth@...]
> > Sent: Tuesday, September 17, 2002 7:32 PM
> > To: rest-discuss
> > Subject: [rest-discuss] Basic Verbs (was Re: Existance of URIs)
> >
> >
> > (note:  this may work into the "Formalizing a model" thread)
> >
> > From: "Julian Reschke" <julian.reschke@...>
> > >
> > > I really have trouble following you.
> > >
> > > How would CREATE be different from what PUT does now?
> >
> > I come from a database programming background.  Strictly
> > speaking, I started
> > off with "local" relational database technologies.  But 
> over the years I
> > have broadened my conceptual view of databases to be any group of
> > resources
> > that are retrievable by an identifier.  This could be a key value
> > in a RDBMS
> > table or an HTTP URL on the web.  It's all the same to me...
> >
> > To me there are four basic operations (verbs) that can 
> occur against a
> > database:
> >
> > ADD    (e.g. SQL INSERT)
> > EDIT    (e.g. SQL UPDATE)
> > DELETE (e.g. SQL DELETE)
> > GET    (e.g. SQL SELECT)
> >
> > Until working with REST, I had still conceptualized the above
> > verbs as doing
> > physical things to the resources themselves.  The identifiers were
> > second-hand citizens to the data, being nothing more than a 
> convenient way
> > to access a resource.  However, as I begin to understand REST
> > more and more,
> > I have started seeing these verbs in a different light.
> >
> > Instead of verbs that act on a resource, I see them as 
> verbs that act on
> > whatever the identifier is mapped to (which we tend to 
> conceptualize as a
> > resource).  When I say ADD, what I would have been saying in the
> > past (from
> > my rdbms pov):
> >
> >     Take this data and make a record/resource which is
> > identifiable by it's
> > key.
> >
> > Now I would say:
> >
> >     Take the key and map the data to it.
> >
> > Likewise, EDIT would be the same:
> >
> >     Take the key and update the data that is mapped to it.
> >
> > DELETE would be:
> >
> >     Take the key and remove the mapping to the data.
> >
> > GET would be:
> >
> >     Take the key and return the data that is mapped to it.
> >
> >
> > In RDBMS, these are still perfectly valid statements, if 
> not a bit "oddly
> > worded".  When I turn around and look at URIs and Resources (as
> > discussed on
> > this list), it still makes perfect sense to use the above verbs.
> > The URI is
> > the key and the Resource is the data.
> >
> >
> > If you want to map them to HTTP verbs, you might end up with
> > something like
> > the following:
> >
> > ADD -> POST
> > EDIT -> PUT
> > DELETE -> DELETE
> > GET -> GET
> >
> > Of course, these are not perfect matches.  As we know, POST can
> > do more than
> > just create a new URI<->Resource mapping.  We also know 
> that PUT do more
> > than just an EDIT.  At the same time, EDIT in RDBMS systems
> > allows a partial
> > edit, which PUT does not (put any arguments to this statement in
> > a different
> > thread, please). DELETE and GET are about the only things that
> > actually work
> > more or less the same.
> >
> > So does this mean that the ADD, EDIT, DELETE, GET model is 
> wrong?  I don't
> > think so.  I think that the HTTP POST, PUT, DELETE, GET 
> model is ambiguous
> > and could be improved to adopt the other model.  This is 
> where CREATE came
> > in.  In this case, CREATE is identical to ADD.  So, suppose 
> we had this
> > model instead:
> >
> > ADD -> CREATE
> > EDIT -> PUT
> > DELETE -> DELETE
> > GET -> GET
> >
> > Now, we are a bit closer.  But this leaves out POST.  Sort of.
> > POST can be
> > used for all sorts of things.  However, if we were to relax PUTs
> > course-grained update requirements, POST would not have to be
> > used for that.
> > Since CREATE is dedicated to the creation of the 
> URI<->Resource mappings,
> > POST would not have to be used for that either.  In the 
> end, POST becomes
> > nothing more than a generic RPC mechanism.  Interestingly, some
> > SQL servers
> > actually have the same thing:  EXEC.  When you need to 
> submit data to a
> > server and there is no visible side effect (i.e. none of 
> the four other
> > verbs are happening), that's when you use POST.
> >
> > So, let's add one more verb to the mix:
> >
> > ADD -> CREATE
> > EDIT -> PUT
> > DELETE -> DELETE
> > GET -> GET
> > EXEC -> POST
> >
> > In the end, I see this as a cleaner, less ambiguous set of 
> verbs than the
> > current HTTP verbs.  I am sure you will disagree with me.  
> :)  But that's
> > fine.  There are certainly questions that need answering 
> such as how these
> > new (variations) verbs deal with "safety", "idempotency",
> > caching, etc.  But
> > I would be willing to tackle those issues if I knew that 
> there were others
> > that saw this as I did (or at least were open to the 
> possibility).  :)
> >
> > ---
> > Seairth Jacobs
> > seairth@...
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/
>
>



To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2606
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-17 21:17:57
Subject:Re: [rest-discuss] Client-composed URI
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> I don't know how to do parameter renaming or even
> parameter construction -- except as standard string manipulation.
Define the HTTP URI as a grove, create links to portions of this graph (the
named query terms), apply a transform that injects input data into the
grove, then serialize this into slash and question mark format rather than
angle bracket format. A URI is a very compact serialization of a fairly
complex data structure.






-----------------------------------------------------------------------------------
Post ID:2607
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-18 20:30:35
Subject:Re: Resources always exist
Message:

S. Mike Dierken wrote:
> ----- Original Message -----
> From: "Paul Prescod" <paul@...>
> 
>>If you DELETE something twice, you usually expect an error message or a
>>core dump.
> 
> Do you mean 'delete' in the classic programming language sense (releasing
> system memory, calling destructors, etc.) or do you mean the HTTP concept of
> DELETE?

The fact that there is potentially a divergence there is exactly my 
point. It's okay for HTTP to diverge but if the spec doesn't say clearly 
one way or another, then people will just guess. HTTP says basically 
"DELETE means you should delete."

Roy describes a very mathematical mode for HTTP (resource is a mapping 
etc.) and if the HTTP methods were described in those terms it would be 
much easier to build interoperable software.

There are hints that it was politics that prevented this from happening 
the first time around, but what should we do about it now? Just transmit 
the true meanings of the methods through mailing lists? Increment HTTP? 
Write an RFC clarifying? Wait for Roy's new protocol? I'm being serious 
here: I think that there is a problem and a variety of solutions and am 
soliciting opinions on both issues.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2608
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-18 20:53:13
Subject:RE: [rest-discuss] Re: Resources always exist
Message:

Paul,

If it hasn't already been done, I think it would be useful
to at least formalize the possible interpretations of things
like DELETE and anything else people find ambiguity in,
separate from attempting to make any judgments about which
interpretations are good and which are not.

I keep threatening to build some Alloy models of parts of
HTTP, and I'm getting very close to actually doing that.  One
thing is that I don't want to do it in isolation, so if you're
interested in this approach, I say we just start with some
informal language.  Unfortunately, the message below is too
ambiguous about the ambiguity in DELETE for me to get my
teeth in.

What do others think about this approach?  I think Mark Baker
proposed something like this, offering to author some new
methods once we had a clear model.  Let's do it, unless it's
already been done and we'd be duplicating effort.

I can pledge a genuine interest and *some* time, but can't
commit to any schedule, unfortunately.

Walden

PS - shall I publish a simple Alloy model to this list
	tommorow to drive a stake into the ground?

> -----Original Message-----
> From: Paul Prescod [mailto:paul@...]
> Sent: Wednesday, September 18, 2002 4:31 PM
> To: S. Mike Dierken
> Cc: Roy T. Fielding; rest-discuss
> Subject: [rest-discuss] Re: Resources always exist
> 
> 
> S. Mike Dierken wrote:
> > ----- Original Message -----
> > From: "Paul Prescod" <paul@...>
> > 
> >>If you DELETE something twice, you usually expect an error 
> message or a
> >>core dump.
> > 
> > Do you mean 'delete' in the classic programming language 
> sense (releasing
> > system memory, calling destructors, etc.) or do you mean 
> the HTTP concept of
> > DELETE?
> 
> The fact that there is potentially a divergence there is exactly my 
> point. It's okay for HTTP to diverge but if the spec doesn't 
> say clearly 
> one way or another, then people will just guess. HTTP says basically 
> "DELETE means you should delete."
> 
> Roy describes a very mathematical mode for HTTP (resource is 
> a mapping 
> etc.) and if the HTTP methods were described in those terms 
> it would be 
> much easier to build interoperable software.
> 
> There are hints that it was politics that prevented this from 
> happening 
> the first time around, but what should we do about it now? 
> Just transmit 
> the true meanings of the methods through mailing lists? 
> Increment HTTP? 
> Write an RFC clarifying? Wait for Roy's new protocol? I'm 
> being serious 
> here: I think that there is a problem and a variety of 
> solutions and am 
> soliciting opinions on both issues.
> 
>   Paul Prescod
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2609
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-18 21:35:20
Subject:Re: [rest-discuss] Re: Resources always exist
Message:

Mathews, Walden wrote,
> What do others think about this approach?  I think Mark Baker
> proposed something like this, offering to author some new
> methods once we had a clear model.  Let's do it, unless it's
> already been done and we'd be duplicating effort.

If it has, the results haven't been published anywhere to the best of my 
knowledge.

> I can pledge a genuine interest and *some* time, but can't
> commit to any schedule, unfortunately.
>
> Walden
>
> PS - shall I publish a simple Alloy model to this list
> 	tommorow to drive a stake into the ground?

Please do ... I, for one, would be very interested in taking a look at 
it.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2610
Sender:"inthedarkplace" <inthedarkplace@...>
Post Date/Time:2002-09-18 21:39:35
Subject:Re: Resources always exist
Message:

The simple fact is that there is no divergence. DELETE is idempotent 
and therefore deleting something once or deleting something a 
thousand times is the same operation. I'm not sure where people got 
the idea that there's something wrong with deleting something twice 
because that's never ever been true of HTTP and in fact most systems 
that expose a delete operation (eg databases, file systems, tuple 
spaces, g-indexes, maps). Further, there is no logical discontinuity 
between this behavior and the meaning of a delete request. I'm not 
sure why some people want to make this more complicated than it is, 
but I think it's clear to the majority.


- itdp
--- In rest-discuss@y..., Paul Prescod <paul@p...> wrote:
> S. Mike Dierken wrote:
> > ----- Original Message -----
> > From: "Paul Prescod" <paul@p...>
> > 
> >>If you DELETE something twice, you usually expect an error 
message or a
> >>core dump.
> > 
> > Do you mean 'delete' in the classic programming language sense 
(releasing
> > system memory, calling destructors, etc.) or do you mean the 
HTTP concept of
> > DELETE?
> 
> The fact that there is potentially a divergence there is exactly 
my 
> point. It's okay for HTTP to diverge but if the spec doesn't say 
clearly 
> one way or another, then people will just guess. HTTP says 
basically 
> "DELETE means you should delete."
> 
> Roy describes a very mathematical mode for HTTP (resource is a 
mapping 
> etc.) and if the HTTP methods were described in those terms it 
would be 
> much easier to build interoperable software.
> 
> There are hints that it was politics that prevented this from 
happening 
> the first time around, but what should we do about it now? Just 
transmit 
> the true meanings of the methods through mailing lists? Increment 
HTTP? 
> Write an RFC clarifying? Wait for Roy's new protocol? I'm being 
serious 
> here: I think that there is a problem and a variety of solutions 
and am 
> soliciting opinions on both issues.
> 
>   Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2611
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-18 22:04:40
Subject:Re: [rest-discuss] Re: Resources always exist
Message:

inthedarkplace wrote,
> I'm not sure where people got the idea that there's something wrong
> with deleting something twice because that's never ever been true of
> HTTP and in fact most systems that expose a delete operation (eg
> databases, file systems, tuple spaces, g-indexes, maps).

I think a lot turns on what's meant by "something wrong with". To take 
one of your examples, files systems,

  $ touch foo
  $ rm foo
  $ rm foo
  rm: cannot remove `foo': No such file or directory
  $

There's nothing "wrong" with this behaviour.

rm is idempotent, but, nb., from the point of view of the effect on the 
filesystem, *not* from the point of view of the response displayed to 
the invoker,

* WRT the filesystem, the effect of n+1 rm's is the same as the effect
  of n.

* WRT the response displayed to the invoker, the effect of the first rm
  is different from the second and subsequent rm's.

The gist of my earlier postings is that I believe that RFC 2616 
equivocates between a view of idempotence, similar to the one above, 
defined soley in terms of effects on servers/resources, and one that 
appeals to sameness of results as seen by the client. It's this 
equivocation which I think is wrong, not idempotent DELETEs.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2612
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-19 04:34:11
Subject:True meaning of "Idempotent"?
Message:

What is the true meaning of "idempotent", both in terms of HTTP and in terms
of REST?  Roy Fielding does not mention idempotency in his dissertation, but
it certainly appears to be an integral part of our discussions on REST.

To start, RFC2616 [1:9.1.2] says:

   Methods can also have the property of "idempotence"
   in that (aside from error or expiration issues) the
   side-effects of N > 0 identical requests is the same
   as for a single request. The methods GET, HEAD, PUT
   and DELETE share this property. Also, the methods
   OPTIONS and TRACE SHOULD NOT have side effects, and
   so are inherently idempotent.

Generally, I don't think we dispute the above description in terms of what
happens to a resource on a server.  However, where we seem to disagree
(mostly due to ambiguity, I think), is just how far the concept of
idempotency reaches.  For instance, is an operation idempotent if it returns
different responses?  When we speak of responses, are we talking about only
the response entity, the metadata, or both?  Since "error or expiration
issues" are explicitly noted as exceptions, what does idempotency mean in
those circumstances?  What is the definition of "side-effect"?

I do not have an answer for this, but I do have some thoughts (and
opinions)...

First, let's define what "side-effect" means.  I prefer the term "mutation"
here, since "side-effect" implies something that occurs indirectly to the
actual action taken.  However, no one here would consider updating a
resource with a PUT as a side-effect.  So, the first thing we can say about
a side-effect (in terms of the HTTP spec) is that we are speaking of the
changing of a resource.  That's it.  Nothing more.  It could be direct or
indirect.  Doesn't matter.  The second thing we can say about a side-effect
(again, in terms of HTTP) is that we are speaking of the end result of the
changing of a resource, not the process itself.  In other words, we only see
a side-effect in terms of what state the resource is in after the change.

Next, let's start applying some scope to these terms (where possible).  To
start, let's say that side-effects are scoped to the resource on the server.
The client is never directly aware of side-effect.  Next, let's also say
that an idempotent method is scoped to the resource on the server as well.
This makes sense since idempotency depends on side-effects.

Now, we get to the part where the ambiguity creeps in...

When one uses an idempotent method which causes a side-effect (PUT, DELETE),
the server returns a response just like any other request method.  The
response contains two parts:  the headers (metadata) and the entity-body
(which can be null).  Recently, we have discussed whether returning
different responses when issuing repeated DELETEs violates idempotency or
not.  One camp says that the response should reflect the results of the
request (i.e. 200 for first response, 404 afterwards).  This attitude would
imply that the response does not have anything to do with whether the
request was idempotent or not.  The other camp says that the response should
reflect the end state of the request (i.e. 200 for all responses).  This
attitude would imply that the response is as much a part of the idempotency
requirements as the request is.  What this comes down to is whether we
consider any part of the response to be within the scope of HTTP's
definition of idempotency.

My feeling is that the response has nothing to do with idempotency at all.
This comes from the use of GET.  GET is an idempotent operation that has no
side-effect.  As a result, I could issue the same GET several times, and the
server could return different responses for each of the requests.  For
instance, in some of the responses, I could get back a 200, but have
different entity bodies (common for dynamic content).  I could also get back
different response codes, such as 200 (OK), then 301 (Moved Permanently),
then 404 (Not Found).  Despite these different responses, each of the GETs
is still considered to be idempotent.

Now, let's move on to PUT.  When PUT is used, and the resource did not
exist, then a 201 (Created) response is expected.  Subsequent PUTs to the
same resource return 200 (OK) responses.  This is very common practice and I
have never heard a single person say this is not idempotent.

So, now we move on to DELETE.  In this case, let's say that the first DELETE
will return a 200 response and subsequent DELETEs return a 404 response.
>From the definition and scoping of "side-effect" above, we all agree that
the state of the resource after each delete is that it does not exist.  This
is enough to also satisfy DELETE's requirement of idempotency.  Further,
this is no different than returning two responses for repeated PUTs.


In the end, my personal conclusion is that responses have nothing to do with
idempotency.  Idempotency is only limited to the resource on the server.
Regardless of what is returned to the client, the operation on the server is
idempotent (assuming that the end state is the same after repeated identical
requests).


So what does this mean for returning responses from DELETE?  I think that
200 (OK) or 202 (Accepted) or 204 (No Content), followed by 404 (Not Found)
or 410 (Gone) and maybe 303 (See Other) would be no different than expected
of other idempotent methods like PUT and GET.

If I had to suggest an order of usage, I'd say (in order of most expressive
to least expressive):

First request:
    204 (No Content)
    202 (Accepted)
    200 (OK)

Repeated requests:
    303 (See Other)
    410 (Gone)
    404 (Not Found)


Should we allow repeated DELETE requests to always get back a "200" (or
similar) response?  PUT (DELETE's binary opposite) doesn't allow it.  GET,
while possible to receive the same response over and over again, must also
be open to receiving other responses as well.  So, why should DELETE be any
different?  My thought here is that it would be wrong (given the way the
other two verbs work) to return the same response code regardless of whether
the resource was deleted or not.


<note>I think that's it.  Sorry if it seemed to ramble on.  I stopped
somewhere in the middle to watch The Daily Show (comedy central) and when
they showed the clip of Bush totally screwing up a simple quote, I just lost
all concentration (funny stuff, it was).  Again, sorry if it all seems
incoherent.  :) *giggle* </note>

[1] http://www.ietf.org/rfc/rfc2616.txt

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2613
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-19 08:16:45
Subject:Re: [rest-discuss] True meaning of "Idempotent"?
Message:

Seairth Jacobs wrote,
> In the end, my personal conclusion is that responses have nothing to
> do with idempotency.  Idempotency is only limited to the resource on
> the server. Regardless of what is returned to the client, the
> operation on the server is idempotent (assuming that the end state is
> the same after repeated identical requests).

This would also be my conclusion, but for one thing.

If we take this interpretation of idempotence, then RFC 2616's 
discussion of non-idempotent sequences of idempotent methods makes no 
sense at all, because on this interpretation *all* sequences of 
idempotent methods are idempotent sequences: see the proof I gave 
earlier ... which I'm confident that Walden's model, if he puts it 
together, will verify.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2614
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-19 13:38:55
Subject:RE: [rest-discuss] Re: Resources always exist
Message:

> -----Original Message-----
> From: inthedarkplace [mailto:inthedarkplace@...]
> Sent: Wednesday, September 18, 2002 5:40 PM
> To: rest-discuss@yahoogroups.com
> Subject: [rest-discuss] Re: Resources always exist
> 
> 
> The simple fact is that there is no divergence. DELETE is idempotent 
> and therefore deleting something once or deleting something a 
> thousand times is the same operation. I'm not sure where people got 
> the idea that there's something wrong with deleting something twice 
> because that's never ever been true of HTTP and in fact most systems 
> that expose a delete operation (eg databases, file systems, tuple 
> spaces, g-indexes, maps). Further, there is no logical discontinuity 
> between this behavior and the meaning of a delete request. I'm not 
> sure why some people want to make this more complicated than it is, 
> but I think it's clear to the majority.
> 
> 
> - itdp

I don't want to play any part in complicating things that are
obvious.  Still, that doesn't rule out modelling simple things
about HTTP, because the simpler models serve as the foundation
for exploring some of the more complex and controversial issues.
And also for reasoning correctly about extensions.

Walden






-----------------------------------------------------------------------------------
Post ID:2615
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-19 14:02:57
Subject:RE: [rest-discuss] True meaning of "Idempotent"?
Message:

Seairth,

I think I agree with you that because of the specific language
of the spec, "side effects" means effects that are not directly
either a request or a response, which includes all state changes
in resources.  Which is a little wierd when you consider that
the raison d'etre of the protocol is to 'transfer' state, as much
to change it as to discover it.

Hence idempotence, which as discussed earlier on this list is 
a property of functions (constrained relations), refers to the
function whose domain is a resource's pre-state and whose range
is the same resource's post-state, where pre- and post- states
are relative to a single HTTP method invocation.  That seems
clear to me -- modulo Roy's counterclaim about idempotent sequences.

Still, the question arises: Should a client be able (guaranteed
by contract) to discover the mapped or unmapped pre-state of
a resource by invoking DELETE?  Some applications may care, and
so we need to know if that contract was intended by 2616 or
not.

Walden

> -----Original Message-----
> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Thursday, September 19, 2002 12:34 AM
> To: rest-discuss
> Subject: [rest-discuss] True meaning of "Idempotent"?
> 
> 
> What is the true meaning of "idempotent", both in terms of 
> HTTP and in terms
> of REST?  Roy Fielding does not mention idempotency in his 
> dissertation, but
> it certainly appears to be an integral part of our 
> discussions on REST.
> 
> To start, RFC2616 [1:9.1.2] says:
> 
>    Methods can also have the property of "idempotence"
>    in that (aside from error or expiration issues) the
>    side-effects of N > 0 identical requests is the same
>    as for a single request. The methods GET, HEAD, PUT
>    and DELETE share this property. Also, the methods
>    OPTIONS and TRACE SHOULD NOT have side effects, and
>    so are inherently idempotent.
> 
> Generally, I don't think we dispute the above description in 
> terms of what
> happens to a resource on a server.  However, where we seem to disagree
> (mostly due to ambiguity, I think), is just how far the concept of
> idempotency reaches.  For instance, is an operation 
> idempotent if it returns
> different responses?  When we speak of responses, are we 
> talking about only
> the response entity, the metadata, or both?  Since "error or 
> expiration
> issues" are explicitly noted as exceptions, what does 
> idempotency mean in
> those circumstances?  What is the definition of "side-effect"?
> 
> I do not have an answer for this, but I do have some thoughts (and
> opinions)...
> 
> First, let's define what "side-effect" means.  I prefer the 
> term "mutation"
> here, since "side-effect" implies something that occurs 
> indirectly to the
> actual action taken.  However, no one here would consider updating a
> resource with a PUT as a side-effect.  So, the first thing we 
> can say about
> a side-effect (in terms of the HTTP spec) is that we are 
> speaking of the
> changing of a resource.  That's it.  Nothing more.  It could 
> be direct or
> indirect.  Doesn't matter.  The second thing we can say about 
> a side-effect
> (again, in terms of HTTP) is that we are speaking of the end 
> result of the
> changing of a resource, not the process itself.  In other 
> words, we only see
> a side-effect in terms of what state the resource is in after 
> the change.
> 
> Next, let's start applying some scope to these terms (where 
> possible).  To
> start, let's say that side-effects are scoped to the resource 
> on the server.
> The client is never directly aware of side-effect.  Next, 
> let's also say
> that an idempotent method is scoped to the resource on the 
> server as well.
> This makes sense since idempotency depends on side-effects.
> 
> Now, we get to the part where the ambiguity creeps in...
> 
> When one uses an idempotent method which causes a side-effect 
> (PUT, DELETE),
> the server returns a response just like any other request method.  The
> response contains two parts:  the headers (metadata) and the 
> entity-body
> (which can be null).  Recently, we have discussed whether returning
> different responses when issuing repeated DELETEs violates 
> idempotency or
> not.  One camp says that the response should reflect the 
> results of the
> request (i.e. 200 for first response, 404 afterwards).  This 
> attitude would
> imply that the response does not have anything to do with whether the
> request was idempotent or not.  The other camp says that the 
> response should
> reflect the end state of the request (i.e. 200 for all 
> responses).  This
> attitude would imply that the response is as much a part of 
> the idempotency
> requirements as the request is.  What this comes down to is whether we
> consider any part of the response to be within the scope of HTTP's
> definition of idempotency.
> 
> My feeling is that the response has nothing to do with 
> idempotency at all.
> This comes from the use of GET.  GET is an idempotent 
> operation that has no
> side-effect.  As a result, I could issue the same GET several 
> times, and the
> server could return different responses for each of the requests.  For
> instance, in some of the responses, I could get back a 200, but have
> different entity bodies (common for dynamic content).  I 
> could also get back
> different response codes, such as 200 (OK), then 301 (Moved 
> Permanently),
> then 404 (Not Found).  Despite these different responses, 
> each of the GETs
> is still considered to be idempotent.
> 
> Now, let's move on to PUT.  When PUT is used, and the resource did not
> exist, then a 201 (Created) response is expected.  Subsequent 
> PUTs to the
> same resource return 200 (OK) responses.  This is very common 
> practice and I
> have never heard a single person say this is not idempotent.
> 
> So, now we move on to DELETE.  In this case, let's say that 
> the first DELETE
> will return a 200 response and subsequent DELETEs return a 
> 404 response.
> >From the definition and scoping of "side-effect" above, we 
> all agree that
> the state of the resource after each delete is that it does 
> not exist.  This
> is enough to also satisfy DELETE's requirement of 
> idempotency.  Further,
> this is no different than returning two responses for repeated PUTs.
> 
> 
> In the end, my personal conclusion is that responses have 
> nothing to do with
> idempotency.  Idempotency is only limited to the resource on 
> the server.
> Regardless of what is returned to the client, the operation 
> on the server is
> idempotent (assuming that the end state is the same after 
> repeated identical
> requests).
> 
> 
> So what does this mean for returning responses from DELETE?  
> I think that
> 200 (OK) or 202 (Accepted) or 204 (No Content), followed by 
> 404 (Not Found)
> or 410 (Gone) and maybe 303 (See Other) would be no different 
> than expected
> of other idempotent methods like PUT and GET.
> 
> If I had to suggest an order of usage, I'd say (in order of 
> most expressive
> to least expressive):
> 
> First request:
>     204 (No Content)
>     202 (Accepted)
>     200 (OK)
> 
> Repeated requests:
>     303 (See Other)
>     410 (Gone)
>     404 (Not Found)
> 
> 
> Should we allow repeated DELETE requests to always get back a 
> "200" (or
> similar) response?  PUT (DELETE's binary opposite) doesn't 
> allow it.  GET,
> while possible to receive the same response over and over 
> again, must also
> be open to receiving other responses as well.  So, why should 
> DELETE be any
> different?  My thought here is that it would be wrong (given 
> the way the
> other two verbs work) to return the same response code 
> regardless of whether
> the resource was deleted or not.
> 
> 
> <note>I think that's it.  Sorry if it seemed to ramble on.  I stopped
> somewhere in the middle to watch The Daily Show (comedy 
> central) and when
> they showed the clip of Bush totally screwing up a simple 
> quote, I just lost
> all concentration (funny stuff, it was).  Again, sorry if it all seems
> incoherent.  :) *giggle* </note>
> 
> [1] http://www.ietf.org/rfc/rfc2616.txt
> 
> ---
> Seairth Jacobs
> seairth@...
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2616
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-19 14:18:11
Subject:RE: [rest-discuss] True meaning of "Idempotent"?
Message:

> If we take this interpretation of idempotence, then RFC 2616's 
> discussion of non-idempotent sequences of idempotent methods makes no 
> sense at all, because on this interpretation *all* sequences of 
> idempotent methods are idempotent sequences: see the proof I gave 
> earlier ... which I'm confident that Walden's model, if he puts it 
> together, will verify.

I had thought the proof was convincing, but if people still have
doubts, I'll throw the model together.  I don't know how to model
the act of repeating a function (or function series) arbitrarily
many times, but I think that a discrete repeat scope = 5 should
satisfy most critics.  Of course it's easy to hack the model to
larger scopes.

Sorry for not getting these models up sooner, and I'm a bit bogged
down with the rewrite of a RESTful specification right now, with
management drunk of schedule pressures and postponing quality wherever
possible.

Bear with me; I have some of this stuff on paper.

Walden






-----------------------------------------------------------------------------------
Post ID:2617
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-19 14:21:42
Subject:Re: [rest-discuss] True meaning of "Idempotent"?
Message:

From: "Mathews, Walden" <waldenm@...>
>
> Still, the question arises: Should a client be able (guaranteed
> by contract) to discover the mapped or unmapped pre-state of
> a resource by invoking DELETE?  Some applications may care, and
> so we need to know if that contract was intended by 2616 or
> not.

I would say the answer is "yes", the client should be able to discover the
pre-state when using DELETE, but can ignore what it finds.  The reason I say
this is because 2616 already explicitly says this very thing about PUT (201,
followed by 200).  The problem I see is that, unlike PUT, DELETE's spec
leaves us guessing as to *which* response(s) to use.  The only thing I feel
for certain is that we should not send the same response when the pre-state
is different between requests (e.g. 200 only), at least as far as DELETEs
are concerned.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2618
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-19 14:23:20
Subject:Re: [rest-discuss] Re: Resources always exist
Message:

> Paul Prescod wrote:
>
> I think that there is a problem and a variety of solutions and am 
> soliciting opinions on both issues.

Ambiguity of the spec with regards to DELETE has been recognized
for a while, e.g.:

   http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0111.html

I get the sense that some common understanding may have been achieved, but 
if in fact there was one, this agreement is now folkloric and hasn't been 
explicitly published anywhere.  

If someone can clearly demonstrate how a reasonable interpretation of the
semantics of DELETE will lead to broken client-side code because of 
inconsistent server-side implementations, it would seem important enough 
that it should be addressed directly by the TAG, much like was done with 
regards to GET:  

   http://www.w3.org/2001/tag/doc/get7

> Mathews, Walden wrote:
>
> shall I publish a simple Alloy model to this list
> tommorow to drive a stake into the ground?

I'd like to see it.  It be a good way to bring the ambiguity into relief
and help to reinforce the importance of the problem if it does get presented
to the TAG.

- Winter








-----------------------------------------------------------------------------------
Post ID:2619
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-19 14:34:01
Subject:RE: [rest-discuss] Re: Resources always exist
Message:

> 
> > Mathews, Walden wrote:
> >
> > shall I publish a simple Alloy model to this list
> > tommorow to drive a stake into the ground?
> 
> I'd like to see it.  It be a good way to bring the ambiguity 
> into relief
> and help to reinforce the importance of the problem if it 
> does get presented
> to the TAG.
> 
> - Winter


Okay, so do I understand correctly that what we want to model
is the DELETE operation in two variants: the first says that
the resource->representation mapping may be empty and DELETE is
still a valid method; the second says the a non-empty mapping
is a required pre-condition for DELETE.

Translated to response codes, the former says that if the
server honors DELETE, then the response code is always 200; the
second says that if the server honors DELETE but the resource
was unmapped before the delete, then in that case the response
is 404, else it's 200.

Do I correctly understand the modelling task here?

Walden

Is that the problem






-----------------------------------------------------------------------------------
Post ID:2620
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-19 16:35:59
Subject:What is a Resource
Message:

For anyone not already participating in the uri@... mailing list, 
there are some interesting threads related to some of the things being 
discussed here on rest-discuss.

I discovered these when following up on the comment Mark B made about 
"DELETE shouldn't return a 404."  The message from Roy F. that Mark 
included was actually a post [1] Roy made to the uri@... list. When I 
went there and read the entire thread, Mark's response made more sense. 
 In fact, my own notion of what a resource is (in HTTP) and the 
relationship between URIs and resources has changed somewhat.

At least for me, it was interesting and instructive to follow the entire 
thread and some of the side-threads it generated.  In partciular, there 
were two messages [2] [3] that talked about the concept of resources 
being composed of other resources - especially where a resource has 
multiple representations.  These shed some light on the limitations of 
PUT with regard to representations and changed my notion of how content 
negotiation fits into the bigger picture .

[1]  http://lists.w3.org/Archives/Public/uri/2002Sep/0045.html
[2]  http://lists.w3.org/Archives/Public/uri/2002Sep/0046.html
[3]  http://lists.w3.org/Archives/Public/uri/2002Sep/0028.html


(I hate that archives are broken out by month - it makes it so much 
harder to follow threads that span more than one month).

--Chuck







-----------------------------------------------------------------------------------
Post ID:2621
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-19 17:20:12
Subject:Re: [rest-discuss] True meaning of "Idempotent"?
Message:

Seairth Jacobs wrote:
 >...
I don't really see this bit as confusing at all. Of course an operation 
will return different responses. When you PUT to an object that doesn't 
exist you get Created. When you PUT again, you don't. Idempotency is 
about *side-effects* which I take to mean anything outside of the 
request/response pair.

 >...
> Now, let's move on to PUT.  When PUT is used, and the resource did not
> exist, then a 201 (Created) response is expected.  Subsequent PUTs to the
> same resource return 200 (OK) responses.  This is very common practice and I
> have never heard a single person say this is not idempotent.

I strongly feel your analysis is correct. I never saw the debate about 
two deletes as having anything to do with idempotence. It is merely a 
question of whether deleting a thing twice is an error or a normal 
action. In most file systems I'm familiar with it is an error. That's 
because objects have identity in a file system and trying to delete a 
non-existent object is a problem.

In SQL, a DELETE that effects nothing is not a problem because "rows" do 
not have identity (except in a particular application domain where you 
choose some column or set of columsn to use as the identifier).

But this has nothing to do with idempotency.

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2622
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-19 17:28:45
Subject:RE: [rest-discuss] True meaning of "Idempotent"?
Message:


> -----Original Message-----
> From: Paul Prescod [mailto:paul@...]
> Sent: Thursday, September 19, 2002 1:20 PM
> To: Seairth Jacobs
> Cc: rest-discuss
> Subject: Re: [rest-discuss] True meaning of "Idempotent"?
> 
> 
> Seairth Jacobs wrote:
>  >...
> I don't really see this bit as confusing at all. Of course an 
> operation 
> will return different responses. When you PUT to an object 
> that doesn't 
> exist you get Created. When you PUT again, you don't. Idempotency is 
> about *side-effects* which I take to mean anything outside of the 
> request/response pair.
> 
>  >...
> > Now, let's move on to PUT.  When PUT is used, and the 
> resource did not
> > exist, then a 201 (Created) response is expected.  
> Subsequent PUTs to the
> > same resource return 200 (OK) responses.  This is very 
> common practice and I
> > have never heard a single person say this is not idempotent.
> 
> I strongly feel your analysis is correct. I never saw the 
> debate about 
> two deletes as having anything to do with idempotence. It is merely a 
> question of whether deleting a thing twice is an error or a normal 
> action. In most file systems I'm familiar with it is an error. That's 
> because objects have identity in a file system and trying to delete a 
> non-existent object is a problem.
> 
> In SQL, a DELETE that effects nothing is not a problem 
> because "rows" do 
> not have identity (except in a particular application domain 
> where you 
> choose some column or set of columsn to use as the identifier).
> 
> But this has nothing to do with idempotency.
> 
>   Paul Prescod

I see the link to idempotence.  Because of its definition, idempotent
operations identify their end states (Proof, Miles?)  In end-state
"speak", SQL DELETE is idempotent because it is silent about mechanism,
while filesystem delete is "idempotent" because it is silent about
end-state, gabby about mechanism.

Is 'declarative' the word I really want?  Even so, I believe you
can construct the connection between 'declarative' and 'idempotent'
if you want to.

Walden






-----------------------------------------------------------------------------------
Post ID:2623
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-19 17:33:44
Subject:Re: [rest-discuss] Re: Resources always exist
Message:

> Translated to response codes, the former says that if the
> server honors DELETE, then the response code is always 200; the
> second says that if the server honors DELETE but the resource
> was unmapped before the delete, then in that case the response
> is 404, else it's 200.
>
> Do I correctly understand the modelling task here?

I believe that captures it.  I'm also left wondering: if subsequent 
DELETEs after an initial DELETE can return 200, does would imply that
GET/HEAD should return 200/204 with an empty entity-body too?  Perhaps
you could include that in your model also?








-----------------------------------------------------------------------------------
Post ID:2624
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-19 17:43:52
Subject:RE: [rest-discuss] Re: Resources always exist
Message:


> -----Original Message-----
> From: Jeffrey Winter [mailto:j.winter@...]
> Sent: Thursday, September 19, 2002 1:34 PM
> To: Mathews, Walden; S. Mike Dierken; Paul Prescod
> Cc: rest-discuss
> Subject: Re: [rest-discuss] Re: Resources always exist
> 
> 
> > Translated to response codes, the former says that if the
> > server honors DELETE, then the response code is always 200; the
> > second says that if the server honors DELETE but the resource
> > was unmapped before the delete, then in that case the response
> > is 404, else it's 200.
> >
> > Do I correctly understand the modelling task here?
> 
> I believe that captures it.  I'm also left wondering: if subsequent 
> DELETEs after an initial DELETE can return 200, does would imply that
> GET/HEAD should return 200/204 with an empty entity-body too?  Perhaps
> you could include that in your model also?

I'll include it if I understand it well enough. ;-)  So you're saying
that if the nth DELETE of some resource (with no intervening operations
that could restore representation mapping) can return 200 (i.e., "OK
it's not mapped"), then should a GET at this point (again, no intervening
operations to change state) also return 200 (i.e., "OK, the resource
is here because resources always exist) with an empty entity-body (i.e.,
"just because it exists doesn't mean it maps to any representations")?

That's a different kind of modeling problem, and I'm not sure modeling
will clarify anything.  I believe the rule is that 404 means no
representation was found, while it's implicit that any resource that
ever existed still does.

Walden
> 
> 






-----------------------------------------------------------------------------------
Post ID:2625
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-19 19:28:11
Subject:Re: [rest-discuss] Re: Resources always exist
Message:

FWIW: I downloaded Slide, the Apache Jakarta WebDAV implementation.

Insofar as this perhaps represents a "reference" implementation 
of an extension to the HTTP protocol, here's how it behaves:

  Request:    PUT /test.xml HTTP/1.1
  Response:   HTTP/1.1 201 Created

  Request:    GET /test.xml HTTP/1.1
  Response:   HTTP/1.1 200 OK

  Request:    DELETE /test.xml HTTP/1.1
  Response:   HTTP/1.1 204 No Content

  Request:    DELETE /test.xml HTTP/1.1
  Response:   HTTP/1.1 404 Not Found

  Request:    GET /test.xml HTTP/1.1
  Response:   HTTP/1.1 404 Not Found

Whether or not this represents some manifestation of the
"folkloric" understanding of the behavior of the ambiguous
DELETE specification I have no idea, but it of course certainly 
makes intuitive sense.  I think it was also what most people 
would have expect the behavior to be - right up until Mark 
Baker's hand-grenade of last week: 

  http://groups.yahoo.com/group/rest-discuss/message/2531

I'm not sure this really answers anything but it's an interesting
data point. Is Slide wrong?

- Winter








-----------------------------------------------------------------------------------
Post ID:2626
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-19 22:10:15
Subject:Re: [rest-discuss] Re: Resources always exist
Message:

----- Original Message -----
From: "Jeffrey Winter" <j.winter@...>



> FWIW: I downloaded Slide, the Apache Jakarta WebDAV implementation.
Neat - I didn't know there was one.

>
> Insofar as this perhaps represents a "reference" implementation
> of an extension to the HTTP protocol, here's how it behaves:

I'm seeing two viewpoints of what an 'http request' is and they each have
different expectations.
The first is 'please perform this operation upon this resource' - so a
DELETE on a non-existent resource fails.
The second is 'please make it such that the resource does not exist' - so a
DELETE on a non-existent resource is a 'duh - okay' response.

The first is more of a procedural point of view, and the second is more of a
declarative/logical assertion point of view. I don't know if that makes any
sense, but I hope the HTTP philosophy isn't the declarative/logical
assertion approach, since 0.001% of programmers would get it.







-----------------------------------------------------------------------------------
Post ID:2627
Sender:"firepipe_au" <michael@...>
Post Date/Time:2002-09-20 01:37:07
Subject:Re: Resources always exist
Message:

--- In rest-discuss@y..., "Mathews, Walden" <waldenm@i...> wrote:
> 
> 
> > -----Original Message-----
> > From: Jeffrey Winter [mailto:j.winter@n...]
> > Sent: Thursday, September 19, 2002 1:34 PM
> > To: Mathews, Walden; S. Mike Dierken; Paul Prescod
> > Cc: rest-discuss
> > Subject: Re: [rest-discuss] Re: Resources always exist
> > 
> > 
> > > Translated to response codes, the former says that if the
> > > server honors DELETE, then the response code is always 200; the
> > > second says that if the server honors DELETE but the resource
> > > was unmapped before the delete, then in that case the response
> > > is 404, else it's 200.
> > >
> > > Do I correctly understand the modelling task here?
> > 
> > I believe that captures it.  I'm also left wondering: if 
subsequent 
> > DELETEs after an initial DELETE can return 200, does would imply 
that
> > GET/HEAD should return 200/204 with an empty entity-body too?  
Perhaps
> > you could include that in your model also?
> 
> I'll include it if I understand it well enough. ;-)  So you're 
saying
> that if the nth DELETE of some resource (with no intervening 
operations
> that could restore representation mapping) can return 200 (i.e., "OK
> it's not mapped"), then should a GET at this point (again, no 
intervening
> operations to change state) also return 200 (i.e., "OK, the resource
> is here because resources always exist) with an empty entity-body 
(i.e.,
> "just because it exists doesn't mean it maps to any 
representations")?
> 
> That's a different kind of modeling problem, and I'm not sure 
modeling
> will clarify anything.  I believe the rule is that 404 means no
> representation was found, while it's implicit that any resource that
> ever existed still does.
>

Agreed there.  The problem with DELETE does not apply for GET.

While RFC 2616 says that "the side-effects of N > 0 identical 
requests is the same as for a single request", this is not the case 
with DELETE, regardless of response codes, unless the representation 
being deleted never existed (In which you can always return a 404 - 
while not stated explicitly as legal in the spec in regards to 
DELETE, it seems to be implied from other areas).

On the first DELETE, there is a side-effect - a representation is un-
mapped.  On the second and subsequent DELETEs, there is no 
representation to un-map, so the side effect /cannot/ take place.  It 
seems impossible to me to maintain idempotence across requests 1 and 
2 with DELETE, and impossible not to (as far as effects on the server 
go) on all requests > 1.

The problem with trying to prove that always (for requests > 0)
returning a 200 (duh) OK/202/204 response would break a client is 
that the spec also states that it is not guaranteed that the intended 
side-effect actually occurred (perhaps supervisor authorisation must 
first be granted, for instance).  To return a 404 is guaranteeing 
that the side-effect did not take place; to return a 20X response is 
more in keeping with the spec where no guarantees are given.  However 
in the 20X case the client can never be sure the request was 
actioned, and your dream of a consistent interface flies out the 
window.

Imagine if dialog boxes had "Yes", "No" and "Maybe" buttons...

As a client, I'd like to see a 404 telling my I'm stupid for trying 
to delete something that didn't exist.  At least then I can check for 
typos.  In which case, 2616 would have to be subject to a minor 
alteration:

"the side-effects of N > 0 identical requests is the same as for a 
single request [ except in the case of DELETE, where N > 1 ]"









-----------------------------------------------------------------------------------
Post ID:2628
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-20 04:44:30
Subject:Re: [rest-discuss] Re: Resources always exist
Message:

firepipe_au wrote:
> --- In rest-discuss@y..., "Mathews, Walden" <waldenm@i...> wrote:
> 
>...

> While RFC 2616 says that "the side-effects of N > 0 identical 
> requests is the same as for a single request", this is not the case 
> with DELETE, regardless of response codes, unless the representation 
> being deleted never existed (In which you can always return a 404 - 
> while not stated explicitly as legal in the spec in regards to 
> DELETE, it seems to be implied from other areas).
> 
> On the first DELETE, there is a side-effect - a representation is un-
> mapped.  On the second and subsequent DELETEs, there is no 
> representation to un-map, so the side effect /cannot/ take place.  It 
> seems impossible to me to maintain idempotence across requests 1 and 
> 2 with DELETE, and impossible not to (as far as effects on the server 
> go) on all requests > 1.

What's the problem? After one request the state of the universe is that 
the resource does not exist and/or is unmapped. After ten requests, the 
resource does not exist and/or is unmapped. That's idempotence!

 >...
> "the side-effects of N > 0 identical requests is the same as for a 
> single request [ except in the case of DELETE, where N > 1 ]"

The *side effect* is the same. There is no resource. The response may be 
different.

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2629
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-09-20 08:00:18
Subject:RE: [rest-discuss] Re: Resources always exist
Message:

> From: firepipe_au [mailto:michael@...]
> Sent: Friday, September 20, 2002 3:37 AM
> To: rest-discuss@yahoogroups.com
> Subject: [rest-discuss] Re: Resources always exist
>
> ...
>
> Agreed there.  The problem with DELETE does not apply for GET.
>
> While RFC 2616 says that "the side-effects of N > 0 identical
> requests is the same as for a single request", this is not the case
> with DELETE, regardless of response codes, unless the representation
> being deleted never existed (In which you can always return a 404 -
> while not stated explicitly as legal in the spec in regards to
> DELETE, it seems to be implied from other areas).

Huh? The side effect for the single DELETE is that the URI mapping is
removed. The side effect for N DELETEs (where N > 1) is the same -- the URI
mapping is removed. What's the problem here?

> On the first DELETE, there is a side-effect - a representation is un-
> mapped.  On the second and subsequent DELETEs, there is no
> representation to un-map, so the side effect /cannot/ take place.  It

It doesn't have to anymore.

> ...

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760







-----------------------------------------------------------------------------------
Post ID:2630
Sender:"waldenmathews" <waldenm@...>
Post Date/Time:2002-09-21 05:37:16
Subject:Idempotence
Message:

Hi all,

The confusion seems to have shifted to the interpretation
of "side-effects".  A side-effect sounds more like a state
transition than a state designation, but I'm sure Dr. Fielding
meant the latter, not the former.

Saying that DELETE is idempotent with respect to the function
that maps the deleted resource's pre-DELETE state to its post-
DELETE state is not implying anything about the response
code for the DELETE request-response.  Perhaps this should be
specified; perhaps it shouldn't.

Exciting news!  I just finished an extended design session with
four other developers in re-designing the web interface to the
project we're working on.  Several of them had epiphanies today
in which they discovered the meaning (and coolness) of "hypertext
as the engine of application state".  Witnessing that was a
terrific experience for me.  Made my week.  Our new design (2nd
cut at hitting the REST mark) is quite good.

More exciting news!!  Roy is right.  Sequences of idempotent 
operations need not be idempotent.  I build an Alloy model tonight
(finally) which demonstrates this.  I have a pdf which I'll post here 
as soon as I can find my way into a mail client.  So stay tuned...

Walden







-----------------------------------------------------------------------------------
Post ID:2631
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-21 05:52:14
Subject:Re: [rest-discuss] Idempotence
Message:

----- Original Message -----
From: "waldenmathews" <waldenm@...>

> Several of them had epiphanies today
> in which they discovered the meaning (and coolness) of "hypertext
> as the engine of application state".
Please explain - that part I just don't understand... examples work for
me...
How can 'hypertext' (which seems static) and 'engine' (which seems dynamic)
be connected?








-----------------------------------------------------------------------------------
Post ID:2632
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-09-21 05:51:40
Subject:Roy was right
Message:

Ok, you'll find attached the pdf file generated by Alloy.  The functions f, g and h are
all idempotent: they satisfy the constraint 

    fun(fun(x)) = fun(x) for all x mapped by fun (plug f, g and h in for 'fun')

The analyzer was asked to generate a counterexample to the claim that
there is no x such that f(g(h(f(g(h(x))))))) = f(g(h(x))), and it found one.  The
reason it's not intuitive is that we need at least 6 nodes for this condition
to occur.

Battery low.  I'll post the model code tomorrow for those interested.  What's
the next modelling challenge?

--Walden





-----------------------------------------------------------------------------------
Post ID:2633
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-21 05:53:25
Subject:Re: [rest-discuss] Idempotence
Message:

----- Original Message -----
From: "waldenmathews" <waldenm@...>

>
> Exciting news!  I just finished an extended design session with
> four other developers in re-designing the web interface to the
> project we're working on.
Is the 'web interface' for the 'visual web' or the 'automatable web'? Is is
UI or an application information model?






-----------------------------------------------------------------------------------
Post ID:2634
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-21 05:57:05
Subject:Re: [rest-discuss] Roy was right
Message:

----- Original Message -----
From: "Walden Mathews" <waldenm@...>



> Ok, you'll find attached the pdf file generated by Alloy.  The functions
f, g and h are
> all idempotent: they satisfy the constraint
>
>     fun(fun(x)) = fun(x) for all x mapped by fun (plug f, g and h in for
'fun')

When you have nested functions - what does that mean? Is it the return data
of one function is the input to another function, or is it the function
applied to the total state of the system after applying the function to the
total state of the system (where its initial conditions are identified by
'x')?






-----------------------------------------------------------------------------------
Post ID:2635
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-09-21 05:58:01
Subject:Re: [rest-discuss] Idempotence
Message:

----- Original Message -----
From: "S. Mike Dierken" <mdierken@...>
To: <rest-discuss@yahoogroups.com>; "waldenmathews" <waldenm@...>
Sent: Saturday, September 21, 2002 1:53 AM
Subject: Re: [rest-discuss] Idempotence


>
> ----- Original Message -----
> From: "waldenmathews" <waldenm@...>
>
> >
> > Exciting news!  I just finished an extended design session with
> > four other developers in re-designing the web interface to the
> > project we're working on.
> Is the 'web interface' for the 'visual web' or the 'automatable web'? Is
is
> UI or an application information model?

Oh good heavens man, the latter, the latter. 8-)
W







-----------------------------------------------------------------------------------
Post ID:2636
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-09-21 06:01:23
Subject:Re: [rest-discuss] Roy was right
Message:

----- Original Message -----
From: "S. Mike Dierken" <mdierken@...>
To: <rest-discuss@yahoogroups.com>; "Walden Mathews" <waldenm@...>
Cc: <waldenm@...>
Sent: Saturday, September 21, 2002 1:57 AM
Subject: Re: [rest-discuss] Roy was right


>
> ----- Original Message -----
> From: "Walden Mathews" <waldenm@...>
>
>
>
> > Ok, you'll find attached the pdf file generated by Alloy.  The functions
> f, g and h are
> > all idempotent: they satisfy the constraint
> >
> >     fun(fun(x)) = fun(x) for all x mapped by fun (plug f, g and h in for
> 'fun')
>
> When you have nested functions - what does that mean? Is it the return
data
> of one function is the input to another function, or is it the function
> applied to the total state of the system after applying the function to
the
> total state of the system (where its initial conditions are identified by
> 'x')?

You have to make that interpretation yourself.  Idempotent is a mathematical
property of homogeneous binary relations.  You decide what's related to what
when you do HTTP message exchange.  Defined as way above.

My answer is that you are relating pre-state to post-state of the resource,
also
badly known as the "side-effect" thing.  The response code is not the same
type
as the resource state, so there's no homogeneity available there.

Walden (truly so low on battery I must now shut down)







-----------------------------------------------------------------------------------
Post ID:2637
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-21 06:14:45
Subject:Re: [rest-discuss] Roy was right
Message:

Walden Mathews wrote,
> Ok, you'll find attached the pdf file generated by Alloy.  The
> functions f, g and h are all idempotent: they satisfy the constraint
>
>     fun(fun(x)) = fun(x) for all x mapped by fun (plug f, g and h in
> for 'fun')
>
> The analyzer was asked to generate a counterexample to the claim that
> there is no x such that f(g(h(f(g(h(x))))))) = f(g(h(x))), and it
> found one.  The reason it's not intuitive is that we need at least 6
> nodes for this condition to occur.

Fascinating! Good stuff ...

That said, this doesn't actually settle the issue. The problem is that 
GET, PUT and DELETE are more constrained than f, g and h in your model. 
For example, a function modelling GET should never generate a state 
transition ... and all of the fn's in your counter-example violate that 
constraint.

PUT and DELETE are, I think, also more constrained, in that,

  PUT /foo
  DELETE /foo

is equivalent to,

  DELETE /foo

and,

  DELETE /foo
  PUT /foo

is equivalent to,

  PUT /foo

and again, all of the fn's in your counter-example violate those 
constraints too.

All three of these constraints played an essential role in my proof, so 
it'd help either if you could produce a new model which respects them, 
or if we could provide a rationale for why it's OK to violate them.

BTW, is Alloy publicly available? Having seen the results I'd be 
interested in playing with it.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2638
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-21 13:39:27
Subject:Where does the "representation" start?
Message:

With REST, we talk about transfering representations.  However, in HTTP, how
much of a message is the representation?  For instance, in a server
response, we have three basic parts:

1) Response code
2) Headers
3) Entity-body (Message-body)

So, which of the above is actually part of the representation of a resource?
Does this change based on the verb being used?  Does this change based on
the response code being used?  Are some headers considered part of the
representation while others are not?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2639
Sender:Jan Algermissen <algermissen@...>
Post Date/Time:2002-09-21 17:16:25
Subject:newbie question (web service composition)
Message:

Hi,

I am still very new to REST and I can't decide what the best way to go would
be for the following issue:

Suppose I have an index that maps words to the documents they occurr in and
I want to make that index accessable as a RESTful web service.

Since the index is potentially too large to return it completely I need to
break it down into smaller chunks.

I wonder if

a) it is appropriate to think of the whole index as a concept of it's own and
   to respond with different representations of it according to some parameters in
   the query string of a GET request:

   http:/foo.bar/archive/index?range=a-c
   http:/foo.bar/archive/index?range=d-f
   ...

   Again: is it a good idea to think of the particular chunks of the index as
   different representations of the concept of the index as a whole ?

   Or am I actually wrong when I think that the two URIs above identify the same
   resource (is the query string part of the URI? )?

   I think that I so far understood that fragment identifiers are not part of the
   URI (don't affect what the URI identifies) and so I wonder if it would be better
   to move the range part in a fragment:

   http:/foo.bar/archive/index#a-c
   http:/foo.bar/archive/index#d-f

   
or if

b) the above is actually the wrong wy to think and if it would be better to view all
   the different chunks of the index as concepts themselves and to create resources
   for them:

   http:/foo.bar/archive/index

   might then return something like

   <index>
     <subindex range="a-c" href="http:/foo.bar/archive/index/a-c" />
     <subindex range="d-f" href="http:/foo.bar/archive/index/d-f" />
     ...
   </index>

   which would allow the server to control the size of the chunks dynamically.
   If the index is quite small it might 'choose' to return

   <index>
     <subindex range="a-m" href="http:/foo.bar/archive/index/a-m" />
     <subindex range="n-z" href="http:/foo.bar/archive/index/n-z" />
   </index>

   instead.


   And it might also choose to return further subindexes (e.g. aa-am)
   thus varying the number of drill-down levels depending on the index size.



I haven't yet understood the REST principles enough to make a decision between
a) and b) above (or yet something completely different?) and I would be very
thankful for help with this.


Jan



   
-- 
Jan Algermissen
Consultant & Programmer

Tel:   ++49 (0)40 89 700 511
       ++49 (0)177 283 1440
Fax:   ++49 (0)40 89 700 841 
Email: algermissen@...
Web:   http://www.topicmapping.com






-----------------------------------------------------------------------------------
Post ID:2640
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-21 18:49:00
Subject:Re: [rest-discuss] Where does the "representation" start?
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>
>
> 1) Response code
> 2) Headers
> 3) Entity-body (Message-body)
>
> So, which of the above is actually part of the representation of a
resource?
> Does this change based on the verb being used?  Does this change based on
> the response code being used?  Are some headers considered part of the
> representation while others are not?
I believe a client agent needs to understand all of them to understand what
is and is not the representation.
For example, the Content-Type header is metadata /about/ the representation.
A status code tells you if the entity is even a representation or not. And
so on.







-----------------------------------------------------------------------------------
Post ID:2641
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-21 19:04:42
Subject:Re: [rest-discuss] newbie question (web service composition)
Message:

----- Original Message -----
From: "Jan Algermissen" <algermissen@...>
>
> a) it is appropriate to think of the whole index as a concept of it's own
and
>    to respond with different representations of it according to some
parameters in
>    the query string of a GET request:
>
>    http:/foo.bar/archive/index?range=a-c
>    http:/foo.bar/archive/index?range=d-f
>    ...
>
>    Again: is it a good idea to think of the particular chunks of the index
as
>    different representations of the concept of the index as a whole ?
Addressing different chunks is a good idea. Some uses might not care - like
if the data set was small and only occasionally used. But generally, my
guess is that having chunks available is okay. If a client always gets all
chunks, then you might as well stream the whole thing out in one chunk
though. If you have good caching knowledge, then maybe chunks help.

Maybe you should address the chunks not by lexical range, but by words
themselves. Depends on what data the client is likely to retrieve - try to
put that stuff in one chunk.

>
>    Or am I actually wrong when I think that the two URIs above identify
the same
>    resource (is the query string part of the URI? )?
The query parameters are part of the URI, so these two URI are different
resources.


>
>    I think that I so far understood that fragment identifiers are not part
of the
>    URI (don't affect what the URI identifies) and so I wonder if it would
be better
>    to move the range part in a fragment:
>
>    http:/foo.bar/archive/index#a-c
>    http:/foo.bar/archive/index#d-f
This would cause a single 'index' resource to be retrieved - on large chunk.

>
>
> or if
>
> b) the above is actually the wrong wy to think and if it would be better
to view all
>    the different chunks of the index as concepts themselves and to create
resources
>    for them:
>
>    http:/foo.bar/archive/index
>
>    might then return something like
>
>    <index>
>      <subindex range="a-c" href="http:/foo.bar/archive/index/a-c" />
>      <subindex range="d-f" href="http:/foo.bar/archive/index/d-f" />
>      ...
>    </index>
>
>    which would allow the server to control the size of the chunks
dynamically.
>    If the index is quite small it might 'choose' to return
>
>    <index>
>      <subindex range="a-m" href="http:/foo.bar/archive/index/a-m" />
>      <subindex range="n-z" href="http:/foo.bar/archive/index/n-z" />
>    </index>
>
>    instead.
Good use of hypertext to give central control & still minimize client
coupling. However (and this is from previous arguments PaulP and I have
had), the client is still dependent on the "range='a-m'" concept - the name
'range' and the syntax, content and meaning of the values. The client has to
be coded to understand what the acceptable values, their allowable ranges,
etc.
An alternate would be to use your example #1 and use named query parameters
with the same value space (letters with a dash between). This requires the
server to support query terms, but that is really a trivial burden (some
sort of mapping - path or query based - will always have to be done anyway)
and generating query-based URIs is lighter weight than parsing XML and doing
a content based query.

>    And it might also choose to return further subindexes (e.g. aa-am)
>    thus varying the number of drill-down levels depending on the index
size.
>
> I haven't yet understood the REST principles enough to make a decision
between
> a) and b) above (or yet something completely different?) and I would be
very
> thankful for help with this.
Good example and good questions. What kind of data size do you expect to
encounter? What kind of clients do you wish to interact with?
Both are fairly RESTful.

Consider an alternate approach to exposing the map between a word and a list
of documents.
http://index.searchalert.net/documents/index?word=up

This might not fit your larger system, but what is interesting about this is
the potential to use POST on the same resource. You could POST a list of
documents that have 'up' in them - which make the index manager purely an
index manager and not a text parser. You could separate these two 'services'
(pieces of functionality) across the Web (assuming a bunch of other
things...)










-----------------------------------------------------------------------------------
Post ID:2642
Sender:Jan Algermissen <algermissen@...>
Post Date/Time:2002-09-21 20:53:34
Subject:Re: [rest-discuss] newbie question (web service composition)
Message:

Mike,

thanks for the very helpfull answer
(comments below).

"S. Mike Dierken" wrote:
> 
> ----- Original Message -----
> From: "Jan Algermissen" <algermissen@...>
> >
> > a) it is appropriate to think of the whole index as a concept of it's own
> and
> >    to respond with different representations of it according to some
> parameters in
> >    the query string of a GET request:
> >
> >    http:/foo.bar/archive/index?range=a-c
> >    http:/foo.bar/archive/index?range=d-f
> >    ...
> >
> >    Again: is it a good idea to think of the particular chunks of the index
> as
> >    different representations of the concept of the index as a whole ?
>
> Addressing different chunks is a good idea. Some uses might not care - like
> if the data set was small and only occasionally used. But generally, my
> guess is that having chunks available is okay. If a client always gets all
> chunks, then you might as well stream the whole thing out in one chunk
> though. If you have good caching knowledge, then maybe chunks help.
> 
> Maybe you should address the chunks not by lexical range, but by words
> themselves. Depends on what data the client is likely to retrieve - try to
> put that stuff in one chunk.
> 
> >
> >    Or am I actually wrong when I think that the two URIs above identify
> the same
> >    resource (is the query string part of the URI? )?
> The query parameters are part of the URI, so these two URI are different
> resources.

Ok, I thought so.
> 
> >
> >    I think that I so far understood that fragment identifiers are not part
> of the
> >    URI (don't affect what the URI identifies) and so I wonder if it would
> be better
> >    to move the range part in a fragment:
> >
> >    http:/foo.bar/archive/index#a-c
> >    http:/foo.bar/archive/index#d-f
> This would cause a single 'index' resource to be retrieved - on large chunk.

Yes, that's obvious now that you remined me ;-)
 
> >
> >
> > or if
> >
> > b) the above is actually the wrong wy to think and if it would be better
> to view all
> >    the different chunks of the index as concepts themselves and to create
> resources
> >    for them:
> >
> >    http:/foo.bar/archive/index
> >
> >    might then return something like
> >
> >    <index>
> >      <subindex range="a-c" href="http:/foo.bar/archive/index/a-c" />
> >      <subindex range="d-f" href="http:/foo.bar/archive/index/d-f" />
> >      ...
> >    </index>
> >
> >    which would allow the server to control the size of the chunks
> dynamically.
> >    If the index is quite small it might 'choose' to return
> >
> >    <index>
> >      <subindex range="a-m" href="http:/foo.bar/archive/index/a-m" />
> >      <subindex range="n-z" href="http:/foo.bar/archive/index/n-z" />
> >    </index>
> >
> >    instead.
> Good use of hypertext to give central control & still minimize client
> coupling. However (and this is from previous arguments PaulP and I have
> had), the client is still dependent on the "range='a-m'" concept - the name
> 'range' and the syntax, content and meaning of the values. The client has to
> be coded to understand what the acceptable values, their allowable ranges,
> etc.

Hmm, as far as I understood one idea is to put
links to subsequent resources inside a representation to give the client a path
to follow _without_ having the client to construct the URIs (using some deeper
knowledge of the server). Your answer sounds like the client would have to
construct the URIs for the subindexes, am I missing something here ?

> An alternate would be to use your example #1 and use named query parameters
> with the same value space (letters with a dash between). 

Do you mean exactly like in example #1:

http:/foo.bar/archive/index?range=a-c

So basically like search engines work ?

I am using the 'drill-down' effect that way, don't I ?

> This requires the
> server to support query terms, but that is really a trivial burden (some
> sort of mapping - path or query based - will always have to be done anyway)
> and generating query-based URIs is lighter weight than parsing XML and doing
> a content based query.

Hmm, this sounds as if there is a way to avoid having the client understand the
syntax of the answer ?

> 
> >    And it might also choose to return further subindexes (e.g. aa-am)
> >    thus varying the number of drill-down levels depending on the index
> size.
> >
> > I haven't yet understood the REST principles enough to make a decision
> between
> > a) and b) above (or yet something completely different?) and I would be
> very
> > thankful for help with this.
> Good example and good questions. What kind of data size do you expect to
> encounter?

This was actually a hypothetical example (you might think of a digital library
that would also offer things like 'view a list of all authors and their publications').
I am thinking at a very large scale where 'chunking' would definitely be a neccessity.

>  What kind of clients do you wish to interact with?

Browsers (in which case I would return HTML) but also non-human clients like
other services for example.

> Both are fairly RESTful.

Good to hear ;-)
> 
> Consider an alternate approach to exposing the map between a word and a list
> of documents.

> http://index.searchalert.net/documents/index?word=up
> 
> This might not fit your larger system, but what is interesting about this is
> the potential to use POST on the same resource. 

You mean that if the index is represented as a concept (resource) then querying
it and adding to it should both be performed on the same resource ? Ah, I see that
http://index.searchalert.net/documents/index?word=up is a resource that (might)
mean "the part of the index that represents all occurrences of 'up'" and that posting
a list of documents (URLs) to it would mean to add occurrences to that part of the index,
yes ? Interesting!

> You could POST a list of
> documents that have 'up' in them - which make the index manager purely an
> index manager and not a text parser. You could separate these two 'services'
> (pieces of functionality) across the Web (assuming a bunch of other
> things...)

Yes, I see what you are up to. Thanks, that helped a lot.

Jan



-- 
Jan Algermissen
Consultant & Programmer

Tel:   ++49 (0)40 89 700 511
       ++49 (0)177 283 1440
Fax:   ++49 (0)40 89 700 841 
Email: algermissen@...
Web:   http://www.topicmapping.com






-----------------------------------------------------------------------------------
Post ID:2643
Sender:Jan Algermissen <algermissen@...>
Post Date/Time:2002-09-21 21:12:06
Subject:Re: [rest-discuss] newbie question (web service composition)
Message:

Jan Algermissen wrote:

> > An alternate would be to use your example #1 and use named query parameters
> > with the same value space (letters with a dash between).
> 
> Do you mean exactly like in example #1:
> 
> http:/foo.bar/archive/index?range=a-c
> 
> So basically like search engines work ?

Uh, when I wrote:

> I am using the 'drill-down' effect that way, don't I ?

I actually meant to write:

I am loosing the 'drill-down' effect that way, don't I ?
     ^^^^^^^

Sorry about that.

Jan






-----------------------------------------------------------------------------------
Post ID:2644
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-22 01:21:43
Subject:Re: [rest-discuss] Where does the "representation" start?
Message:

From: "S. Mike Dierken" <mdierken@...>
>
> From: "Seairth Jacobs" <seairth@...>
> >
> > 1) Response code
> > 2) Headers
> > 3) Entity-body (Message-body)
> >
> > So, which of the above is actually part of the representation of a
> > resource?
> > Does this change based on the verb being used?  Does this change based
on
> > the response code being used?  Are some headers considered part of the
> > representation while others are not?
>
> I believe a client agent needs to understand all of them to understand
what
> is and is not the representation.
> For example, the Content-Type header is metadata /about/ the
representation.
> A status code tells you if the entity is even a representation or not. And
> so on.

This is also my current understanding, so I don't disagree with what you are
saying.  However, this view seems almost useless when talking about REST (at
least to me).  It seems to me that part of what makes REST effective is
that, given a particular RESTful system, we can all agree on what does and
does not constitute the representation of a resource (either sent or
received, for that matter).  However, with HTTP this is not very clear to
me.  I would think that the Message-body is always part of the
representation (when there is one).  But the headers seems to be less
well-defined.  For instance, would the "Location" header in a 201 response
be considered part of the representation?  As you suggest, Content-Type
would be about the respresentation.  Does that mean that it is not part of
the representation?

One thing that has suddenly occured to me is that I may be following a false
assumption here as well.  I assumed that in RESTful applications,
representations were *always* sent (in responses).  However, the more I
think about this, the more this doesn't make sense.  If I can send a request
that contains no representation (e.g. GET), then I should be able to receive
a response that has no presentation (201 maybe?).  This doesn't necessarily
help me understand what is part of a representation when one is sent, but
this changed view would at least allow me to avoid wondering about several
HTTP response codes for which there does not appear to be a representation.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2645
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-22 01:57:28
Subject:Re: [rest-discuss] newbie question (web service composition)
Message:

----- Original Message -----
From: "Jan Algermissen" <algermissen@...>

> > This requires the
> > server to support query terms, but that is really a trivial burden (some
> > sort of mapping - path or query based - will always have to be done
anyway)
> > and generating query-based URIs is lighter weight than parsing XML and
doing
> > a content based query.
>
> Hmm, this sounds as if there is a way to avoid having the client
understand the
> syntax of the answer ?

There are two aspects to the answers that are interesting - how you discover
the location of more chunks of the index, and the data of the index itself
(as viewed by the client).
If you have some xml that is a mapping of multiple words to documents, then
the client needs to know how to do local searches over that data - and so it
doesn't much matter if you also do local searches to find more chunks to
retrieve.
If you have some xml that is /only/ the list of documents that a single word
maps to - and the client knows what word it asked for - then you don't need
to have a mix of both 'list of documents' and 'additional maps of resources
and word ranges' - it simplifies the content structure.


> > Good example and good questions. What kind of data size do you expect to
> > encounter?
>
> This was actually a hypothetical example (you might think of a digital
library
> that would also offer things like 'view a list of all authors and their
publications').
> I am thinking at a very large scale where 'chunking' would definitely be a
neccessity.

>
> >  What kind of clients do you wish to interact with?
>
> Browsers (in which case I would return HTML) but also non-human clients
like
> other services for example.

Personally, I strongly believe that the resource models you end up with are
different for the 'visual web' and the 'automatable web'. It is easier to do
strong information architecture on the 'automatable web' approach -
hyperlinking .vs. client-aware query terms, chunking, etc. The 'visual web'
is a whole different ball game & existing browsers have lots of limitations
(no PUT, no DELETE, etc. unless you do scripting with client components like
MS's XMLHttpRequest).
I think that you probably could have a REST/HTTP layer for pure information
access and a UI/HTTP layer for browser and user experience concerns. Limited
deployments probably would optimize away the REST information layer and go
with straight SQL access - probably faster & more skill/tool support, but
not as scalable/shareable. Just my opinions though.










-----------------------------------------------------------------------------------
Post ID:2646
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-22 01:59:45
Subject:Re: [rest-discuss] newbie question (web service composition)
Message:

----- Original Message -----
From: "Jan Algermissen" <algermissen@...>

>
> > An alternate would be to use your example #1 and use named query
parameters
> > with the same value space (letters with a dash between).
>
> Do you mean exactly like in example #1:
>
> http:/foo.bar/archive/index?range=a-c
>
> So basically like search engines work ?
>
> I am losing the 'drill-down' effect that way, don't I ?

If the XML based index document used the very same URI as the constructed
ones, the server won't notice or care. The client will send the same
requests for various chunks.







-----------------------------------------------------------------------------------
Post ID:2647
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-22 02:03:02
Subject:Re: [rest-discuss] Where does the "representation" start?
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

>
> This is also my current understanding, so I don't disagree with what you
are saying.
Um, thanks.

> However, this view seems almost useless when talking about REST (at
> least to me).  It seems to me that part of what makes REST effective is
> that, given a particular RESTful system, we can all agree on what does and
> does not constitute the representation of a resource (either sent or
> received, for that matter).  However, with HTTP this is not very clear to
> me.  I would think that the Message-body is always part of the
> representation (when there is one).  But the headers seems to be less
> well-defined.  For instance, would the "Location" header in a 201 response
> be considered part of the representation?  As you suggest, Content-Type
> would be about the respresentation.  Does that mean that it is not part of
> the representation?
Yes - I believe it is not 'part' of the representation. I see a graph of
related nodes - the graph is the interesting information, one node is the
'representation'. The graph says a lot about the representation - like what
the syntax is, what the meaning is, what the encryption is, etc. Even if you
view metadata as 'part' of the data - there are metadata items about that
are purely about the request or response (success/failure, caching, etc.)
that are still very useful in dealing with the representation.

>






-----------------------------------------------------------------------------------
Post ID:2648
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-09-22 13:00:58
Subject:Re: [rest-discuss] Where does the "representation" start?
Message:

I think you're talking about control data in this thread.

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>
To: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Saturday, September 21, 2002 9:21 PM
Subject: Re: [rest-discuss] Where does the "representation" start?


> From: "S. Mike Dierken" <mdierken@...>
> >
> > From: "Seairth Jacobs" <seairth@...>
> > >
> > > 1) Response code
> > > 2) Headers
> > > 3) Entity-body (Message-body)
> > >
> > > So, which of the above is actually part of the representation of a
> > > resource?
> > > Does this change based on the verb being used?  Does this change based
> on
> > > the response code being used?  Are some headers considered part of the
> > > representation while others are not?
> >
> > I believe a client agent needs to understand all of them to understand
> what
> > is and is not the representation.
> > For example, the Content-Type header is metadata /about/ the
> representation.
> > A status code tells you if the entity is even a representation or not.
And
> > so on.
>
> This is also my current understanding, so I don't disagree with what you
are
> saying.  However, this view seems almost useless when talking about REST
(at
> least to me).  It seems to me that part of what makes REST effective is
> that, given a particular RESTful system, we can all agree on what does and
> does not constitute the representation of a resource (either sent or
> received, for that matter).  However, with HTTP this is not very clear to
> me.  I would think that the Message-body is always part of the
> representation (when there is one).  But the headers seems to be less
> well-defined.  For instance, would the "Location" header in a 201 response
> be considered part of the representation?  As you suggest, Content-Type
> would be about the respresentation.  Does that mean that it is not part of
> the representation?
>
> One thing that has suddenly occured to me is that I may be following a
false
> assumption here as well.  I assumed that in RESTful applications,
> representations were *always* sent (in responses).  However, the more I
> think about this, the more this doesn't make sense.  If I can send a
request
> that contains no representation (e.g. GET), then I should be able to
receive
> a response that has no presentation (201 maybe?).  This doesn't
necessarily
> help me understand what is part of a representation when one is sent, but
> this changed view would at least allow me to avoid wondering about several
> HTTP response codes for which there does not appear to be a
representation.
>
> ---
> Seairth Jacobs
> seairth@...
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>








-----------------------------------------------------------------------------------
Post ID:2649
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-22 14:02:43
Subject:Re: [rest-discuss] Roy was right
Message:

Mathews, Walden wrote,
> However, Roy's language is about idempotent compositions, not HTTP
> methods in the specific, so I wanted to cover all bases and show
> where his logic may be coming from.

Err ... well in the context of RFC 2616, he's surely referring to 
compositions of idempotent _HTTP_ methods? What else would he be 
talking about in that RFC?

> The Alloy software is available from Daniel Jackson's MIT Software
> Design Group site: http://sdg.lcs.mit.edu/alloy/.  There is also a
> yahoo group for it called "alloy-discuss".

Many thanks for the pointer ... hmm, actually, I think you sent me that 
once before. Sorry.

> Yes, the model can be changed to correctly show the constraints on
> GET, PUT and DELETE, and I believe once again that your proof will
> hold rather trivially, but who knows.

Fancy giving it a go?

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2650
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-22 14:22:52
Subject:RE: [rest-discuss] Roy was right
Message:

Miles,

You're absolutely right about GET, PUT and DELETE beyind constrained
far beyond the constraints of mere idempotence.  PUT and DELETE are both
functions whose ranges consists of a single element.  The range of DELETE is
the "unmapped" resource, while the range of the function PUTX, where 'X' is
designated end-state, is obviously just X.  And GET is just an identity:
GET(x)=x (in the side-effect sense).  These relations don't even require the
term f(f(x)) to describe them.

The very notion of "sequences of idempotent functions" is peculiar because
it is void of any idempotence test cases.  In other words, to construct a
"sequence" like g(f) you rule out f(f).

Certainly we can rework the model to correctly represent the behaviors of
GET, PUT and DELETE.  When we do, I'm predicting that your assumption and
proof will be reinforced.  But I thought it would be interesting to show how
compositions on idempotent functions worked in the abstract.  At least we
have some idea of where Roy was coming from.

In other words, the spec addresses idempotence as a property of interest to
clients.  Extension to HTTP may want to include other idempotent methods
which are less constrained than the present ones, and for which Roy's caveat
would apply.

Alloy is available to the public at http://sdg.lcs.mit.edu/alloy/, and
there's also a yahoo group for it: alloy-discuss.

Walden



-----Original Message-----
From: Miles Sabin
To: rest-discuss@yahoogroups.com
Sent: 9/21/2002 2:14 AM
Subject: Re: [rest-discuss] Roy was right

Walden Mathews wrote,
> Ok, you'll find attached the pdf file generated by Alloy.  The
> functions f, g and h are all idempotent: they satisfy the constraint
>
>     fun(fun(x)) = fun(x) for all x mapped by fun (plug f, g and h in
> for 'fun')
>
> The analyzer was asked to generate a counterexample to the claim that
> there is no x such that f(g(h(f(g(h(x))))))) = f(g(h(x))), and it
> found one.  The reason it's not intuitive is that we need at least 6
> nodes for this condition to occur.

Fascinating! Good stuff ...

That said, this doesn't actually settle the issue. The problem is that 
GET, PUT and DELETE are more constrained than f, g and h in your model. 
For example, a function modelling GET should never generate a state 
transition ... and all of the fn's in your counter-example violate that 
constraint.

PUT and DELETE are, I think, also more constrained, in that,

  PUT /foo
  DELETE /foo

is equivalent to,

  DELETE /foo

and,

  DELETE /foo
  PUT /foo

is equivalent to,

  PUT /foo

and again, all of the fn's in your counter-example violate those 
constraints too.

All three of these constraints played an essential role in my proof, so 
it'd help either if you could produce a new model which respects them, 
or if we could provide a rationale for why it's OK to violate them.

BTW, is Alloy publicly available? Having seen the results I'd be 
interested in playing with it.

Cheers,


Miles


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2651
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-22 14:28:01
Subject:RE: [rest-discuss] Idempotence
Message:

Mike,

Yeah, it would be like saying that the Interstate highway system is the
"engine" of domestic ground travel, in which case What's that whirring noise
coming from under my hood? ;-)

"Engine" has a broader meaning that means "means"; know what I mean?

The thing that my group was "getting" was the idea that every useful state
is just an explicit link from wherever we are now, and how beautiful it is
when the client doesn't have to try to invent meaningful states and then
gamble on their validity in the system.

Walden

-----Original Message-----
From: S. Mike Dierken
To: rest-discuss@yahoogroups.com
Sent: 9/21/2002 1:52 AM
Subject: Re: [rest-discuss] Idempotence


----- Original Message -----
From: "waldenmathews" <waldenm@...>

> Several of them had epiphanies today
> in which they discovered the meaning (and coolness) of "hypertext
> as the engine of application state".
Please explain - that part I just don't understand... examples work for
me...
How can 'hypertext' (which seems static) and 'engine' (which seems
dynamic)
be connected?




To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2652
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-22 23:53:08
Subject:Re: [rest-discuss] Roy was right
Message:

> Miles Sabin wrote,
> > Mathews, Walden wrote,
> > However, Roy's language is about idempotent compositions, not HTTP
> > methods in the specific, so I wanted to cover all bases and show
> > where his logic may be coming from.
> 
> Err ... well in the context of RFC 2616, he's surely referring to 
> compositions of idempotent _HTTP_ methods? What else would he be 
> talking about in that RFC?

Since HTTP is extensible, I'm sure the definition was intended to be 
carried though to any other conceivable methods.

Still, the original authors seem to have even the basic HTTP/1.1 
methods in mind when the wording was included.  

This appears to be one of the original messages in which the difference 
in the definition of "Idempotent Methods" between RFC2616 and RFC2068 
was first proposed (by Jeffrey Mogul, one of the authors):

http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997MayAug/0704.html

- Winter







-----------------------------------------------------------------------------------
Post ID:2653
Sender:"waldenmathews" <waldenm@...>
Post Date/Time:2002-09-23 01:19:35
Subject:Re: Roy was right
Message:

Winter,

Ah, transactions.  So that's what those rascals were up to!  Well, 
that explains everything.  So much for my model; I was way off in the 
weeds.  I wish they would have said

"a sequence of idempotent invocations on multiple resources will not 
necessarily be idempotent over the collective state of those 
resources"

or something like that.

Anyhow, I'm on a modelling roll now if anyone cares to submit a 
challenging case for analysis.

Walden

--- In rest-discuss@y..., "Jeffrey Winter" <j.winter@n...> wrote:
> > Miles Sabin wrote,
> > > Mathews, Walden wrote,
> > > However, Roy's language is about idempotent compositions, not 
HTTP
> > > methods in the specific, so I wanted to cover all bases and show
> > > where his logic may be coming from.
> > 
> > Err ... well in the context of RFC 2616, he's surely referring to 
> > compositions of idempotent _HTTP_ methods? What else would he be 
> > talking about in that RFC?
> 
> Since HTTP is extensible, I'm sure the definition was intended to 
be 
> carried though to any other conceivable methods.
> 
> Still, the original authors seem to have even the basic HTTP/1.1 
> methods in mind when the wording was included.  
> 
> This appears to be one of the original messages in which the 
difference 
> in the definition of "Idempotent Methods" between RFC2616 and 
RFC2068 
> was first proposed (by Jeffrey Mogul, one of the authors):
> 
> http://lists.w3.org/Archives/Public/ietf-http-wg-
old/1997MayAug/0704.html
> 
> - Winter







-----------------------------------------------------------------------------------
Post ID:2654
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-23 05:37:23
Subject:Re: [rest-discuss] Idempotence
Message:

----- Original Message -----
From: "Mathews, Walden" <waldenm@...>

>
> Yeah, it would be like saying that the Interstate highway system is the
> "engine" of domestic ground travel, in which case What's that whirring
noise
> coming from under my hood? ;-)
>
> "Engine" has a broader meaning that means "means"; know what I mean?
Sort of... I'm being dense just know.

>
> The thing that my group was "getting" was the idea that every useful state
> is just an explicit link from wherever we are now,
What do you mean by 'state'? I'm thinking in terms of client, server and
server-based data. It sounds like you are using 'state' as in state
transition... maybe that's a viewpoint that I haven't tried yet.

> and how beautiful it is
> when the client doesn't have to try to invent meaningful states and then
> gamble on their validity in the system.
>
> Walden
>
> -----Original Message-----
> From: S. Mike Dierken
> To: rest-discuss@yahoogroups.com
> Sent: 9/21/2002 1:52 AM
> Subject: Re: [rest-discuss] Idempotence
>
>
> ----- Original Message -----
> From: "waldenmathews" <waldenm@...>
>
> > Several of them had epiphanies today
> > in which they discovered the meaning (and coolness) of "hypertext
> > as the engine of application state".
> Please explain - that part I just don't understand... examples work for
> me...
> How can 'hypertext' (which seems static) and 'engine' (which seems
> dynamic)
> be connected?
>
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>






-----------------------------------------------------------------------------------
Post ID:2655
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-09-23 06:00:28
Subject:Re: [rest-discuss] Roy was right
Message:

Jeffrey Winter wrote,
> This appears to be one of the original messages in which the
> difference in the definition of "Idempotent Methods" between RFC2616
> and RFC2068 was first proposed (by Jeffrey Mogul, one of the
> authors):
>
> http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997MayAug/0704.
> html

Ahh ... thanks for that. This rings a bell from the last time I dug into 
this.

OK, it's easy to see from the example in that message where the 
assumptions underlying my proof don't match,

  Step 1: x := RA.GET();
  Step 2: RC.PUT(x);
  Step 3: y := RB.GET();
  Step 4: RA.PUT(y);

  Step 5: x := RA.GET();
  Step 6: RC.PUT(x);
  Step 7: y := RB.GET();
  Step 8: RA.PUT(y);

Clearly the PUT entity in (2) is different from the PUT entity in (6), 
which is a possibility I explicitly ruled out.

I guess my big question now is: does allowing the PUT entity to vary 
from invocation to invocation in this way leave us with a coherent 
notion of idempotence? I obviously isn't intended to be "invoking the 
same method with the same args more than once has the same effect as 
invoking it exactly once". So what is it really intended to be?

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2656
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-23 13:48:11
Subject:RE: [rest-discuss] Idempotence
Message:

> It sounds like you are using 'state' as in state
> transition... maybe that's a viewpoint that I haven't tried yet.

Yes, hypertext as the *means* of transition among the legal
states of the application.

Walden







-----------------------------------------------------------------------------------
Post ID:2657
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-09-23 13:57:01
Subject:RE: [rest-discuss] Idempotence
Message:

> > It sounds like you are using 'state' as in state
> > transition... maybe that's a viewpoint that I haven't tried yet.
> 
> Yes, hypertext as the *means* of transition among the legal
> states of the application.

No, hypertext as the *engine*, because the link selections within the
representation drive the state transition. Word smithing, I know, but it's
important to grok how general the dynamic is.


Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.gooseworks.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2658
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-23 11:25:46
Subject:rest-explore
Message:

I wonder if we should move the more advanced conversations about the 
exact formal meanings of various methods to rest-explore so that 
rest-discuss can be more easily used by people trying to grasp the 
basics (the role of URIs, hypertext, statelessness, etc.). That can be a 
learning curve all by itself. And then there are all of the "how do I 
implement this in my environment" questions to consider.

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2659
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-23 16:53:47
Subject:Re: [rest-discuss] Idempotence
Message:

----- Original Message -----
From: "Mathews, Walden" <waldenm@...>
>
> Yes, hypertext as the *means* of transition among the legal
> states of the application.
Are the resources identified by the URI the set of states of the
application?
Hmm... I view the application as distributed across both the client and the
server. Using a GET only provides information to the client (in terms of
side-effects) - and the client can decide what to do with it.
How does this translate into transitioning into a new state for the
application?

Color me still confused...






-----------------------------------------------------------------------------------
Post ID:2660
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-23 18:31:12
Subject:RE: [rest-discuss] Idempotence
Message:

> > Yes, hypertext as the *means* of transition among the legal
> > states of the application.
> Are the resources identified by the URI the set of states of the
> application?

More like states of the client, but Dr. Fielding has already
crafted the language that defines client state as being a function
of outstanding requests, etc.  I need not reword the concept.

> Hmm... I view the application as distributed across both the 
> client and the
> server. 

That's a reasonable scope.  In that case I don't think the "engine"
analogy is quite so clear, but I don't know that it is invalid
either.  Does the server change state other than when a link is
followed?  Certainly, but probably mostly outside the scope of web
architecture, like at startup or reconfig time.

I think if you overanalyze the language, you come to the dry
realization that following pointers is how applications change state,
and that URIs are pointers.  It doesn't mean we have to abandon
Neutonean physics just yet.

> Using a GET only provides information to the client 
> (in terms of
> side-effects) - and the client can decide what to do with it.

I don't understand this.  Don't we agree that GET is free of
side-effects?

> How does this translate into transitioning into a new state for the
> application?

Well, one of the things that characterizes states in a finite
state machine is the list of eligible states reachable from where
you are now.  In a well-designed web application, hyperlinks
correspond pretty well to that list, don't they?  And it's not
only about GET.  If I am looking at a recently gotten User document and it
has
a link associated with the text "close this user", and I POST
the right stuff to that URL, I just transitioned to a new client
state.

> 
> Color me still confused...
> 

Truly confused, or just pretending a little?

Walden






-----------------------------------------------------------------------------------
Post ID:2661
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-23 18:43:18
Subject:RE: [rest-discuss] rest-explore
Message:

If I do any more modelling work, I'll post it only to rest-explore
from now on.  I'm not sure if anyone will read it there, but I do
agree that it would be distracting for people trying to grasp the
basics.

Walden

> -----Original Message-----
> From: Paul Prescod [mailto:paul@...]
> Sent: Monday, September 23, 2002 7:26 AM
> To: rest-discuss@yahoogroups.com
> Subject: [rest-discuss] rest-explore
> 
> 
> I wonder if we should move the more advanced conversations about the 
> exact formal meanings of various methods to rest-explore so that 
> rest-discuss can be more easily used by people trying to grasp the 
> basics (the role of URIs, hypertext, statelessness, etc.). 
> That can be a 
> learning curve all by itself. And then there are all of the "how do I 
> implement this in my environment" questions to consider.
> 
>   Paul Prescod
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Plan to Sell a Home?
> http://us.click.yahoo.com/J2SnNA/y.lEAA/ySSFAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2662
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-23 18:48:07
Subject:RE: [rest-discuss] Idempotence
Message:

> > Yes, hypertext as the *means* of transition among the legal
> > states of the application.
> 
> No, hypertext as the *engine*, because the link selections within the
> representation drive the state transition. Word smithing, I 
> know, but it's
> important to grok how general the dynamic is.

The link *selections* (actions) drive the state transitions, not the
links themselves.  The engine *drives* the car; the highway does not
pull it along.  "Dereferencing of hypertext links" is the engine of
application state, taking the active interpretation of "engine".  Enough
wordsmithing.  It's not all that important, is it?

Walden






-----------------------------------------------------------------------------------
Post ID:2663
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-23 19:09:13
Subject:Re: [rest-discuss] rest-explore
Message:

Instead, why not start another list called "rest-basics" or "rest-learn"?  I
think "rest-discuss" should continue to be used as a place to discuss the
intricacies, conflicting views, etc. of REST.

---
Seairth Jacobs
seairth@...

----- Original Message -----
From: "Paul Prescod" <paul@...>
To: <rest-discuss@yahoogroups.com>
Sent: Monday, September 23, 2002 7:25 AM
Subject: [rest-discuss] rest-explore


> I wonder if we should move the more advanced conversations about the
> exact formal meanings of various methods to rest-explore so that
> rest-discuss can be more easily used by people trying to grasp the
> basics (the role of URIs, hypertext, statelessness, etc.). That can be a
> learning curve all by itself. And then there are all of the "how do I
> implement this in my environment" questions to consider.
>
>   Paul Prescod
>
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>







-----------------------------------------------------------------------------------
Post ID:2664
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-23 20:59:07
Subject:Re: [rest-discuss] Idempotence
Message:


>
> > Using a GET only provides information to the client
> > (in terms of
> > side-effects) - and the client can decide what to do with it.
>
> I don't understand this.  Don't we agree that GET is free of
> side-effects?
What I meant was that following links (where following == GET) doesn't
change server state. Following links can only provide information to a
client that would then change its own state. Each client could end in
different states even though the hypermedia and resource representations
were exactly the same for each.


> >
> > Color me still confused...
> >
>
> Truly confused, or just pretending a little?
>
The 'state machine' viewpoint of REST is very confusing to me. I understand
and like all the stuff about REST I've learned over the years, but this part
doesn't (yet) fit my pre-conceived notions. I'll keep noodling on it.








-----------------------------------------------------------------------------------
Post ID:2665
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-23 21:38:01
Subject:RE: [rest-discuss] Idempotence
Message:

> What I meant was that following links (where following == GET) doesn't
> change server state. Following links can only provide information to a
> client that would then change its own state. Each client could end in
> different states even though the hypermedia and resource 
> representations
> were exactly the same for each.

If we're splitting hairs, then one bit difference constitutes clients
in different states.  But do you feel that two clients as described
above could be in *significantly* different states having done the same
GET and received the same representation?  I think not.  It does seem
to depend, though, on what the client is caching along the way...Is
that your point?

Walden






-----------------------------------------------------------------------------------
Post ID:2666
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-23 21:53:19
Subject:Re: [rest-discuss] Idempotence
Message:

----- Original Message -----
From: "Mathews, Walden" <waldenm@...>



> > What I meant was that following links (where following == GET) doesn't
> > change server state. Following links can only provide information to a
> > client that would then change its own state. Each client could end in
> > different states even though the hypermedia and resource
> > representations
> > were exactly the same for each.
>
> If we're splitting hairs, then one bit difference constitutes clients
> in different states.  But do you feel that two clients as described
> above could be in *significantly* different states having done the same
> GET and received the same representation?  I think not.  It does seem
> to depend, though, on what the client is caching along the way...Is
> that your point?

No - I was thinking that one client was a text indexer (like a search
engine) and another was a visual browser. They both receive the same
content, but one just extracts words and associates them with the URI. The
other shows some UI and stuff.

I still don't get the 'state machine' viewpoint. Not a big deal.







-----------------------------------------------------------------------------------
Post ID:2667
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-09-24 00:56:58
Subject:Re: [rest-discuss] Idempotence
Message:

S. Mike Dierken wrote:
> 
>...
> 
> The 'state machine' viewpoint of REST is very confusing to me. I understand
> and like all the stuff about REST I've learned over the years, but this part
> doesn't (yet) fit my pre-conceived notions. I'll keep noodling on it.

I'm not going to jump in full-bore, but in case you haven't seen it, 
I've written a little about this that may or may not be helpful:

http://www.prescod.net/rest/state_transition.html

If not, sorry!

  Paul








-----------------------------------------------------------------------------------
Post ID:2668
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-24 01:51:09
Subject:Re: [rest-discuss] Idempotence
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> I'm not going to jump in full-bore, but in case you haven't seen it,
> I've written a little about this that may or may not be helpful:
>
> http://www.prescod.net/rest/state_transition.html
>
Ahh.... many thanks Paul - you are always a help.

"The current state of a conversation should be represented by a resource
addressable by a URI" - this part I can grasp.
I'll pretend 'state machine' relates to the states of a 'coordinating
protocol' that two entities are using to dance together. Not a perfect
analogy, but it gets my frame of mind headed in the right direction.

This to me is a layer above REST, as opposed to REST itself - but that's
okay. I like working out the coordination issues and I think this view of
applying REST will be very useful.






-----------------------------------------------------------------------------------
Post ID:2669
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-09-24 09:03:45
Subject:Hypertext conversations (was Re: Idempotence)
Message:

--- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote:
> "The current state of a conversation should be represented by a 
resource
> addressable by a URI" - this part I can grasp.
> I'll pretend 'state machine' relates to the states of 
a 'coordinating
> protocol' that two entities are using to dance together. Not a 
perfect
> analogy, but it gets my frame of mind headed in the right direction.
> 
> This to me is a layer above REST, as opposed to REST itself - but 
that's
> okay. I like working out the coordination issues and I think this 
view of
> applying REST will be very useful.

I started thinking about this question from the midst of 
a "choreography" project.
Even when I started to grasp what Paul was talking about, I still 
made it more complicated than it needed to be.

Here's an example of my current state of understanding, which 
probably still has a ways to go.  The following is the outline of a 
conversation in hypertext. (Note, there's nothing special about this 
thread vs this topic, it was just a random selection.)

http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0173.html

RE: arch diagrams from the f2f
From: Heather Kreger
Date: Mon, Sep 23 2002 

Next message: Heather Kreger: "Re: XML and SOAP constraints? (was RE: 
WSA constraints)" 
http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0174.html

Previous message: Ugo Corda: "RE: Reliable Messaging Definition" 
http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0172.html

Maybe in reply to: Heather Kreger: "arch diagrams from the f2f" 
http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0052.html

Next in thread: Anne Thomas Manes: "RE: arch diagrams from the f2f" 
http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0180.html

Reply: Anne Thomas Manes: "RE: arch diagrams from the f2f" 
http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0180.html

etc.

Note that the threads would not need to be all on the same site.
Webloggers do this all the time: spin a conversation from one blog to 
another and back and forth.  Each speech act contains a hyperlink to 
its referent.  Somebody may collect the whole thread.  Jon Schull and 
Jon Udell even did some diagrams of bloghopping threads.

Business conversations could follow the same idea, using Paul's 
hyperlink + hash format.

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:2670
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-24 14:48:46
Subject:RE: [rest-discuss] Re: Resources always exist
Message:

> I'm seeing two viewpoints of what an 'http request' is and 
> they each have
> different expectations.
> The first is 'please perform this operation upon this resource' - so a
> DELETE on a non-existent resource fails.
> The second is 'please make it such that the resource does not 
> exist' - so a
> DELETE on a non-existent resource is a 'duh - okay' response.
> 
> The first is more of a procedural point of view, and the 
> second is more of a
> declarative/logical assertion point of view. I don't know if 
> that makes any
> sense, but I hope the HTTP philosophy isn't the declarative/logical
> assertion approach, since 0.001% of programmers would get it.

I think a few more than that would "get it", but I understand
your point nonetheless.

Sometimes the programmer doesn't matter as much as the customer.
On my current project, we have an issue that's right on this
same point.  Our customer wants to "update portfolios".  Up until
now we've assumed, because the implementation details include
the storing of incremental transaction data for audit, that
the end-user is thinking this way too, but recent evidence seems
to suggest that they always think "declaratively" about their
portfolios.  An example, the broker is allowed to run one chart
window, but branch management has decided that brokers would be
happier running the maximum product capability of four chart
windows.  Four is the target; four is the meaningful number in
the problem domain; "plus 3" is the language of the application.
The programmers and programing management likes "plus 3"; they
don't want to change...

There's a problem with "plus 3"; in order to get every broker's
config up to four, we need to know in a time-sensitive manner
each broker's current config.  This places a high burden on the
freshness of the caches.  If we order "plus 3" for a broker who
was participating in a prototype and already has four, we're
making an illegal request.  We might spend extra bandwidth to
refresh caches of all affected accounts in order to stick with
this non-idempotent method of portfolio update; or we might go
with the natural format that matches the way portfolio coordinators
and management think and use the declarative (idempotent) method
instead.

Based on bandwidth constraints alone, a development management
who refused to listen to "idempotent" in the abstract must now
pay attention and entertain the necessity of this change.

That's what's been happening in our little world.  If programmers
can't keep up with that kind of thinking, their futures are a bit
dark from where I sit.  It ain't rocket science either...

Peace,
Walden






-----------------------------------------------------------------------------------
Post ID:2671
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-09-24 18:22:27
Subject:responses
Message:

Looking over 2616 and draft-baker-http-resource-state-model, I'm inclined
to believe that response entity-bodies can be classified in three ways;

* representations, in response to GETs
* status messages, attached to exceptional status codes (e.g., 201, 404,
etc.)
* results, in response to POSTs

Does this seem reasonable? I classify the response to a POST as a result,
not a representation, because my reading is that while a POST might affect
a resource's state, it does not return a representation of it; rather, it
returns the results of processing.

Thoughts?


--
Mark Nottingham







-----------------------------------------------------------------------------------
Post ID:2672
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-24 18:28:59
Subject:RE: [rest-discuss] responses
Message:

Elsewhere I've seen the distinction between

	representation[1] - a representation of the resource addressed 
		in the method invocation

	representation[2] - a representation of some other resource which
		may or may not have an identifier in the system yet.

A "result" may be one of the latter, if I recall.

Walden

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@...]
> Sent: Tuesday, September 24, 2002 2:22 PM
> To: rest-discuss@yahoogroups.com
> Subject: [rest-discuss] responses
> 
> 
> Looking over 2616 and draft-baker-http-resource-state-model, 
> I'm inclined
> to believe that response entity-bodies can be classified in 
> three ways;
> 
> * representations, in response to GETs
> * status messages, attached to exceptional status codes 
> (e.g., 201, 404,
> etc.)
> * results, in response to POSTs
> 
> Does this seem reasonable? I classify the response to a POST 
> as a result,
> not a representation, because my reading is that while a POST 
> might affect
> a resource's state, it does not return a representation of 
> it; rather, it
> returns the results of processing.
> 
> Thoughts?
> 
> 
> --
> Mark Nottingham
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Home Selling? Try Us!
> http://us.click.yahoo.com/QrPZMC/iTmEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
> 






-----------------------------------------------------------------------------------
Post ID:2673
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-24 18:35:34
Subject:Re: [rest-discuss] responses
Message:

Hi Mark,

On Tue, Sep 24, 2002 at 02:22:27PM -0400, Mark Nottingham wrote:
> Looking over 2616 and draft-baker-http-resource-state-model, I'm
> inclined
> to believe that response entity-bodies can be classified in three ways;
> 
> * representations, in response to GETs
> * status messages, attached to exceptional status codes (e.g., 201, 404,
> etc.)
> * results, in response to POSTs
> 
> Does this seem reasonable? I classify the response to a POST as a
> result,
> not a representation, because my reading is that while a POST might
> affect
> a resource's state, it does not return a representation of it; rather,
> it
> returns the results of processing.

I think it's reasonable to classify the response to a successful POST as
a representation of *a* resource, just not of *the* resource that the
POST was invoked on.

I believe that all data is a possible representation of some resource.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2674
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-09-24 18:38:27
Subject:Re: [rest-discuss] responses
Message:

Definately; I'm just trying to differentiate what kinds of responses
represent *that* resource's state. Would you agree that only responses to
GET do so?


----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "Mark Nottingham" <mnot@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Tuesday, September 24, 2002 11:35 AM
Subject: Re: [rest-discuss] responses


> Hi Mark,
>
> On Tue, Sep 24, 2002 at 02:22:27PM -0400, Mark Nottingham wrote:
> > Looking over 2616 and draft-baker-http-resource-state-model, I'm
> > inclined
> > to believe that response entity-bodies can be classified in three
ways;
> >
> > * representations, in response to GETs
> > * status messages, attached to exceptional status codes (e.g., 201,
404,
> > etc.)
> > * results, in response to POSTs
> >
> > Does this seem reasonable? I classify the response to a POST as a
> > result,
> > not a representation, because my reading is that while a POST might
> > affect
> > a resource's state, it does not return a representation of it; rather,
> > it
> > returns the results of processing.
>
> I think it's reasonable to classify the response to a successful POST as
> a representation of *a* resource, just not of *the* resource that the
> POST was invoked on.
>
> I believe that all data is a possible representation of some resource.
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
>







-----------------------------------------------------------------------------------
Post ID:2675
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-24 19:35:45
Subject:Re: [rest-discuss] responses
Message:

----- Original Message -----
From: "Mark Nottingham" <mnot@...>


> Looking over 2616 and draft-baker-http-resource-state-model, I'm inclined
> to believe that response entity-bodies can be classified in three ways;
>
> * representations, in response to GETs
> * status messages, attached to exceptional status codes (e.g., 201, 404,
> etc.)
> * results, in response to POSTs
>
> Does this seem reasonable? I classify the response to a POST as a result,
> not a representation, because my reading is that while a POST might affect
> a resource's state, it does not return a representation of it; rather, it
> returns the results of processing.
Very nice. If the response to a post does not identify via some header what
resource the entity body is a representation of, then I'd classify it as
'result' type of response.






-----------------------------------------------------------------------------------
Post ID:2676
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-24 19:35:45
Subject:Re: [rest-discuss] responses
Message:

----- Original Message -----
From: "Mark Nottingham" <mnot@...>


> Looking over 2616 and draft-baker-http-resource-state-model, I'm inclined
> to believe that response entity-bodies can be classified in three ways;
>
> * representations, in response to GETs
> * status messages, attached to exceptional status codes (e.g., 201, 404,
> etc.)
> * results, in response to POSTs
>
> Does this seem reasonable? I classify the response to a POST as a result,
> not a representation, because my reading is that while a POST might affect
> a resource's state, it does not return a representation of it; rather, it
> returns the results of processing.
Very nice. If the response to a post does not identify via some header what
resource the entity body is a representation of, then I'd classify it as
'result' type of response.






-----------------------------------------------------------------------------------
Post ID:2677
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-24 20:20:53
Subject:Re: [rest-discuss] responses
Message:

On Tue, Sep 24, 2002 at 11:38:27AM -0700, Mark Nottingham wrote:
> Definately; I'm just trying to differentiate what kinds of responses
> represent *that* resource's state. Would you agree that only responses to
> GET do so?

Well, turn it around.  That resource's state could be represented in
the response to a PUT or a POST of some other resource. 8-)

But the only way to *explicitly request* a representation of the state
is with GET, yes.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2678
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-09-24 20:25:05
Subject:DELETE semantics
Message:

I think we've danced around this before, but I forget where we ended up...

What are the semantics of DELETE regarding query strings. E.g., if I say

  DELETE /Bob?appendage=right_arm HTTP/1.1

Is Bob just practicing his writing skills, or are we all left scratching
our heads and saying, "Where'd Bob get to?"

I ask because of the somewhat tricky language in 2396, Section 3.4;
   The query component is a string of information to be interpreted by
   the resource.

Note, "to be interpreted by the resource."

--
Mark Nottingham







-----------------------------------------------------------------------------------
Post ID:2679
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-09-24 20:29:00
Subject:Re: [rest-discuss] responses
Message:

Hmm, just so we're crystal;

The only requests which will return a representation of the state of the
resource identified in the request-line will be GET; responses to other
methods may contain the state of other resources, but not the one so
identied.

Correct?


----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "Mark Nottingham" <mnot@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Tuesday, September 24, 2002 1:20 PM
Subject: Re: [rest-discuss] responses


> On Tue, Sep 24, 2002 at 11:38:27AM -0700, Mark Nottingham wrote:
> > Definately; I'm just trying to differentiate what kinds of responses
> > represent *that* resource's state. Would you agree that only responses
to
> > GET do so?
>
> Well, turn it around.  That resource's state could be represented in
> the response to a PUT or a POST of some other resource. 8-)
>
> But the only way to *explicitly request* a representation of the state
> is with GET, yes.
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
>







-----------------------------------------------------------------------------------
Post ID:2680
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-24 20:31:57
Subject:Re: [rest-discuss] rest-explore
Message:

Well, rest-discuss came first, so we didn't think to call it
"rest-newbies" (or whatever).  But today, most of the membership is
not REST experts, just people who want to learn more about REST.

I agree that we should move the more advanced topics to rest-explore.

May I remind you that I'm the administrator of this list ... Muhaha! 8-)

MB

On Mon, Sep 23, 2002 at 03:09:13PM -0400, Seairth Jacobs wrote:
> Instead, why not start another list called "rest-basics" or "rest-learn"?  I
> think "rest-discuss" should continue to be used as a place to discuss the
> intricacies, conflicting views, etc. of REST.

-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2681
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-24 20:40:21
Subject:Re: [rest-discuss] responses
Message:

On Tue, Sep 24, 2002 at 01:29:00PM -0700, Mark Nottingham wrote:
> Hmm, just so we're crystal;
> 
> The only requests which will return a representation of the state of the
> resource identified in the request-line will be GET; responses to other
> methods may contain the state of other resources, but not the one so
> identied.
> 
> Correct?

Almost.  The response to other methods may contain the state of any
resource, including the one identified by the URI; the key point is just
that there can be no expectation that the response will include the
representation of any particular resource, including the targetted
resource.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2682
Sender:"Lee Fife" <lee@...>
Post Date/Time:2002-09-24 21:02:00
Subject:Re: [rest-discuss] responses
Message:

I wonder about the suggestion that S. Mike made earlier today. Doesn't seem like this is required anywhere, but perhaps it's a best practice?

GET always returns representation of the resource you asked for.
Other methods may return a representation of some resource. If they are returning such a representation, then the corresponding resource *should* be identified by a header, presumably Content-Location. If that header isn't present, then ... what? You can use the status code and the meaning of the entity body has to be determined out of band?

-Lee
  ----- Original Message ----- 
  From: Mark Baker 
  To: Mark Nottingham 
  Cc: rest-discuss@yahoogroups.com 
  Sent: Tuesday, September 24, 2002 2:40 PM
  Subject: Re: [rest-discuss] responses


  On Tue, Sep 24, 2002 at 01:29:00PM -0700, Mark Nottingham wrote:
  > Hmm, just so we're crystal;
  > 
  > The only requests which will return a representation of the state of the
  > resource identified in the request-line will be GET; responses to other
  > methods may contain the state of other resources, but not the one so
  > identied.
  > 
  > Correct?

  Almost.  The response to other methods may contain the state of any
  resource, including the one identified by the URI; the key point is just
  that there can be no expectation that the response will include the
  representation of any particular resource, including the targetted
  resource.

  MB






-----------------------------------------------------------------------------------
Post ID:2683
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-24 21:46:21
Subject:RESTWiki
Message:

Anybody know what happened to RESTWiki.  It used to be here

    http://internet.conveyor.com/RESTwiki/

--Chuck







-----------------------------------------------------------------------------------
Post ID:2684
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-25 01:58:37
Subject:Re: [rest-discuss] DELETE semantics
Message:

----- Original Message -----
From: "Mark Nottingham" <mnot@...>

>
> I ask because of the somewhat tricky language in 2396, Section 3.4;
>    The query component is a string of information to be interpreted by
>    the resource.
>
> Note, "to be interpreted by the resource."
I'm pretty sure this means the whole string including query /identifies/ the
resource & the meaning & syntax is specific to the resource - but of course
a 'manager' or 'controller' may understand the format as well. It doesn't
imply identfying the resource and then passing just the query components to
it. The resource (or its 'manager') is free to use whatever wacky syntax it
wants.








-----------------------------------------------------------------------------------
Post ID:2685
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-25 02:00:13
Subject:Re: [rest-discuss] responses
Message:

----- Original Message ----- 
From: "Mark Nottingham" <mnot@...>


> Hmm, just so we're crystal;
> 
> The only requests which will return a representation of the state of the
> resource identified in the request-line will be GET; responses to other
> methods may contain the state of other resources, but not the one so
> identied.

a) but not [ever] the one so identied.
b) but not [necessarily] the one so identied.

I think b)






-----------------------------------------------------------------------------------
Post ID:2686
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-25 02:13:05
Subject:Re: [rest-discuss] RESTWiki
Message:

The machine was hacked, and had to have everything reinstalled on it.
I'm working on it.

On Tue, Sep 24, 2002 at 05:46:21PM -0400, Chuck Hinson wrote:
> Anybody know what happened to RESTWiki.  It used to be here
> 
>     http://internet.conveyor.com/RESTwiki/

-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2687
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-25 14:20:04
Subject:Re: [rest-discuss] DELETE semantics
Message:

On Tue, Sep 24, 2002 at 01:25:05PM -0700, Mark Nottingham wrote:
> I think we've danced around this before, but I forget where we ended up...
> 
> What are the semantics of DELETE regarding query strings. E.g., if I say
> 
>   DELETE /Bob?appendage=right_arm HTTP/1.1
> 
> Is Bob just practicing his writing skills, or are we all left scratching
> our heads and saying, "Where'd Bob get to?"
> 
> I ask because of the somewhat tricky language in 2396, Section 3.4;
>    The query component is a string of information to be interpreted by
>    the resource.
> 
> Note, "to be interpreted by the resource."

IMO, that's just unfortunate language.  As Roy said, DELETE means
roughly "remove any representations for this resource", so in that
case - if I understand your intent - it would probably remove any
pictures, or data, of/about his right arm.

In other words, query parameters don't matter.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2688
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-25 14:26:09
Subject:Re: [rest-discuss] responses
Message:

On Tue, Sep 24, 2002 at 03:02:00PM -0600, Lee Fife wrote:
> I wonder about the suggestion that S. Mike made earlier today. Doesn't seem like this is required anywhere, but perhaps it's a best practice?
> 
> GET always returns representation of the resource you asked for.
> Other methods may return a representation of some resource. If they are returning such a representation, then the corresponding resource *should* be identified by a header, presumably Content-Location.

Sounds good.

> If that header isn't present, then ... what? You can use the status code and the meaning of the entity body has to be determined out of band?

The meaning of the body should stand on its own, independant of whether
an identifier is provided or not.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2689
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-25 14:44:17
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

Mark,

Did this discussion ever go anywhere?

I agree with the points you had made, but the current reading of "Obligations"
here:

    http://www.w3.org/2001/tag/doc/get7#obligations

would indicate that some GET operation even with Google's counter would
be okay since the user agreed to those terms when obtaining a developer key.

Will this document be updated to reflect the issue you raised?

Thanks,

Jeff


----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "Jeffrey Winter" <j.winter@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Monday, September 09, 2002 12:18 PM
Subject: Re: [rest-discuss] GET: Shades of Grey


Yah, I'm following that too, and admit to being a bit puzzled by Dan's
response and the finding.  I think each request has to stand alone in
its status as state-changing or not, for all the reasons I gave.

I'll see how the discussion, if any, goes, before chiming in.  Dan's a
smart guy, so you better make sure your ducks are lined up before
challenging him. 8-)

MB

On Mon, Sep 09, 2002 at 12:02:14PM -0400, Jeffrey Winter wrote:
> Mark,
>
> I thought that I had the issue of Google allowing an strictly
> non-idempotent GET resolved in my mind, but a recent item on
> the tag list pointed out this:
>
>     http://www.w3.org/2001/tag/doc/get7#obligations
>
> I had been trying to argue - perhaps ineffectually - that the
> Developer's Key effects the notion of what "safety" means.
> The key is obtained through of an authorization relationship
> established in a way similar to that described in the "TAG Finding:
> URIs, Addressability, and the use of HTTP GET" document
> referenced above.
>
> I gave up on this line of reasoning because of your point
> about proxy cache refereshing.
>
> Do you think that your point effects the findings described
> in that TAG document?  Or do you not think that the way
> Google is setup falls under this notion of "obligation"?
>
> Thanks,
>
> - Jeff
>

--
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com







-----------------------------------------------------------------------------------
Post ID:2690
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-25 14:51:41
Subject:Re: [rest-discuss] DELETE semantics
Message:


Mark Baker wrote:

>On Tue, Sep 24, 2002 at 01:25:05PM -0700, Mark Nottingham wrote:
>
>>I think we've danced around this before, but I forget where we ended up...
>>
>>What are the semantics of DELETE regarding query strings. E.g., if I say
>>
>>  DELETE /Bob?appendage=right_arm HTTP/1.1
>>
>>Is Bob just practicing his writing skills, or are we all left scratching
>>our heads and saying, "Where'd Bob get to?"
>>
>>I ask because of the somewhat tricky language in 2396, Section 3.4;
>>   The query component is a string of information to be interpreted by
>>   the resource.
>>
>>Note, "to be interpreted by the resource."
>>
>
>IMO, that's just unfortunate language.  As Roy said, DELETE means
>roughly "remove any representations for this resource", so in that
>case - if I understand your intent - it would probably remove any
>pictures, or data, of/about his right arm.
>
>In other words, query parameters don't matter.
>
So, is it fair to say that for any URL x (that is, a URL of any form - 
qurey string or no), DELETE(x) deletes/removes/unmaps the same 
representation that GET(x) would have returned?

--Chuck









-----------------------------------------------------------------------------------
Post ID:2691
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-25 14:53:48
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

On Wed, Sep 25, 2002 at 10:44:17AM -0400, Jeffrey Winter wrote:
> Mark,
> 
> Did this discussion ever go anywhere?

Yah.  I misinterpreted what Dan was saying.  We were in agreement all
along.

> I agree with the points you had made, but the current reading of "Obligations"
> here:
> 
>     http://www.w3.org/2001/tag/doc/get7#obligations
> 
> would indicate that some GET operation even with Google's counter would
> be okay since the user agreed to those terms when obtaining a developer key.

Hmm, I don't read it that way.  Is it the part that says

"This is not to say that there are never any obligations related to following links"

that leads you to believe this?  FWIW, I had to do a double-take on
that, but the word "related" is quite key there, as the example
demonstrates.

> Will this document be updated to reflect the issue you raised?

The only issue I raised, that for some reason got lots of support, was
that a pay-per-use example would probably be helpful to people.  But I
doubt it's a high priority item with the TAG - nor do I think it's very
important.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2692
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-09-25 14:55:17
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

Could the contract (ie, the developer key) under which the GET operation
took place part of the resource that represents the session, much as in
Paul Prescod's session="/sessions/42" example at:

     http://www.prescod.net/rest/state_transition.html

Now I know why "42" -- the answer to any question! 

Might even be a RESTful community convention to make resource invariants
like contracts available here -- /42 would be as interesting as /etc !
(Topic map PSIs might be available at 42/PSIs for example.) 

Someone, I am sure, will let me know politely if I am breaking the
paradigm or not being RESTful.

> Mark,
> 
> Did this discussion ever go anywhere?
> 
> I agree with the points you had made, but the current reading of "Obligations"
> here:
> 
>     http://www.w3.org/2001/tag/doc/get7#obligations
> 
> would indicate that some GET operation even with Google's counter would
> be okay since the user agreed to those terms when obtaining a developer key.
> 
> Will this document be updated to reflect the issue you raised?
> 
> Thanks,
> 
> Jeff
> 
> 
> ----- Original Message -----
> From: "Mark Baker" <distobj@...>
> To: "Jeffrey Winter" <j.winter@...>
> Cc: <rest-discuss@yahoogroups.com>
> Sent: Monday, September 09, 2002 12:18 PM
> Subject: Re: [rest-discuss] GET: Shades of Grey
> 
> 
> Yah, I'm following that too, and admit to being a bit puzzled by Dan's
> response and the finding.  I think each request has to stand alone in
> its status as state-changing or not, for all the reasons I gave.
> 
> I'll see how the discussion, if any, goes, before chiming in.  Dan's a
> smart guy, so you better make sure your ducks are lined up before
> challenging him. 8-)
> 
> MB
> 
> On Mon, Sep 09, 2002 at 12:02:14PM -0400, Jeffrey Winter wrote:
> > Mark,
> >
> > I thought that I had the issue of Google allowing an strictly
> > non-idempotent GET resolved in my mind, but a recent item on
> > the tag list pointed out this:
> >
> >     http://www.w3.org/2001/tag/doc/get7#obligations
> >
> > I had been trying to argue - perhaps ineffectually - that the
> > Developer's Key effects the notion of what "safety" means.
> > The key is obtained through of an authorization relationship
> > established in a way similar to that described in the "TAG Finding:
> > URIs, Addressability, and the use of HTTP GET" document
> > referenced above.
> >
> > I gave up on this line of reasoning because of your point
> > about proxy cache refereshing.
> >
> > Do you think that your point effects the findings described
> > in that TAG document?  Or do you not think that the way
> > Google is setup falls under this notion of "obligation"?
> >
> > Thanks,
> >
> > - Jeff
> >
> 
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
> 
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.gooseworks.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2693
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-25 14:56:28
Subject:Re: [rest-discuss] DELETE semantics
Message:

On Wed, Sep 25, 2002 at 10:51:41AM -0400, Chuck Hinson wrote:
> So, is it fair to say that for any URL x (that is, a URL of any form - 
> qurey string or no), DELETE(x) deletes/removes/unmaps the same 
> representation that GET(x) would have returned?

As well as all the other representations it knows about, yes, I'd say
so.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2694
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-25 15:08:27
Subject:RE: [rest-discuss] DELETE semantics
Message:

I'm wondering about what assumptions would be safe with regard
to the containment of the query-string resource within the base
resource, or within other query-string resources.

A pure reading has us believe that "/Bob" and "/Bob?appendage=right_arm"
are each resources with no implied transitivity or implied anything.

So, if I "GET /Bob", the representation returned is likely as not to
include a picture of Bob's right arm, and so is the one returned from
"GET /Bob?appendage=right_arm", if that's what that URI means.

Next, I'll "DELETE /Bob?appendage=right_arm", GET that same resource
again to confirm that the picture is no longer mapped there.

Finally, I'll "GET /Bob" once more, and lo and behold he's still
symmetric!  Why?  Because nobody told the implementation to unmap
any representation stuff from "/Bob".  Did I assume wrong?

Walden

> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Wednesday, September 25, 2002 10:56 AM
> To: Chuck Hinson
> Cc: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] DELETE semantics
> 
> 
> On Wed, Sep 25, 2002 at 10:51:41AM -0400, Chuck Hinson wrote:
> > So, is it fair to say that for any URL x (that is, a URL of 
> any form - 
> > qurey string or no), DELETE(x) deletes/removes/unmaps the same 
> > representation that GET(x) would have returned?
> 
> As well as all the other representations it knows about, yes, I'd say
> so.
> 
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@...
> http://www.markbaker.ca        http://www.idokorro.com
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Sell a Home with Ease!
> http://us.click.yahoo.com/SrPZMC/kTmEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2695
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-25 15:22:44
Subject:Re: [rest-discuss] DELETE semantics
Message:


Mark Baker wrote:

>On Wed, Sep 25, 2002 at 10:51:41AM -0400, Chuck Hinson wrote:
>
>>So, is it fair to say that for any URL x (that is, a URL of any form - 
>>qurey string or no), DELETE(x) deletes/removes/unmaps the same 
>>representation that GET(x) would have returned?
>>
>
>As well as all the other representations it knows about, yes, I'd say
>so.
>
>MB
>
So in the case of resources with multiple representations, or resources 
that have query strings, does it make sense to constrain DELETE in the 
same way the Fielding says PUT is constrained (resources that have 
multiple representation should not support PUT).

I suspect that it probably isnt reasonable to require this constraint of 
DELETE, but I wonder if it wouldn't be a useful simplication is many cases.

Just thinking out loud...

--Chuck








-----------------------------------------------------------------------------------
Post ID:2696
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-09-25 16:48:03
Subject:Retraction, advice sought, code offered
Message:

Okay, despite pissing all over the idea of pipelined HTTP requests at 
some earlier point, I've come across a situation where this is 
absolutely necessary.  That is, a situation where it would be nice to 
do e.g.:

GET http://x/1?GET=http://y/2?GET=http://z/3

That is, a situation where it would be useful to pass the results of 
GETting z/3 as input to y/2 to be transformed, and then passing the 
results of that as input to x/1 and getting the result of that 
transformation.  And it's necessary to do this strictly via a URI, that 
is,

http://x/1?GET=http://y/2?GET=http://z/3

or somesuch is the name of this pipelined transformation result.  
Various folks around here have advocated this in the past, so I need 
some advice:  the above won't work since the ? delimited parts of the 
query string will be interpreted as separate parameters for x/1.  An 
alternative syntax for this might be:

http://x/1/GET=http://y/2/GET=http://z/3

...but it seems like getting e.g. Apache to do the right thing in this 
case might be tricky.  It's particularly difficult since any of the 
sub-URI may themselves have query strings --- the part I'm calling z/3 
in fact has a horrendously long query string of its own that shouldn't 
be interpreted by x or y (it's a bugzilla query, fyi.)  Anybody have 
any suggestions on how to set things up here?  Something to do with 
mod_rewrite?  Examples --- particularly Python code--- much appreciated.

jb

BTW --- A colleague up at work wrote a MoinMoin processor that allows 
you to embed dot code directly into a Wiki page and have it generate / 
render the described graph, if anybody's interested.  Also have a piece 
of Python code I wrote that turns wiki-style tables plus a "map" 
datastructure into a dot graph description...  if anybody's interested, 
give me a holler.  When we get the RESTWiki back up, we should install 
this stuff there --- tres useful.  We use our Wiki up at work to 
coordinate all development specification and planning activities, and a 
lot of this stuff is the trivial fruit of some work to integrate Wiki 
and bugzilla and automate various dev planning processes.







-----------------------------------------------------------------------------------
Post ID:2697
Sender:"Lee Fife" <lee@...>
Post Date/Time:2002-09-25 17:23:46
Subject:Re: [rest-discuss] DELETE semantics
Message:

I must have missed this -- resources w/ multiple representations shouldn't support PUT? So, I shouldn't have an image resource that uses content negotiation to decide whether to return SVG, JPG, PNG, etc. that also allows you to PUT a new SVG version of that image? The only way to update that image is to POST to a container/manager? And there's no way to DELETE the image?

that can't be right ...

-Lee
  ----- Original Message ----- 
  From: Chuck Hinson 
  So in the case of resources with multiple representations, or resources 
  that have query strings, does it make sense to constrain DELETE in the 
  same way the Fielding says PUT is constrained (resources that have 
  multiple representation should not support PUT).

  I suspect that it probably isnt reasonable to require this constraint of 
  DELETE, but I wonder if it wouldn't be a useful simplication is many cases.

  Just thinking out loud...

  --Chuck






-----------------------------------------------------------------------------------
Post ID:2698
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-25 17:28:34
Subject:RE: [rest-discuss] DELETE semantics
Message:

Why wouldn't there be a way to DELETE?

-----Original Message-----
From: Lee Fife [mailto:lee@...]
Sent: Wednesday, September 25, 2002 1:24 PM
To: rest-discuss@yahoogroups.com
Subject: Re: [rest-discuss] DELETE semantics


I must have missed this -- resources w/ multiple representations shouldn't
support PUT? So, I shouldn't have an image resource that uses content
negotiation to decide whether to return SVG, JPG, PNG, etc. that also allows
you to PUT a new SVG version of that image? The only way to update that
image is to POST to a container/manager? And there's no way to DELETE the
image?
 
that can't be right ...
 
-Lee

----- Original Message ----- 
From: Chuck Hinson <mailto:cmhinson@...>  
So in the case of resources with multiple representations, or resources 
that have query strings, does it make sense to constrain DELETE in the 
same way the Fielding says PUT is constrained (resources that have 
multiple representation should not support PUT).

I suspect that it probably isnt reasonable to require this constraint of 
DELETE, but I wonder if it wouldn't be a useful simplication is many cases.

Just thinking out loud...

--Chuck



Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=233217.2395914.3827946.2225242/D=egroupweb/S=17057010
14:HM/A=1227861/R=0/*http://ads.track-star.com/linker.ts?ts=1;2;312;3_2_11>

 
<http://us.adserver.yahoo.com/l?M=233217.2395914.3827946.2225242/D=egroupmai
l/S=:HM/A=1227861/rand=152150743> 	

To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 







-----------------------------------------------------------------------------------
Post ID:2699
Sender:"Lee Fife" <lee@...>
Post Date/Time:2002-09-25 17:33:49
Subject:Re: [rest-discuss] DELETE semantics
Message:

I'm just following up what Chuck said. It doesn't seem right to me.

Where does Fielding say this (no PUT for resources for multiple representations)? I don't recall seeing it ...

-Lee
  ----- Original Message ----- 
  From: Mathews, Walden 
  To: 'Lee Fife' ; rest-discuss@yahoogroups.com 
  Sent: Wednesday, September 25, 2002 11:28 AM
  Subject: RE: [rest-discuss] DELETE semantics


  Why wouldn't there be a way to DELETE?
    -----Original Message-----
    From: Lee Fife [mailto:lee@...]
    Sent: Wednesday, September 25, 2002 1:24 PM
    To: rest-discuss@yahoogroups.com
    Subject: Re: [rest-discuss] DELETE semantics


    I must have missed this -- resources w/ multiple representations shouldn't support PUT? So, I shouldn't have an image resource that uses content negotiation to decide whether to return SVG, JPG, PNG, etc. that also allows you to PUT a new SVG version of that image? The only way to update that image is to POST to a container/manager? And there's no way to DELETE the image?

    that can't be right ...

    -Lee
      ----- Original Message ----- 
      From: Chuck Hinson 
      So in the case of resources with multiple representations, or resources 
      that have query strings, does it make sense to constrain DELETE in the 
      same way the Fielding says PUT is constrained (resources that have 
      multiple representation should not support PUT).

      I suspect that it probably isnt reasonable to require this constraint of 
      DELETE, but I wonder if it wouldn't be a useful simplication is many cases.

      Just thinking out loud...

      --Chuck


          Yahoo! Groups Sponsor 
                ADVERTISEMENT
               
         
         

    To unsubscribe from this group, send an email to:
    rest-discuss-unsubscribe@yahoogroups.com



    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 






-----------------------------------------------------------------------------------
Post ID:2700
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-25 17:37:09
Subject:EBI vs. REST
Message:

I would like to apply REST principles to a problem that I am currently working
through, but the current requirements are pushing towards an EBI (i.e.,
event-based) solution.

The issue is that some read-only data is being generated that needs to be
pushed to one particular class of client in near real-time.  Some clients can
perform periodic queries against the server to obtain this data, these others
cannot.

One idea would be to use some peer-to-peer protocol such as BXXP to alert that
class of client that new information was available, perhaps supplying them
with the URL in the message; that client could then GET the representation
using HTTP.

Obviously there are all the attendant scalability issues with EBI, but I can't
see how to avoid it in this circumstance.

What does REST have to say about this class of problem?

Thanks,

Jeff








-----------------------------------------------------------------------------------
Post ID:2701
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-25 17:44:37
Subject:Re: [rest-discuss] GET: Shades of Grey
Message:

I guess I'll have to squint a little harder.  I read the entire line:

"This is not to say that there are never any obligations related to following
links; only that the obligations must be accepted some other way than
requesting to follow a link."

as saying that so long as you accepted the obligations (i.e., agreeing to the
count-down counter) some "safe" way, that the party you have accepted the
obligations from can
enforce those obligations (i.e., performing the count-down) with a GET.

Thanks again,  Jeff







-----------------------------------------------------------------------------------
Post ID:2702
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-25 17:49:49
Subject:RE: [rest-discuss] DELETE semantics
Message:

It's in one of the email archives; I'm not sure which one, but I think it
might be
for the uri list; it was posted a day or two on this list.  Maybe the poster
can
answer your question.  Sorry.
 
Walden

-----Original Message-----
From: Lee Fife [mailto:lee.fife@...]
Sent: Wednesday, September 25, 2002 1:34 PM
To: rest-discuss@yahoogroups.com
Cc: Mathews, Walden
Subject: Re: [rest-discuss] DELETE semantics


I'm just following up what Chuck said. It doesn't seem right to me.
 
Where does Fielding say this (no PUT for resources for multiple
representations)? I don't recall seeing it ...
 
-Lee

----- Original Message ----- 
From: Mathews, Walden <mailto:waldenm@...>  
To: 'Lee Fife' <mailto:lee@...>  ; rest-discuss@yahoogroups.com
<mailto:rest-discuss@yahoogroups.com>  
Sent: Wednesday, September 25, 2002 11:28 AM
Subject: RE: [rest-discuss] DELETE semantics

Why wouldn't there be a way to DELETE?

-----Original Message-----
From: Lee Fife [mailto:lee@...]
Sent: Wednesday, September 25, 2002 1:24 PM
To: rest-discuss@yahoogroups.com <mailto:rest-discuss@yahoogroups.com> 
Subject: Re: [rest-discuss] DELETE semantics


I must have missed this -- resources w/ multiple representations shouldn't
support PUT? So, I shouldn't have an image resource that uses content
negotiation to decide whether to return SVG, JPG, PNG, etc. that also allows
you to PUT a new SVG version of that image? The only way to update that
image is to POST to a container/manager? And there's no way to DELETE the
image?
 
that can't be right ...
 
-Lee

----- Original Message ----- 
From: Chuck  <mailto:cmhinson@...> Hinson 
So in the case of resources with multiple representations, or resources 
that have query strings, does it make sense to constrain DELETE in the 
same way the Fielding says PUT is constrained (resources that have 
multiple representation should not support PUT).

I suspect that it probably isnt reasonable to require this constraint of 
DELETE, but I wonder if it wouldn't be a useful simplication is many cases.

Just thinking out loud...

--Chuck



Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=233217.2395914.3827946.2225242/D=egroupweb/S=17057010
14:HM/A=1227861/R=0/*http://ads.track-star.com/linker.ts?ts=1;2;312;3_2_11>

 
<http://us.adserver.yahoo.com/l?M=233217.2395914.3827946.2225242/D=egroupmai
l/S=:HM/A=1227861/rand=152150743> 	

To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 







-----------------------------------------------------------------------------------
Post ID:2703
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-09-25 19:03:29
Subject:Re: [rest-discuss] Retraction, advice sought, code offered
Message:

On Wednesday, September 25, 2002, at 01:54  PM, John Fletcher wrote:

> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3

Ugh...  I was afraid that was how it was going to go.  Any other 
suggestions that preserve readibility but perhaps torture URI syntax / 
semantics a bit more? ;-)

jb








-----------------------------------------------------------------------------------
Post ID:2704
Sender:"Uday .S" <kumarudaya@...>
Post Date/Time:2002-09-23 21:22:51
Subject:Newbie: Any REST Implementations?
Message:

Hi,
  I am very new to REST and would like to know is there a Open Source REST implementation that i can look at it...

Thanks,
-Uday.








-----------------------------------------------------------------------------------
Post ID:2705
Sender:"John Fletcher" <john.fletcher@...>
Post Date/Time:2002-09-25 18:54:20
Subject:Re: [rest-discuss] Retraction, advice sought, code offered
Message:

----- Original Message ----- 
From: "Jeff Bone" <jbone@...>
To: <rest-discuss@yahoogroups.com>
Sent: Wednesday, September 25, 2002 5:48 PM
Subject: [rest-discuss] Retraction, advice sought, code offered


> 
> Okay, despite pissing all over the idea of pipelined HTTP requests at 
> some earlier point, I've come across a situation where this is 
> absolutely necessary.  That is, a situation where it would be nice to 
> do e.g.:
> 
> GET http://x/1?GET=http://y/2?GET=http://z/3
> 

<snipped>

Jeff

Isn't this just what URL-Encoding is for?

It's slightly more complex in that you need to "quote" the Nth URL in N layers of URL-Encoding. For example, your URL should be:

http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3


Regards

John Fletcher







-----------------------------------------------------------------------------------
Post ID:2706
Sender:Phil Eskelin <philip.eskelin@...>
Post Date/Time:2002-09-25 19:16:46
Subject:RE: [rest-discuss] Newbie: Any REST Implementations?
Message:

To use Uday's question as an opportunity to update everyone:

I am *still* working on the REST toolkit.  Since I last mentioned it, a lot
of progress has been made.  Currently, I am updating its use of Xerces-C
from 1.6 to 2.1.  When I have finally released it, which should be soon, I
will be sure to first mention it here.  Here are some features:

1. Class design includes CGeneral, CRequest, CResponse for messaging;
   CResource and CRepresentation for resources and representations;
   CContainer, CComponent, CConnector, CFilter and CNode as specialized
   resources.
2. Utility classes include implementation of thread pool, socket classes,
   multi-byte and XMLCh strings, URIs, lists, dictionaries, items, etc.
2. Extensible connector-based filtering through client- and server-based
   connector filters.
3. Design of environmental acquisition (e.g., python) and something
   I call "indirect traversal" which is a way to make URIs more dynamic in
   terms of how the server resolves them.
4. Object and resource factories for dynamic registry of factories that
   create specialized objects.
5. Very very primitive support for XML - the whole framework serializes
   itself based on a simple 10-line DTD that uses some core elements and
   attributes to define typing, scoping, naming, and containment.

Once I finally release a first version, I really look forward to moving onto
thinking about real-world examples like Paul's RESTmail idea, Bob's auction
idea, etc.

Thanks for being patient,
Philip

-----Original Message-----
From: Uday .S [mailto:kumarudaya@...]
Sent: Monday, September 23, 2002 5:23 PM
To: rest-discuss@yahoogroups.com
Subject: [rest-discuss] Newbie: Any REST Implementations?


Hi,
  I am very new to REST and would like to know is there a Open Source REST
implementation that i can look at it...

Thanks,
-Uday.

________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.






-----------------------------------------------------------------------------------
Post ID:2707
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-09-25 19:19:36
Subject:Re: [rest-discuss] DELETE semantics
Message:

I posted a few links [1] to the uri list a few days ago which were part 
of a thread that talked about resources and resource containment.  The 
third link [2] in particular implie no PUT for resources with multiple 
representation, though  I would suggest reading the entire thread for 
better context.

[1] http://groups.yahoo.com/group/rest-discuss/message/2620
[2] http://lists.w3.org/Archives/Public/uri/2002Sep/0028.html

--Chuck

Mathews, Walden wrote:

> It's in one of the email archives; I'm not sure which one, but I think 
> it might be
>
> for the uri list; it was posted a day or two on this list.  Maybe the 
> poster can
>
> answer your question.  Sorry.
>
>  
>
> Walden
>
>     -----Original Message-----
>     *From:* Lee Fife [mailto:lee.fife@...]
>     *Sent:* Wednesday, September 25, 2002 1:34 PM
>     *To:* rest-discuss@yahoogroups.com
>     *Cc:* Mathews, Walden
>     *Subject:* Re: [rest-discuss] DELETE semantics
>
>     I'm just following up what Chuck said. It doesn't seem right to me.
>
>      
>
>     Where does Fielding say this (no PUT for resources for multiple
>     representations)? I don't recall seeing it ...
>
>      
>
>     -Lee
>
>         ----- Original Message -----
>
>         * From:* Mathews, Walden <mailto:waldenm@...>
>
>         * To:* 'Lee Fife' <mailto:lee@...> ;
>         rest-discuss@yahoogroups.com
>         <mailto:rest-discuss@yahoogroups.com>
>
>         * Sent:* Wednesday, September 25, 2002 11:28 AM
>
>         * Subject:* RE: [rest-discuss] DELETE semantics
>
>
>         Why wouldn't there be a way to DELETE?
>
>             -----Original Message-----
>             *From:* Lee Fife [mailto:lee@...]
>             *Sent:* Wednesday, September 25, 2002 1:24 PM
>             *To:* rest-discuss@yahoogroups.com
>             <mailto:rest-discuss@yahoogroups.com>
>             *Subject:* Re: [rest-discuss] DELETE semantics
>
>             I must have missed this -- resources w/ multiple
>             representations shouldn't support PUT? So, I shouldn't
>             have an image resource that uses content negotiation to
>             decide whether to return SVG, JPG, PNG, etc. that also
>             allows you to PUT a new SVG version of that image? The
>             only way to update that image is to POST to a
>             container/manager? And there's no way to DELETE the image?
>
>              
>
>             that can't be right ...
>
>              
>
>             -Lee
>
>                 ----- Original Message -----
>
>                 * From:* Chuck Hinson <mailto:cmhinson@...>
>
>                 So in the case of resources with multiple
>                 representations, or resources
>                 that have query strings, does it make sense to
>                 constrain DELETE in the
>                 same way the Fielding says PUT is constrained
>                 (resources that have
>                 multiple representation should not support PUT).
>
>                 I suspect that it probably isnt reasonable to require
>                 this constraint of
>                 DELETE, but I wonder if it wouldn't be a useful
>                 simplication is many cases.
>
>                 Just thinking out loud...
>
>                 --Chuck
>
>
>
>             To unsubscribe from this group, send an email to:
>             rest-discuss-unsubscribe@yahoogroups.com
>
>
>
>             Your use of Yahoo! Groups is subject to the Yahoo! Terms
>             of Service <http://docs.yahoo.com/info/terms/>.
>
>
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
> <http://rd.yahoo.com/M=229441.2397090.3822005.2225242/D=egroupweb/S=1705701014:HM/A=1189558/R=0/*http://www.bmgmusic.com/acq/ee/q6/enroll/mhn/9/> 
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service 
> <http://docs.yahoo.com/info/terms/>.







-----------------------------------------------------------------------------------
Post ID:2708
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-25 19:20:54
Subject:Re: [rest-discuss] EBI vs. REST
Message:

On Wed, Sep 25, 2002 at 01:37:09PM -0400, Jeffrey Winter wrote:
> I would like to apply REST principles to a problem that I am currently working
> through, but the current requirements are pushing towards an EBI (i.e.,
> event-based) solution.
> 
> The issue is that some read-only data is being generated that needs to be
> pushed to one particular class of client in near real-time.  Some clients can
> perform periodic queries against the server to obtain this data, these others
> cannot.
> 
> One idea would be to use some peer-to-peer protocol such as BXXP to alert that
> class of client that new information was available, perhaps supplying them
> with the URL in the message; that client could then GET the representation
> using HTTP.
> 
> Obviously there are all the attendant scalability issues with EBI, but I can't
> see how to avoid it in this circumstance.
> 
> What does REST have to say about this class of problem?

Roy's description of EBI in his dissertation was pretty interesting.
But I disagreed with it when he said;

"The event-based integration style, also known as the implicit
invocation or event system style, reduces coupling between components by
removing the need for identity on the connector interface."
-- http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_6_1

That's true, sort of.  Coupling is reduced, but not because identity
is removed from the connector interface - you still need to know the
identity of the "bus" 8-) - but because you don't need to know about
the identity of the publishers.

Anyhow, think of it that way; the bus/channel/topic as a resource.
Then visit http://developer.knownow.com. 8-)

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2709
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-25 19:55:48
Subject:RE: [rest-discuss] Retraction, advice sought, code offered
Message:

I object to your desire for URI readability; it implies that you
are planning to do something unsafe, like use a URI as though it
was a function call with parameters.

I see no reason why Jill shouldn't pull out her lipstick and her
PDA over a candle-lit dinner with John and using the lipstick, write
the following URI on her dinner napkin and then hand that to John
knowing that neither will be in the mood to surf later, if the evening
goes according to expectations.

I hope that answers your question.

Walden

> -----Original Message-----
> From: Jeff Bone [mailto:jbone@...]
> Sent: Wednesday, September 25, 2002 3:03 PM
> To: John Fletcher
> Cc: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Retraction, advice sought, code offered
> 
> 
> 
> On Wednesday, September 25, 2002, at 01:54  PM, John Fletcher wrote:
> 
> > http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3
> 
> Ugh...  I was afraid that was how it was going to go.  Any other 
> suggestions that preserve readibility but perhaps torture URI 
> syntax / 
> semantics a bit more? ;-)
> 
> jb
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2710
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-09-25 20:11:43
Subject:Re: [rest-discuss] Retraction, advice sought, code offered
Message:

On Wednesday, September 25, 2002, at 02:55  PM, Mathews, Walden wrote:

> I object to your desire for URI readability; it implies that you
> are planning to do something unsafe, like use a URI as though it
> was a function call with parameters.

See ---  THIS is exactly why I rant about URI opacity.  It leads the 
naively dogmatic to make statements like the above!  ;-)

> I see no reason why Jill shouldn't pull out her lipstick and her
> PDA over a candle-lit dinner with John and using the lipstick, write
> the following URI on her dinner napkin and then hand that to John
> knowing that neither will be in the mood to surf later, if the evening
> goes according to expectations.

But of course!  Now, if she can only remember that URI....  let's see, 
was that

>>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3

or

>>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%252A%253F%252Fz%252F3

of

>>> http://x/1?GET=http%2F%3A%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3

And if you say "but it's in her PDA," I'd say "well then, why doesn't 
she just beam it to John's PDA?"  If John doesn't have one, maybe Jill 
doesn't either...  now, where's my napkin?


jb







-----------------------------------------------------------------------------------
Post ID:2711
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-09-25 20:28:54
Subject:RE: [rest-discuss] Retraction, advice sought, code offered
Message:

John doesn't have a PDA, but if he keeps going out with Jill,
he probably will soon, because she sells them.  But that's another
matter.  Jill's PDA has a USB port, so she excuses herself, goes
to the ladies room and patches into the HP InkJet printer they
keep in there* (this Restaurant is not even in Zagats!), prints
the URL on her choice of paper (there are at least 4 trays!),
comes out and hands the paper to John, who is so impressed he
swallows his olive down the wrong pipe.  Jill can't remember the
Heimlich Manouver, but no worries, the URL to that is also filed
somewhere on her PDA...

* This is all done via a complex setup involving an SMC Barricade
firewall router -- you don't need to know the wiring details, do you?

Meanwhile, at a table in the corner all by himself sits Jeff, who
appears to have lost his napkin, of all things.

(heh)

Walden

> -----Original Message-----
> From: Jeff Bone [mailto:jbone@...]
> Sent: Wednesday, September 25, 2002 4:12 PM
> To: Mathews, Walden
> Cc: John Fletcher; rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Retraction, advice sought, code offered
> 
> 
> 
> On Wednesday, September 25, 2002, at 02:55  PM, Mathews, Walden wrote:
> 
> > I object to your desire for URI readability; it implies that you
> > are planning to do something unsafe, like use a URI as though it
> > was a function call with parameters.
> 
> See ---  THIS is exactly why I rant about URI opacity.  It leads the 
> naively dogmatic to make statements like the above!  ;-)
> 
> > I see no reason why Jill shouldn't pull out her lipstick and her
> > PDA over a candle-lit dinner with John and using the lipstick, write
> > the following URI on her dinner napkin and then hand that to John
> > knowing that neither will be in the mood to surf later, if 
> the evening
> > goes according to expectations.
> 
> But of course!  Now, if she can only remember that URI....  
> let's see, 
> was that
> 
> >>> 
http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3

or

>>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%252A%253F%252Fz%252F3

of

>>> http://x/1?GET=http%2F%3A%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3

And if you say "but it's in her PDA," I'd say "well then, why doesn't 
she just beam it to John's PDA?"  If John doesn't have one, maybe Jill 
doesn't either...  now, where's my napkin?


jb






-----------------------------------------------------------------------------------
Post ID:2712
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-25 20:33:36
Subject:Re: [rest-discuss] Retraction, advice sought, code offered
Message:

You'll have to parse the URL yourself, but why not break it up
using ";":

http://host1/res1/res2?parm1=x;host2/res1/res2?parm2=y;host3/x

- Winter

----- Original Message -----
From: "Jeff Bone" <jbone@...>
To: "Mathews, Walden" <waldenm@...>
Cc: "John Fletcher" <john.fletcher@...>;
<rest-discuss@yahoogroups.com>
Sent: Wednesday, September 25, 2002 4:11 PM
Subject: Re: [rest-discuss] Retraction, advice sought, code offered



On Wednesday, September 25, 2002, at 02:55  PM, Mathews, Walden wrote:

> I object to your desire for URI readability; it implies that you
> are planning to do something unsafe, like use a URI as though it
> was a function call with parameters.

See ---  THIS is exactly why I rant about URI opacity.  It leads the
naively dogmatic to make statements like the above!  ;-)

> I see no reason why Jill shouldn't pull out her lipstick and her
> PDA over a candle-lit dinner with John and using the lipstick, write
> the following URI on her dinner napkin and then hand that to John
> knowing that neither will be in the mood to surf later, if the evening
> goes according to expectations.

But of course!  Now, if she can only remember that URI....  let's see,
was that

>>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3

or

>>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%252A%253F%252Fz%252F3

of

>>> http://x/1?GET=http%2F%3A%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3

And if you say "but it's in her PDA," I'd say "well then, why doesn't
she just beam it to John's PDA?"  If John doesn't have one, maybe Jill
doesn't either...  now, where's my napkin?


jb



To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/









-----------------------------------------------------------------------------------
Post ID:2713
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-09-25 20:55:01
Subject:Re: [rest-discuss] Retraction, advice sought, code offered
Message:

That's fine.  My question was rather mundane:  assuming some arbitrary  
syntax / delimiter, does anybody have any existing Python / Apache or  
other gadgetry that does this?  I.e., if I just huck a standard Python  
CGI up on our Apache server, Apache is going to be "friendly" and  
flatten out all of the params to pass to the first resource in the  
pipeline, which will then have to reassemble them.  I guess that's  
trivial, though, isn't it?  Just ignore all the params and parse the  
URI directly.  Hmmm...

Just wanted to know if anybody done this kind of thing;  we discussed  
it a while back, but I wasn't sure if that was a mostly academic  
discussion.

jb


On Wednesday, September 25, 2002, at 03:33  PM, Jeffrey Winter wrote:

> You'll have to parse the URL yourself, but why not break it up
> using ";":
>
> http://host1/res1/res2?parm1=x;host2/res1/res2?parm2=y;host3/x
>
> - Winter
>
> ----- Original Message -----
> From: "Jeff Bone" <jbone@...>
> To: "Mathews, Walden" <waldenm@...>
> Cc: "John Fletcher" <john.fletcher@...>;
> <rest-discuss@yahoogroups.com>
> Sent: Wednesday, September 25, 2002 4:11 PM
> Subject: Re: [rest-discuss] Retraction, advice sought, code offered
>
>
>
> On Wednesday, September 25, 2002, at 02:55  PM, Mathews, Walden wrote:
>
>> I object to your desire for URI readability; it implies that you
>> are planning to do something unsafe, like use a URI as though it
>> was a function call with parameters.
>
> See ---  THIS is exactly why I rant about URI opacity.  It leads the
> naively dogmatic to make statements like the above!  ;-)
>
>> I see no reason why Jill shouldn't pull out her lipstick and her
>> PDA over a candle-lit dinner with John and using the lipstick, write
>> the following URI on her dinner napkin and then hand that to John
>> knowing that neither will be in the mood to surf later, if the evening
>> goes according to expectations.
>
> But of course!  Now, if she can only remember that URI....  let's see,
> was that
>
>>>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3
>
> or
>
>>>> http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%252A%253F%252Fz%252F3
>
> of
>
>>>> http://x/1?GET=http%2F%3A%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3
>
> And if you say "but it's in her PDA," I'd say "well then, why doesn't
> she just beam it to John's PDA?"  If John doesn't have one, maybe Jill
> doesn't either...  now, where's my napkin?
>
>
> jb
>
>
> ------------------------ Yahoo! Groups Sponsor  
> ---------------------~-->
> Home Selling? Try Us!
> http://us.click.yahoo.com/QrPZMC/iTmEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------------- 
> ~->
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to  
> http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:2714
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-25 21:10:20
Subject:Re: [rest-discuss] EBI vs. REST
Message:

----- Original Message -----
From: "Jeffrey Winter" <j.winter@...>

>
> The issue is that some read-only data is being generated that needs to be
> pushed to one particular class of client in near real-time.  Some clients
can
> perform periodic queries against the server to obtain this data, these
others
> cannot.
>
> What does REST have to say about this class of problem?

Model the receiver as a set of resources, then update them as needed in
real-time.
Essentially, reverse the roles of client and server.
With HTTP, this means putting a port 80 listener on the client and handling
PUT or POST.
The resources don't have to be persisted to disk, or anything like that.

Remember - The Web works both ways.






-----------------------------------------------------------------------------------
Post ID:2715
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-25 21:27:03
Subject:Re: [rest-discuss] Newbie: Any REST Implementations?
Message:

----- Original Message -----
From: "Uday .S" <kumarudaya@...>


> Hi,
>   I am very new to REST and would like to know is there a Open Source REST
implementation that i can look at it...
>
REST is an approach to building large scale networked applications - it
isn't an app server, or code library or other implementation.
You can learn about the approach and build the concepts into whatever system
you are using - JMS, DCOM, SOAP, etc.- or you can build things with HTTP and
gear your designs to the concepts outlined by REST.
There are many ways to build with any of the many technologies available -
REST is just one way to approach solving problems.

Mike






-----------------------------------------------------------------------------------
Post ID:2716
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-09-26 13:06:09
Subject:Re: [rest-discuss] Retraction, advice sought, code offered
Message:

Assuming that you have control over all embedded URIs below (z/3 and y/2,
anyhow), how about reversing it like:

GET http://z/3?GET=http://y/2?GET=http://x/1

z/3 would return a 304 (Found) to:

Location: http://y/2?GET=http://x/1&results

which would return another 304 to:

Location: http://x/1?results

which would return your final response.

---
Seairth Jacobs
seairth@...


----- Original Message -----
From: "Jeff Bone" <jbone@...>
To: <rest-discuss@yahoogroups.com>
Sent: Wednesday, September 25, 2002 12:48 PM
Subject: [rest-discuss] Retraction, advice sought, code offered


>
> Okay, despite pissing all over the idea of pipelined HTTP requests at
> some earlier point, I've come across a situation where this is
> absolutely necessary.  That is, a situation where it would be nice to
> do e.g.:
>
> GET http://x/1?GET=http://y/2?GET=http://z/3
>
> That is, a situation where it would be useful to pass the results of
> GETting z/3 as input to y/2 to be transformed, and then passing the
> results of that as input to x/1 and getting the result of that
> transformation.  And it's necessary to do this strictly via a URI, that
> is,
>
> http://x/1?GET=http://y/2?GET=http://z/3
>
> or somesuch is the name of this pipelined transformation result.
> Various folks around here have advocated this in the past, so I need
> some advice:  the above won't work since the ? delimited parts of the
> query string will be interpreted as separate parameters for x/1.  An
> alternative syntax for this might be:
>
> http://x/1/GET=http://y/2/GET=http://z/3
>
> ...but it seems like getting e.g. Apache to do the right thing in this
> case might be tricky.  It's particularly difficult since any of the
> sub-URI may themselves have query strings --- the part I'm calling z/3
> in fact has a horrendously long query string of its own that shouldn't
> be interpreted by x or y (it's a bugzilla query, fyi.)  Anybody have
> any suggestions on how to set things up here?  Something to do with
> mod_rewrite?  Examples --- particularly Python code--- much appreciated.
>
> jb
>
> BTW --- A colleague up at work wrote a MoinMoin processor that allows
> you to embed dot code directly into a Wiki page and have it generate /
> render the described graph, if anybody's interested.  Also have a piece
> of Python code I wrote that turns wiki-style tables plus a "map"
> datastructure into a dot graph description...  if anybody's interested,
> give me a holler.  When we get the RESTWiki back up, we should install
> this stuff there --- tres useful.  We use our Wiki up at work to
> coordinate all development specification and planning activities, and a
> lot of this stuff is the trivial fruit of some work to integrate Wiki
> and bugzilla and automate various dev planning processes.
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>







-----------------------------------------------------------------------------------
Post ID:2717
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-09-26 18:47:06
Subject:Re: [rest-discuss] EBI vs. REST
Message:

> Model the receiver as a set of resources, then update them as needed in
> real-time. Essentially, reverse the roles of client and server.
> With HTTP, this means putting a port 80 listener on the client and handling
> PUT or POST.

I actually am considering this for aspects of the system that do not require
near real-time notification.  For the real-time stuff though my concern is
with
scalability.  As the number of clients grow, the publisher would end
up POSTing (synchronously) to large numbers of clients.  Even if I were
to spin up a bunch of threads to handle this, there could be an intolerable
lag waiting for responses.

I started to read some of the documentation on the KnowNow.com site, but
for some reason I haven't been able to connect to it for a while,  So
I may be missing something, but they seemed to indicate that they had
some mechanism for doing HTTP POST asynchronously, that is, without
waiting for a response.  If true, that seems like an abuse of HTTP. Why
not just choose a protocol that is built to be asynchronous?  I'd prefer
to stick will well supported standards-based tools if possible.

This seems like a class of problem not well suited for REST - the
client-server
aspect of it anyway; I'll still try to maintain a generic interface, etc.

- Jeff







-----------------------------------------------------------------------------------
Post ID:2718
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-09-26 19:12:46
Subject:Re: [rest-discuss] EBI vs. REST
Message:

On Thursday, Sep 26, 2002, at 19:47 Europe/Dublin, Jeffrey Winter wrote:
> I started to read some of the documentation on the KnowNow.com site, 
> but
> for some reason I haven't been able to connect to it for a while,  So
> I may be missing something, but they seemed to indicate that they had
> some mechanism for doing HTTP POST asynchronously, that is, without
> waiting for a response.  If true, that seems like an abuse of HTTP. Why
> not just choose a protocol that is built to be asynchronous?  I'd 
> prefer
> to stick will well supported standards-based tools if possible.

i have dreamt of a RESTful protocol built as a BEEP profile to handle 
situations like this which would just bloat HTTP.  i reckon BEEP is 
quite capable of just about any kind of 1 request-1 response, 1 
request-no response (async) or 1 request-n response cycle you can think 
of.  if only there were a perl module on cpan.

it allows you to distinguish between the client-server and 
initiator-listener dichotomies.  where in client-server normally the 
server is the listener and the client is the initiator, you could also 
have the opposite.  if you have a copy of 'BEEP: The Definitive Guide' 
(o'reilly), check out chapter 4, 'Exchanges'.

http://www.oreilly.com/catalog/beep

so e.g. a client could connect to your server (through NAT, firewalls, 
etc.; all you need is TCP) and you could start sending POST methods 
'back' to it.  i don't know if this is the best solution to your 
problem but you might want to explore further.  of course this is just 
ramblings on my part; total vapour rather than something you can pick 
up off the shelf and start writing code with.

http://www.beepcore.org/

the website leaves a lot to be desired (e.g. the news has no dates, 
it's just 'there') but you should be able to at least pull RFC3080.

regards,
-vincent







-----------------------------------------------------------------------------------
Post ID:2719
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-26 20:06:20
Subject:RESTwiki, limping along
Message:

The RESTwiki is mostly up, but for some reason the main page is
"crashing".

Could anybody debug it for me?  I have no idea how to decypher what
appears here;

http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage

I reinstalled a new version of MoinMoin, and of Python.  Perhaps that
has something to do with the problems?

Follow-ups to me.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2720
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-26 22:35:13
Subject:Re: [rest-discuss] EBI vs. REST
Message:

----- Original Message -----
From: "Jeffrey Winter" <j.winter@...>
To: "S. Mike Dierken" <mdierken@...>; <rest-discuss@yahoogroups.com>
Sent: Thursday, September 26, 2002 11:47 AM
Subject: Re: [rest-discuss] EBI vs. REST


> > Model the receiver as a set of resources, then update them as needed in
> > real-time. Essentially, reverse the roles of client and server.
> > With HTTP, this means putting a port 80 listener on the client and
handling
> > PUT or POST.
>
> I actually am considering this for aspects of the system that do not
require
> near real-time notification.  For the real-time stuff though my concern is
> with
> scalability.  As the number of clients grow, the publisher would end
> up POSTing (synchronously) to large numbers of clients.  Even if I were
> to spin up a bunch of threads to handle this, there could be an
intolerable
> lag waiting for responses.
The POST to multiple clients can happen on one thread if you build it right.
You just need asynch IO.
You POST to client 1, then POST to client 2, etc. then check for response
from client 1 - process it if there, then go on to client 2, etc. With a
small thread pool, you could do this reasonably easy. With Java's new NIO,
you probably could do it in Java also.

Also, what about a cascade of machines?


> I started to read some of the documentation on the KnowNow.com site, but
> for some reason I haven't been able to connect to it for a while,  So
> I may be missing something, but they seemed to indicate that they had
> some mechanism for doing HTTP POST asynchronously, that is, without
> waiting for a response.  If true, that seems like an abuse of HTTP. Why
> not just choose a protocol that is built to be asynchronous?
Thats fine too - you don't lose any REST concepts, but you may have to build
up some HTTP concepts.

> I'd prefer to stick will well supported standards-based tools if possible.
>
> This seems like a class of problem not well suited for REST - the
> client-server
> aspect of it anyway; I'll still try to maintain a generic interface, etc.
REST works fine - HTTP may have issues.







-----------------------------------------------------------------------------------
Post ID:2721
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-26 23:17:20
Subject:Re: [rest-discuss] Retraction, advice sought, code offered
Message:

Could you do a two-phase approach, use a POST to create the chain and then a
GET to read from it?

----- Original Message -----
From: "Jeff Bone" <jbone@...>
To: "John Fletcher" <john.fletcher@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Wednesday, September 25, 2002 12:03 PM
Subject: Re: [rest-discuss] Retraction, advice sought, code offered


>
> On Wednesday, September 25, 2002, at 01:54  PM, John Fletcher wrote:
>
> > http://x/1?GET=http%3A%2F%2Fy%2F2%3FGET%3Dhttp%253A%252F%252Fz%252F3
>
> Ugh...  I was afraid that was how it was going to go.  Any other
> suggestions that preserve readibility but perhaps torture URI syntax /
> semantics a bit more? ;-)
>
> jb
>
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>






-----------------------------------------------------------------------------------
Post ID:2722
Sender:"Mathews, Walden" <walden.matthews@...>
Post Date/Time:2002-09-27 17:26:59
Subject:Re: code offered
Message:

Last week Jeff Bone posted:

[quote]
BTW --- A colleague up at work wrote a MoinMoin processor that allows 
you to embed dot code directly into a Wiki page and have it generate / 
render the described graph, if anybody's interested. Also have a piece 
of Python code I wrote that turns wiki-style tables plus a "map" 
datastructure into a dot graph description... if anybody's interested, 
give me a holler. When we get the RESTWiki back up, we should install 
this stuff there --- tres useful. We use our Wiki up at work to 
coordinate all development specification and planning activities, and a 
lot of this stuff is the trivial fruit of some work to integrate Wiki 
and bugzilla and automate various dev planning processes.
[quote]

Yes, very interested in the "dot code" processor.  I want to post my
Alloy models to the REST Wiki, showing graphs of certain instances of
the models.  Coincidentally, Alloy saves the info in "dot code", so
yes this would be very helpful.  Also helpful would be if someone knows
how to make the processor part of REST Wiki, 'cuz I sure as hell
don't.

BTW - thanks to Mark and whomever else helped fix REST Wiki.

Cheerio,

Walden

Walden Mathews
ILX Systems
111 Fulton St. 3rd Floor
New York, NY 10038
Phone (212) 510-3121
Fax (212) 520-3800






-----------------------------------------------------------------------------------
Post ID:2723
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-09-27 18:42:14
Subject:Re: [rest-discuss] moindot code
Message:

On Friday, September 27, 2002, at 12:26  PM, Mathews, Walden wrote:

> Yes, very interested in the "dot code" processor.  I want to post my
> Alloy models to the REST Wiki, showing graphs of certain instances of
> the models.  Coincidentally, Alloy saves the info in "dot code", so
> yes this would be very helpful.  Also helpful would be if someone knows
> how to make the processor part of REST Wiki, 'cuz I sure as hell
> don't.

Pj's moindot processor is available on the moinmoin processor market 
page, but it's a slightly outdated version that only allows one graph / 
page.  (You can set up multiple ones, but the last one is rendered for 
every separate graph description.  Oops. ;-)  The current version we're 
using doesn't have this limitation;  here it is in all its glory.  
Simply drop it into .../processor/moindot.py:

----
"""
     MoinDot - WebDot/MoinMoin collaboration macro

     Copyright (c) 2002 by Paul Jimenez <pj@...>

"""

import string, sys

def process(request, formatter, lines):
     webdoturl = "http://my.webdot.host/cgi-bin/webdot/"
     localdir = "/var/www/html/webdot/"
     localurl = "http://my.webdot.dir.url/webdot/"
     # parse bangpath for arguments
     # remove bang path
     args=string.split(lines[0])
     if len(args) > 1:
         dotfilename = "moindot-%s.dot" % args[1]
     else:
         dotfilename = "moindot.dot"

     dotfile = file(localdir+dotfilename,'w')

     del lines[0]
     for line in lines:
         dotfile.write(line)
         dotfile.write("\n")
     #dotfile.writelines(lines)
     dotfile.close()

     dotjpgurl = "%s%s%s.dot.jpg" % (webdoturl, localurl, dotfilename)

     sys.stdout.write("<IMG SRC=\""+dotjpgurl+"\">")

----

To use this, just include dot code in your wikitext as follows:

{{{#!moindot

...dot code goes here...

}}}

Couple of prerequisites:  you'll either need to set up the webdot stuff 
on the wiki (or other) host  OR use one of the open webdot renderers 
out on the net somewhere.  The webdoturl variable above should point at 
that host.  The localurl variable needs to contain the base / path for 
where the webdot renderer can retrieve the dot code to render --- 
that's a directory on the wikihost that should be set up.

Enjoy!

jb







-----------------------------------------------------------------------------------
Post ID:2724
Sender:"Mathews, Walden" <walden.matthews@...>
Post Date/Time:2002-09-27 18:47:49
Subject:RE: [rest-discuss] moindot code
Message:

Thanks Jeff!  I don't picture me simply dropping that into
anywhere it would make a difference.  Hopefully someone else
more empowered than I is reading this thread. 8-)

Walden

> -----Original Message-----
> From: Jeff Bone [mailto:jbone@...]
> Sent: Friday, September 27, 2002 2:42 PM
> To: Mathews, Walden
> Cc: 'rest-discuss@yahoogroups.com'
> Subject: Re: [rest-discuss] moindot code
> 
> 
> 
> On Friday, September 27, 2002, at 12:26  PM, Mathews, Walden wrote:
> 
> > Yes, very interested in the "dot code" processor.  I want to post my
> > Alloy models to the REST Wiki, showing graphs of certain 
> instances of
> > the models.  Coincidentally, Alloy saves the info in "dot code", so
> > yes this would be very helpful.  Also helpful would be if 
> someone knows
> > how to make the processor part of REST Wiki, 'cuz I sure as hell
> > don't.
> 
> Pj's moindot processor is available on the moinmoin processor market 
> page, but it's a slightly outdated version that only allows 
> one graph / 
> page.  (You can set up multiple ones, but the last one is 
> rendered for 
> every separate graph description.  Oops. ;-)  The current 
> version we're 
> using doesn't have this limitation;  here it is in all its glory.  
> Simply drop it into .../processor/moindot.py:
> 
> ----
> """
>      MoinDot - WebDot/MoinMoin collaboration macro
> 
>      Copyright (c) 2002 by Paul Jimenez <pj@...>
> 
> """
> 
> import string, sys
> 
> def process(request, formatter, lines):
>      webdoturl = "http://my.webdot.host/cgi-bin/webdot/"
>      localdir = "/var/www/html/webdot/"
>      localurl = "http://my.webdot.dir.url/webdot/"
>      # parse bangpath for arguments
>      # remove bang path
>      args=string.split(lines[0])
>      if len(args) > 1:
>          dotfilename = "moindot-%s.dot" % args[1]
>      else:
>          dotfilename = "moindot.dot"
> 
>      dotfile = file(localdir+dotfilename,'w')
> 
>      del lines[0]
>      for line in lines:
>          dotfile.write(line)
>          dotfile.write("\n")
>      #dotfile.writelines(lines)
>      dotfile.close()
> 
>      dotjpgurl = "%s%s%s.dot.jpg" % (webdoturl, localurl, dotfilename)
> 
>      sys.stdout.write("<IMG SRC=\""+dotjpgurl+"\">")
> 
> ----
> 
> To use this, just include dot code in your wikitext as follows:
> 
> {{{#!moindot
> 
> ...dot code goes here...
> 
> }}}
> 
> Couple of prerequisites:  you'll either need to set up the 
> webdot stuff 
> on the wiki (or other) host  OR use one of the open webdot renderers 
> out on the net somewhere.  The webdoturl variable above 
> should point at 
> that host.  The localurl variable needs to contain the base / 
> path for 
> where the webdot renderer can retrieve the dot code to render --- 
> that's a directory on the wikihost that should be set up.
> 
> Enjoy!
> 
> jb
> 






-----------------------------------------------------------------------------------
Post ID:2725
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-09-27 19:23:39
Subject:Re: [rest-discuss] EBI vs. REST
Message:

----- Original Message -----
From: "Vincent D Murphy" <vdm@...>

> so e.g. a client could connect to your server (through NAT, firewalls,
> etc.; all you need is TCP) and you could start sending POST methods
> 'back' to it.
There was some discussion a while back on this list about doing just this to
'send' to behind-the-firewall resources.
The connection is initiated by the protected machine, a 'protocol upgrade'
message is sent, and after that it is regular HTTP with the protected
machine playing the role of server. A simple form of tunnelling which does
not break HTTP in any way - other than intermediaries, which shouldn't be a
concern in this situation anyway (since the alternative is a custom
protocol).








-----------------------------------------------------------------------------------
Post ID:2726
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-09-27 19:20:47
Subject:RESTwiki update
Message:

On Fri, Sep 27, 2002 at 01:26:59PM -0400, Mathews, Walden wrote:
> BTW - thanks to Mark and whomever else helped fix REST Wiki.

It's not fixed yet.  There's that bizarre top line; I have no
idea where it's coming from.  But it at least appears to be
functional.

I tried downgrading MoinMoin versions from 1.0 to 0.11, but that
didn't fix it.  Perhaps I'll downgrade Python.  Blah.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2727
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-09-28 03:17:03
Subject:More moin-dot fun...
Message:

Not really REST per se, but interesting perhaps to RESTwiki users, 
MoinMoin users, and Python enthusiasts (of which this list has several.)

The following code takes a (moin) wiki table description and a python 
"map" data structure and generates a dot graph description.  It could 
very easily be used by a moin processor ala the pj's moindot processor, 
but I haven't gotten around to integrating the two yet.  (We've been 
doing a fork-lift database redesign over the last week, two weeks 
before customer ship --- eegads, where are the razor blades?!? If we 
can get this done, it'll be phenomenal -- think 1/5th Google (in terms 
of items for which metadata is stored) in a single appliance, but 
targeted at storage system management!  :-)

Enjoy, this is the "result" of a half-day of my week+ family "vacation" 
/ fishing trip last week! :-)

jb






-----------------------------------------------------------------------------------
Post ID:2728
Sender:"Mathews, Walden" <walden.matthews@...>
Post Date/Time:2002-09-28 05:03:31
Subject:RE: Http modeling
Message:

Hi,

Posting to both lists for better coverage.  If you're a "newbie" and you're
not interested in formal models, pass this by...

I've just created a page on the REST Wiki called "ResourceModel" in which I
present a complete (for now at least) structural model of URI, resources,
Representations and Variants in the Http resource space.  The model is
small, but 'checks out'.  Hopefully some discussion will ensue.

I probably shouldn't have said 'complete'.  You be the judge.  By the way,
the page would be improved by the inclusion of a picture of the "Shared"
function, using Jeff's "dotcode" miracle.

Cheerio,
Walden

PS - if you're interested in Alloy, check out
<alloy-discuss@yahoogroups.com> sister list.






-----------------------------------------------------------------------------------
Post ID:2729
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-10-01 01:40:07
Subject:RESTwiki fixed
Message:

Ah, finally.  Apparently Python has some backwards compatibility
issues.  MoinMoin 0.9 only works with Python 2.1, not 2.2.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2730
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-10-02 14:24:53
Subject:Re: [rest-discuss] EBI vs. REST
Message:

I came across I pretty good summary of the various options.

http://www.clipcode.com/peer/http_async_notif.htm


----- Original Message ----- 
From: "S. Mike Dierken" <mdierken@...>
To: <rest-discuss@yahoogroups.com>
Sent: Friday, September 27, 2002 3:23 PM
Subject: Re: [rest-discuss] EBI vs. REST



----- Original Message -----
From: "Vincent D Murphy" <vdm@...>

> so e.g. a client could connect to your server (through NAT, firewalls,
> etc.; all you need is TCP) and you could start sending POST methods
> 'back' to it.
There was some discussion a while back on this list about doing just this to
'send' to behind-the-firewall resources.
The connection is initiated by the protected machine, a 'protocol upgrade'
message is sent, and after that it is regular HTTP with the protected
machine playing the role of server. A simple form of tunnelling which does
not break HTTP in any way - other than intermediaries, which shouldn't be a
concern in this situation anyway (since the alternative is a custom
protocol).




To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 









-----------------------------------------------------------------------------------
Post ID:2731
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-02 16:36:39
Subject:Re: [rest-discuss] EBI vs. REST
Message:

----- Original Message -----
From: "Jeffrey Winter" <j.winter@...>


> I came across I pretty good summary of the various options.
>
> http://www.clipcode.com/peer/http_async_notif.htm
>
Yes - this is a good survey of different approaches. I'm not sure the
'never-ending response' /requires/ two connections. By the way, this is also
how KnowNow does stuff (response going to a browser has multiple events,
each is picked up by javascript on the client and dispatched to app code on
a page).

I think the 'TURN' approach is what we've talked about here - Mark or
somebody suggested the 'protocol upgrade' aspect of HTTP may be able to help
out here. ClipCode says this is 'not standard http' and recommends BEEP, but
I think the initiation is the only part not purely HTTP (and even then, it
follows the rules of extensions).

http://groups.yahoo.com/group/rest-discuss/message/1980
Nobody challenged whether Upgrade is all that is needed for 'client behind
firewall' or CONNECT is required - does anybody really know?



>
> ----- Original Message -----
> From: "S. Mike Dierken" <mdierken@...>
>
> ----- Original Message -----
> From: "Vincent D Murphy" <vdm@...>
>
> > so e.g. a client could connect to your server (through NAT, firewalls,
> > etc.; all you need is TCP) and you could start sending POST methods
> > 'back' to it.
> There was some discussion a while back on this list about doing just this
to
> 'send' to behind-the-firewall resources.
> The connection is initiated by the protected machine, a 'protocol upgrade'
> message is sent, and after that it is regular HTTP with the protected
> machine playing the role of server. A simple form of tunnelling which does
> not break HTTP in any way - other than intermediaries, which shouldn't be
a
> concern in this situation anyway (since the alternative is a custom
> protocol).
>







-----------------------------------------------------------------------------------
Post ID:2732
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-10-02 18:12:47
Subject:Re: [rest-discuss] EBI vs. REST
Message:

On Wed, Oct 02, 2002 at 09:36:39AM -0700, S. Mike Dierken wrote:
> http://groups.yahoo.com/group/rest-discuss/message/1980
> Nobody challenged whether Upgrade is all that is needed for 'client behind
> firewall' or CONNECT is required - does anybody really know?

If you want to send HTTP back through HTTP, as I see it you have two
choices; CONNECT or TURN.

I don't believe Upgrade is suitable, because its semantics say nothing
of flipping client/server, just upgrading to a new protocol.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2733
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-02 18:22:54
Subject:Web notification - blogs are gathering steam, but not necessarily correctly...
Message:

I'm not sure everybody interested in Web notifications has noticed, but the
world of blogs has built pub/sub mechanisms. Very useful, but not very REST.
But of course, that's the way the Web was built too...


There are two approaches (that I know of - I'm a newbie to blog
infrastructure)
 - trackback (from MoveableType)
 - pingback

Generally these both allow a blog to subscribe to a different blog - the
original blog is then notified when new entries are added to the second
blog, etc.
Unfortunately, neither use the terms publish, subscribe, notify, etc. very
often. The term 'ping' generally means 'notify'.
This system is currently used to establish cross-links between items. Since
it is a bare-bones pub/sub system, it will grow into more uses.
Generally, this is creating a semi-distributed discussion/mail/discussion
system. Semi-distributed in the sense that individual entries in a
series/thread do not need to reside on a single server, but the messages are
still on a server rather than being downloaded to a client (like the way
email works). It shows the power of distributed hyper-linking (I'm sure
PaulP is all over this...).


TrackBack
-----------
http://www.movabletype.org/docs/mtmanual_trackback.html
TrackBack says they use a REST model for its pings, but they use GET to
perform the notification. It's be better to use POST, either with an XML
body or a x-www-form-urlencoded (classical form data) body. I haven't found
out why they used GET.
They also provide a listing of previous notifications (pings) on a
particular blog entry. It is assumed that all notifications contain a link
to a related posting on a different blog - pretty reasonable in the world of
discussion based blogs.

MoveableType definitely wants trackback to become more than just blog
cross-linking. They are also addressing some security concerns.

PingBack
----------
http://www.hixie.ch/specs/pingback/pingback
"Pingback is a method for web authors to request notification when somebody
links to one of their documents."
"The pingback mechanism uses an HTTP header and an HTML or XHTML <link>
element for autodiscovery, and uses a single XML-RPC call for notifying the
target site of the link on the source site."

This seems more cooler... they provide for an HTTP response header
X-Pingback, as well as a <link> tag in HTML and XHTML: <link rel="pingback"
href="http://charlie.example.com/pingback/xmlrpc">

They also say "HTTP headers are defined to override link elements when they
differ." - I wonder if this is wise, given that its easier to change content
than response headers. I think this happened with HTTP/HTML <meta
http-equiv> tags.

They also use XML-RPC instead of pure HTTP.
method: pingback.ping
description: Notifies the server that a link has been added to sourceURI,
pointing to targetURI.


It's interesting to consider the difference between notifications (that a
link was added) and an explicit request (add a link to the 'referenced-by'
collection). Both need a magic name - either 'pingback.ping' (the name of
the method) or 'referenced-by' (the name of the collection). With a custom
named method, you need another magic name to get a list (apparently not
discussed in the pingback spec). With a named collection, you just use GET
on that same collection.








-----------------------------------------------------------------------------------
Post ID:2734
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-10-02 18:41:39
Subject:Re: [rest-discuss] Web notification - blogs are gathering steam, but not necessarily correctly...
Message:

S. Mike Dierken wrote:
> I'm not sure everybody interested in Web notifications has noticed, but the
> world of blogs has built pub/sub mechanisms. Very useful, but not very REST.
> But of course, that's the way the Web was built too...
> 
> 
> There are two approaches (that I know of - I'm a newbie to blog
> infrastructure)
>  - trackback (from MoveableType)
>  - pingback
> 
> Generally these both allow a blog to subscribe to a different blog - the
> original blog is then notified when new entries are added to the second
> blog, etc.
> Unfortunately, neither use the terms publish, subscribe, notify, etc. very
> often. The term 'ping' generally means 'notify'.

At Sam Ruby's suggestion, I have spoken with the inventor of trackback 
about being more REST-y. He's open to the idea but we haven't converged 
on a final design and development plan yet. He used the term REST in his 
literature so he was trying to do the right thing but various 
implementation quirks pushed him towards using non-idempotent GETs. I 
think future versions will fix that.

I don't know anything about PingBack. If there is anything better there 
maybe it could be incorporated into the TrackBack refactoring.

>...
> This seems more cooler... they provide for an HTTP response header
> X-Pingback, as well as a <link> tag in HTML and XHTML: <link rel="pingback"
> href="http://charlie.example.com/pingback/xmlrpc">

Trackback uses RDF.

> They also say "HTTP headers are defined to override link elements when they
> differ." - I wonder if this is wise, given that its easier to change content
> than response headers. I think this happened with HTTP/HTML <meta
> http-equiv> tags.
> 
> They also use XML-RPC instead of pure HTTP.
> method: pingback.ping
> description: Notifies the server that a link has been added to sourceURI,
> pointing to targetURI.

At least it is using POST as POST instead of as GET.

> It's interesting to consider the difference between notifications (that a
> link was added) and an explicit request (add a link to the 'referenced-by'
> collection). Both need a magic name - either 'pingback.ping' (the name of
> the method) or 'referenced-by' (the name of the collection). With a custom
> named method, you need another magic name to get a list (apparently not
> discussed in the pingback spec). With a named collection, you just use GET
> on that same collection.

That's what I've been suggesting. POST extends the collection of 
trackbacks. GET returns the list of trackbacks.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2735
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-02 19:27:30
Subject:Re: [rest-discuss] Web notification - blogs are gathering steam, but not necessarily correctly...
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> At Sam Ruby's suggestion, I have spoken with the inventor of trackback
> about being more REST-y. He's open to the idea but we haven't converged
> on a final design and development plan yet.
Let me know if I can help out - I have some free time on my hands.
I'm installing MoveableType and will be playing around with it.

> He used the term REST in his
> literature so he was trying to do the right thing but various
> implementation quirks pushed him towards using non-idempotent GETs. I
> think future versions will fix that.

> >...
> > This seems more cooler... they provide for an HTTP response header
> > X-Pingback, as well as a <link> tag in HTML and XHTML: <link
rel="pingback"
> > href="http://charlie.example.com/pingback/xmlrpc">
>
> Trackback uses RDF.
But this one goes to eleven!
http://spinaltapfan.com/atozed/TAP00160.HTM








-----------------------------------------------------------------------------------
Post ID:2736
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-10-02 20:43:08
Subject:Re: [rest-discuss] Web notification - blogs are gathering steam, but not necessarily correctly...
Message:

I just got an email from Benjamin that indicates that future versions of 
TrackBack will treat URIs totally opaquely on the client, will use POST 
for "notify" and after backwards compatibility issues have been cleared, 
GETs will be freed up and probably used to report on the list of things 
that were POSTed. Also some minor issues with RDF will probably be 
cleaned up and they are working on deeper integration with RSS.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2737
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-10-02 23:36:22
Subject:Re: [rest-discuss] EBI vs. REST
Message:

Sorry guys, I haven't been following closely but from previous thinking 
I strongly believe that there is a really useful RFC potential in a 
simple mechanism to turn around an HTTP connection. It isn't that 
different than launching SSL from HTTP. 
http://rfc.sunsite.dk/rfc/rfc2817.html

Sorry for jumping in the middle. Wasted my email time today on TAG.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2738
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-03 02:33:50
Subject:Re: [rest-discuss] EBI vs. REST
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> Sorry guys, I haven't been following closely but from previous thinking
> I strongly believe that there is a really useful RFC potential in a
> simple mechanism to turn around an HTTP connection. It isn't that
> different than launching SSL from HTTP.
> http://rfc.sunsite.dk/rfc/rfc2817.html
>
> Sorry for jumping in the middle. Wasted my email time today on TAG.
>

I think there is a lot in there that is good - but I'm not sure what HTTP
method we'd apply the Upgrade header to.
It is really a server operation, not a per-resource operation. I don't know
the SSL+HTTP stuff, so it might be a lot more similar that I'm thinking.

So what are the choices?
a) Upgrade header
 - what method(s) or resources would this apply to? (probably OPTIONS...)
 - is it sufficiently like keep-alive that is applies to multiple requests?
 - am I worrying over nothing regarding Upgrade and multiple
resources/methods?

b) CONNECT method
 - how would this work?
 - CONNECT seems to be per-host rather than per-resource (you couldn't have
multiple resources, one per 'message queue'- but this might simplify
security/authority issues)
 - what is CONNECT used for anyway? Is it for tunning a /different/ protocol
over port 80 to a destination system?

c) new method (TURN or something)








-----------------------------------------------------------------------------------
Post ID:2739
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-10-03 07:23:40
Subject:Re: [rest-discuss] EBI vs. REST
Message:

S. Mike Dierken wrote:
> ----- Original Message -----
>...
> 
> I think there is a lot in there that is good - but I'm not sure what HTTP
> method we'd apply the Upgrade header to.

They use OPTIONS. Why not copy?

> It is really a server operation, not a per-resource operation. I don't know
> the SSL+HTTP stuff, so it might be a lot more similar that I'm thinking.

I think that RFC 2817 bears study. I'd almost use it as a template for a 
new one.

> So what are the choices?
> a) Upgrade header
>  - what method(s) or resources would this apply to? (probably OPTIONS...)
>  - is it sufficiently like keep-alive that is applies to multiple requests?

It applies to the *socket*. You are switching protocols from HTTP to 
"Reverse HTTP" which happens to have identical syntax and semantics to 
HTTP except you never create a Reverse HTTP connection directly, you 
always get one by reusing an ordinary HTTP socket.

>  - am I worrying over nothing regarding Upgrade and multiple
> resources/methods?
> 
> b) CONNECT method
>  - how would this work?
>  - CONNECT seems to be per-host rather than per-resource (you couldn't have
> multiple resources, one per 'message queue'- but this might simplify
> security/authority issues)
>  - what is CONNECT used for anyway? Is it for tunning a /different/ protocol
> over port 80 to a destination system?

Yes. Like HTTPS or "Reverse HTTP".

> c) new method (TURN or something)

I don't think that there is a need for it.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2740
Sender:"Mathews, Walden" <waldenm@...>
Post Date/Time:2002-10-03 15:45:38
Subject:RE: [rest-discuss] moindot code
Message:

Now that the REST wiki is back up, would it be possible to
install this?  I'd like to experiment with pictures.

Walden

> -----Original Message-----
> From: Jeff Bone [mailto:jbone@...]
> Sent: Friday, September 27, 2002 2:42 PM
> To: Mathews, Walden
> Cc: 'rest-discuss@yahoogroups.com'
> Subject: Re: [rest-discuss] moindot code
> 
> 
> 
> On Friday, September 27, 2002, at 12:26  PM, Mathews, Walden wrote:
> 
> > Yes, very interested in the "dot code" processor.  I want to post my
> > Alloy models to the REST Wiki, showing graphs of certain 
> instances of
> > the models.  Coincidentally, Alloy saves the info in "dot code", so
> > yes this would be very helpful.  Also helpful would be if 
> someone knows
> > how to make the processor part of REST Wiki, 'cuz I sure as hell
> > don't.
> 
> Pj's moindot processor is available on the moinmoin processor market 
> page, but it's a slightly outdated version that only allows 
> one graph / 
> page.  (You can set up multiple ones, but the last one is 
> rendered for 
> every separate graph description.  Oops. ;-)  The current 
> version we're 
> using doesn't have this limitation;  here it is in all its glory.  
> Simply drop it into .../processor/moindot.py:
> 
> ----
> """
>      MoinDot - WebDot/MoinMoin collaboration macro
> 
>      Copyright (c) 2002 by Paul Jimenez <pj@...>
> 
> """
> 
> import string, sys
> 
> def process(request, formatter, lines):
>      webdoturl = "http://my.webdot.host/cgi-bin/webdot/"
>      localdir = "/var/www/html/webdot/"
>      localurl = "http://my.webdot.dir.url/webdot/"
>      # parse bangpath for arguments
>      # remove bang path
>      args=string.split(lines[0])
>      if len(args) > 1:
>          dotfilename = "moindot-%s.dot" % args[1]
>      else:
>          dotfilename = "moindot.dot"
> 
>      dotfile = file(localdir+dotfilename,'w')
> 
>      del lines[0]
>      for line in lines:
>          dotfile.write(line)
>          dotfile.write("\n")
>      #dotfile.writelines(lines)
>      dotfile.close()
> 
>      dotjpgurl = "%s%s%s.dot.jpg" % (webdoturl, localurl, dotfilename)
> 
>      sys.stdout.write("<IMG SRC=\""+dotjpgurl+"\">")
> 
> ----
> 
> To use this, just include dot code in your wikitext as follows:
> 
> {{{#!moindot
> 
> ...dot code goes here...
> 
> }}}
> 
> Couple of prerequisites:  you'll either need to set up the 
> webdot stuff 
> on the wiki (or other) host  OR use one of the open webdot renderers 
> out on the net somewhere.  The webdoturl variable above 
> should point at 
> that host.  The localurl variable needs to contain the base / 
> path for 
> where the webdot renderer can retrieve the dot code to render --- 
> that's a directory on the wikihost that should be set up.
> 
> Enjoy!
> 
> jb
> 







-----------------------------------------------------------------------------------
Post ID:2741
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-10-03 16:08:24
Subject:Re: [rest-discuss] moindot code
Message:

On Thu, Oct 03, 2002 at 11:45:38AM -0400, Mathews, Walden wrote:
> Now that the REST wiki is back up, would it be possible to
> install this?  I'd like to experiment with pictures.

Sure.  Some install directions would help.  We're using MoinMoin 0.9,
which may be a problem.

Let's take this off-line too.  If we get it working, we'll announce
it back here.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@...
http://www.markbaker.ca        http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2742
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-10-03 17:39:32
Subject:REST-Bay revived
Message:

A while ago I posted a trial baloon on rest-discuss
about a decentralized REST auction idea.
http://groups.yahoo.com/group/rest-explore/message/96

The response was so underwhelming that I concluded the baloon may be 
of the lead variety.  And I got busy with other things and never 
followed up properly.

But now I see an independent emergence of the same idea from Joe 
Gregorio:
http://bitworking.org/wellformed.html

Joe's even got some implementation ideas.  And he refers to REST, as 
well.

Plus, I see Phil Eskelin noticed the idea:
http://groups.yahoo.com/group/rest-discuss/message/2706

So maybe it's worth porting to rest-discuss and see if's got legs.

Joe and I had a little email exchange about it, as follows:

[Joe, responding to my ping] Interesting. I had come at it from an 
RDF angle and not web services. Given the interest I'll try putting 
together a quick implementation of this.
[Joe's article also spawned a thread on xml-dev]
Have you done any work on an implementation?

[Bob] No.  Busy with other things.
Where I was gonna focus next was on binding the bids to the ad, and 
the ad to the winning bid.
Then a little work on the non-repudiation angle - you don't really 
need to repeat the representations, just the digests.
[I was thinking of Paul's URL + hash format]
The other thing I was thinking is to relax the "biddingEnds" so as to 
eliminate sniping.  Do it more like a regular auction - going, going, 
gone.  But of course at the option of the advertiser

[Joe] Oooh, neat idea. If you think of it that way then this replaces 
auctions and classified ads all at the same time.

[Bob] Yes.  What I have in mind is offers of all kinds:
offers to sell, offers to buy, offers to barter, offers of services, 
you name it.
I don't see any reason why any of this stuff can't be decentralized.








-----------------------------------------------------------------------------------
Post ID:2743
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-03 17:48:11
Subject:Re: [rest-discuss] EBI vs. REST
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>
To: "S. Mike Dierken" <mdierken@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Thursday, October 03, 2002 12:23 AM
Subject: Re: [rest-discuss] EBI vs. REST


> S. Mike Dierken wrote:
> > ----- Original Message -----
> >...
> >
> > I think there is a lot in there that is good - but I'm not sure what
HTTP
> > method we'd apply the Upgrade header to.
>
> They use OPTIONS. Why not copy?
Yes, I think that would work.



> > c) new method (TURN or something)
>
> I don't think that there is a need for it.

I think maybe a 'PROXY' method (requesting that the server begin acting as a
type of proxy) might make sense.
If CONNECT has a way to advertise what particular protocol will be
'tunnelled' - like "HTTP-Reverse/1.1" - then proxies will still be able to
participate (caching, cache purging, etc.). Although I don't really care if
proxies are involved.

I see two scenarios for this technology -
a) expose private machine on public Web
the private machine wants to be public but can't accept incoming connections
so the public machine proxies that job
Useful for dynamic IP allocation, either due to ISP allocated addresses or
through 'nomadic/mobile' use. Other approaches like dyndns.org may solve the
host/ip mapping issue, but not incoming connection issues.
This turns the client into a server - which means you need more security and
either multiple connections or multiplexing messages on a single connection.

b) low-latency application messaging
where a private machine just wants low-latency messages to an application
but can't accept incoming connections.
This may be useful for smaller devices - the public machine can do all the
security, high-level policy stuff and connection management, and the small
device can stay simple.



I do not want to 'tunnel' stuff through a firewall - I'm not into smuggling
information. Either you are the firewall admin & can open up the port, or
you are not the admin and you /shouldn't/ open up the port. The third
alternative is that the firewall admin doesn't care to let you listen - like
an ISP that restricts incoming requests. This situation would benefit from a
generic 'reverse http connector' - like an Apache mod (or hack) that did the
proper socket management.








-----------------------------------------------------------------------------------
Post ID:2744
Sender:Phil Eskelin <philip.eskelin@...>
Post Date/Time:2002-10-03 17:49:52
Subject:RE: [rest-discuss] REST-Bay revived
Message:

Bob wrote:
> Plus, I see Phil Eskelin noticed the idea:
> http://groups.yahoo.com/group/rest-discuss/message/2706
>
> So maybe it's worth porting to rest-discuss and see if's got legs.

I was wondering if you were registering on my interest in REST-Bay, and I
assumed you were busy at the time and couldn't respond.  Anyway, I think
REST-Mail and REST-Bay are great examples that would help people get it.

I too have been very busy in the last few weeks.  Hence I haven't made as
much progress as I wanted to when I posted message 2706, but I can promise
you that once I release v1.0 of this toolkit, I will move focus to 1)
responding to feedback from this group and 2) implementing sample programs.

Thanks,
Philip

________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.






-----------------------------------------------------------------------------------
Post ID:2745
Sender:"noxavior" <noxavior@...>
Post Date/Time:2002-10-09 00:51:17
Subject:Newbie question
Message:

Hello everyone, I have been interrested in the web services architecture debates for about a year now. I read in one of the messages here that GET and POST have different uses. How is this true? And while we're at it, what's a good reference to understand the four transactions supported by HTTP? How about good background reading on HTTPS?

Any information is appreciated,

Geoffrey








-----------------------------------------------------------------------------------
Post ID:2746
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-09 04:07:41
Subject:Re: [rest-discuss] Newbie question
Message:

----- Original Message -----
From: "noxavior" <noxavior@...>


> Hello everyone, I have been interrested in the web services architecture
debates for about a year now.
> I read in one of the messages here that GET and POST have different uses.
How is this true?
With HTTP, a request message identifies a resource and an operation upon
that resource. These operations are the methods as specified in the HTTP
spec - http://www.w3.org/Protocols/rfc2616/rfc2616.html
A GET message is requesting a representation of the resource identified by
the URL (also called the URI).
A POST message is requesting that data carried along with the request be
used by the resource to 'extend' the resource. This 'extend' could be many
things. For example, it could add an entry to a log, or add a file to a
directory, etc. If a new resource is created, the response to the POST
request can identify the URL of this new resource.

> And while we're at it, what's a good reference to understand the four
transactions supported by HTTP?
HTTP has more than four methods - and new methods can be added.
The spec has good detail, but I would like to see other descriptions also. I
once read a book with a frog on it that talked alot about HTTP, but haven't
seen it in a while.

> How about good background reading on HTTPS?
I don't know.







-----------------------------------------------------------------------------------
Post ID:2747
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-10-09 15:35:12
Subject:Re: [rest-discuss] Clarification of PUT
Message:

> Probably more a rest-discuss question, but ..

ok. moved from rest-explore...

>> On Wed, Oct 09, 2002 at 10:55:07AM -0400, Jeffrey Winter wrote:
>> When PUTing a representation, is it the requirement that the 
>> entity-body will be stored as-is, or only that the representation
>> not vary on GET?
>> 
>> So in other words, if I accept the following PUT:
>> 
>>     <a><b/></a>
>> 
>> is it okay to respond to a GET with:
>> 
>>     <a>
>>         <b/>
>>     </a>

> No.

Do intermediaries actually depend on this or is it just the 
semantics of the method itself?

>> so long as that response does vary based on the headers?  
>> Or is the expectation that GET actually responds with
>> the exact same representation that was PUT?  

> Yes.
>
> This is why we need "SET", which could do this.  SET could be used with
> SOAP, while PUT can't (at least as you'd expect it to be used).

The SOAP PUT issue was actually one of the issues that I was 
wondering about.  How could it really work at all?

Do you envision this "SET" method allowing partial resource updates?







-----------------------------------------------------------------------------------
Post ID:2748
Sender:Matt Gushee <mgushee@...>
Post Date/Time:2002-10-09 16:13:54
Subject:Re: [rest-discuss] Clarification of PUT
Message:

On Wed, Oct 09, 2002 at 11:35:12AM -0400, Jeffrey Winter wrote:

> >> On Wed, Oct 09, 2002 at 10:55:07AM -0400, Jeffrey Winter wrote:
> >> When PUTing a representation, is it the requirement that the 
> >> entity-body will be stored as-is, or only that the representation
> >> not vary on GET?
> >> 
> >> So in other words, if I accept the following PUT:
> >> 
> >>     <a><b/></a>
> >> 
> >> is it okay to respond to a GET with:
> >> 
> >>     <a>
> >>         <b/>
> >>     </a>
> 
> > No.

Has it been stipulated somewhere that the GET request is asking for the
same representation type that was PUT? If not, I don't understand why
that wouldn't be allowed. The two documents would appear to be variant
representations of the same resource (or perhaps I should say of each
other, since we don't know what the resource is).

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@...           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)






-----------------------------------------------------------------------------------
Post ID:2749
Sender:Jan Algermissen <algermissen@...>
Post Date/Time:2002-10-10 17:09:02
Subject:POSTING to a URI that contains a query string ?
Message:

Hi,

this might actually be an FAQ question, but I want to make
sure not just 'legal HTTP' but also RESTful:

Can I POST to a URI that contains a query string ?

Example (adding a link to a linklist) :

POST /linklist?subject=travel HTTP/1.0
Host: www.myhost.com
Content-Length: 28

http://www.cheaptravel.com

Would this be OK ?



Would it be OK in an HTML <form action="..." method="POST">
element to specify an action URL that contains a query string ?


Jan




-- 
Jan Algermissen
Consultant & Programmer

Tel:   ++49 (0)40 89 700 511
       ++49 (0)177 283 1440
Fax:   ++49 (0)40 89 700 841 
Email: algermissen@...
Web:   http://www.topicmapping.com






-----------------------------------------------------------------------------------
Post ID:2750
Sender:Chris Croome <chris@...>
Post Date/Time:2002-10-10 19:18:00
Subject:Re: [rest-discuss] POSTING to a URI that contains a query string ?
Message:

Hi

On Thu 10-Oct-2002 at 07:09:02PM +0200, Jan Algermissen wrote:
> 
> Can I POST to a URI that contains a query string ?

We haven't had any luck doing that with Apache and Perl, the result
is always the same as posting without the query string. 

Populating the form with the information from the query string
seems the most logical thing to do.

Chris 

-- 
Chris Croome                               <chris@...>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   
everything else                               http://chris.croome.net/  






-----------------------------------------------------------------------------------
Post ID:2751
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-10 20:24:50
Subject:Re: [rest-discuss] POSTING to a URI that contains a query string ?
Message:

----- Original Message -----
From: "Jan Algermissen" <algermissen@...>

> Can I POST to a URI that contains a query string ?
Absolutely.

>
> Example (adding a link to a linklist) :
>
> POST /linklist?subject=travel HTTP/1.0
> Host: www.myhost.com
> Content-Length: 28
>
> http://www.cheaptravel.com
>
> Would this be OK ?
Definitely.

>
>
>
> Would it be OK in an HTML <form action="..." method="POST">
> element to specify an action URL that contains a query string ?
Yes.

The only caution I would have is when server tools parse the request, they
don't always do it right. Often they provide a request property called
'parameters' - but there is no such thing in the protocol. This usually is a
blending of the query terms from the resource identifier and the name/value
pairs from the content being posted.  Another example where common tools are
broken with respect to using the protocol correctly.
Often, you will have to explicitly get the query terms separate from the
form data. I think ASP pages can do this relatively easily. If the names
between query terms and content body are the same you may have problems, so
I'd recommend avoiding that.

Mike









-----------------------------------------------------------------------------------
Post ID:2752
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-10 22:08:11
Subject:Re: [rest-discuss] POSTING to a URI that contains a query string ?
Message:

----- Original Message -----
From: "Vincent D Murphy" <vdm@...>

>
> i have mod_rewrite rules in apache which do the following:
>
> /contributors/?foo=bar      becomes
> /cgi-bin/contributors/index.cgi?foo=bar
> /contributors/12345         becomes
> /cgi-bin/contributors/one.cgi?id=12345
> /contributors/12345?foo=bar becomes
> /cgi-bin/contributors/one.cgi?id=12345&foo=bar
>
> and so on.  each CGI script handles all requests (GET, POST for know
> because that's all the clients support).
This is very nice - what do the rules look like? (I don't know the Apache
syntax)

This is a good idea even independent of REST since the public URL doesn't
have name of the implementation file (one.cgi) which could change if the
system migrates to another technology (e.g. one.jsp). The URLs have a longer
lifetime and this is good.








-----------------------------------------------------------------------------------
Post ID:2753
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-10-11 09:35:28
Subject:Re: [rest-discuss] POSTING to a URI that contains a query string ?
Message:

here's my .htaccess.

RewriteEngine on
RewriteBase /foo
RewriteRule ^contributors$ contributors/ [R=permanent]
RewriteRule ^contributors/$ cgi/contributors/index.pl.cgi
RewriteRule ^contributors/([0-9]+)[/]?$ 
cgi/contributors/one.pl.cgi?id=$1

RewriteBase sets the 'root' of your URL.  it could be just slash /, but 
i used /foo because there are other things living on the root of the 
same httpd.

overall i found mod_rewrite to be a total pain in the ass (it took me a 
whole day to come up with these simple rules) but i'm of the opinion 
that it was worth it.







-----------------------------------------------------------------------------------
Post ID:2754
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-10-10 21:52:38
Subject:Re: [rest-discuss] POSTING to a URI that contains a query string ?
Message:

[yahoo groups was bouncing my mail, so i'm reposting this.]

On Thursday, Oct 10, 2002, at 21:24 Europe/Dublin, S. Mike Dierken 
wrote:
> The only caution I would have is when server tools parse the request, 
> they
> don't always do it right. Often they provide a request property called
> 'parameters' - but there is no such thing in the protocol. This 
> usually is a
> blending of the query terms from the resource identifier and the 
> name/value
> pairs from the content being posted.  Another example where common 
> tools are
> broken with respect to using the protocol correctly.

agreed.  in perl, pretty much all of the CPAN CGI modules (including 
the erst-while CPAN.pm) advertise this breakage as a feature (although 
to be fair i guess not many people care outside of those who are aware 
of REST), and you have to explicitly configure the modules to 
distinguish between the url-encoded entity body and the query string.

i just read STDIN or the QUERY_STRING environment variable and use a 
hash keyed on the value of Content-type header to pick out an 
appropriate parser.  if you want me to elaborate on this chris, let me 
know; i have a CGI script doing this.

i'm using this in combination with mod_rewrite to have nice URIs which 
reflect the hierarchy.  this isn't strictly a requirement of being 
RESTful; i just like it this way.  it keeps verbs out of the URIs, they 
only have nouns in them.

i am working on a system for tracking fund-raising.

i have mod_rewrite rules in apache which do the following:

/contributors/?foo=bar      becomes 
/cgi-bin/contributors/index.cgi?foo=bar
/contributors/12345         becomes 
/cgi-bin/contributors/one.cgi?id=12345
/contributors/12345?foo=bar becomes 
/cgi-bin/contributors/one.cgi?id=12345&foo=bar

and so on.  each CGI script handles all requests (GET, POST for know 
because that's all the clients support).

i'm toying with the idea of boiling this stuff down into a CPAN module 
called CGI::Resource or something; maybe when i have a bit more 
experience of how well this works in practice.  if anybody wants 
boilerplate source shout.

to answer your question, POSTing to a URI with a querystring is 
definitely possible, and probably OK.  i prefer to use querystrings for 
queries parameters only as much as possible, but pragmatism wins out 
easily over that most of the time.  the tool support for eliminating 
querystrings except for queries isn't really there (yet).  hence my 
wrestling with mod_rewrite.

regards,
-vincent







-----------------------------------------------------------------------------------
Post ID:2755
Sender:Jan Algermissen <algermissen@...>
Post Date/Time:2002-10-11 19:47:20
Subject:Re: [rest-discuss] POSTING to a URI that contains a query string ?
Message:

Chris Croome wrote:
> 
> Hi
> 
> On Thu 10-Oct-2002 at 07:09:02PM +0200, Jan Algermissen wrote:
> >
> > Can I POST to a URI that contains a query string ?
> 
> We haven't had any luck doing that with Apache and Perl, the result
> is always the same as posting without the query string.

Hmm, technically I will be writing an Apache module. Am I correctly assuming
that Apache itself does not have problems with this ?


The reason why I need to use a query string is that URIs will be part of
my web service URIs

Here is a fictitious example:

Suppose there is a web service that serves manuals for all kinds
of technical goods, among them air conditioner XYZ. Also suppose that
the only way to tell the services which machine's manual I need to see
is via a URI. I would have to issue requests such as

GET /documentation/manuals?item=http://www.brandX.com/products/air-contitioners#XYZ

(not url encoded for clarity)

Would there be any way to put the air conditioner's URI into the service's
URI other than via a query string ?



Jan


 
> 
> Populating the form with the information from the query string
> seems the most logical thing to do.
> 
> Chris
> 
> --
> Chris Croome                               <chris@...>
> web design                             http://www.webarchitects.co.uk/
> web content management                               http://mkdoc.com/
> everything else                               http://chris.croome.net/
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

-- 
Jan Algermissen
Consultant & Programmer

Tel:   ++49 (0)40 89 700 511
       ++49 (0)177 283 1440
Fax:   ++49 (0)40 89 700 841 
Email: algermissen@...
Web:   http://www.topicmapping.com






-----------------------------------------------------------------------------------
Post ID:2756
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-11 21:11:08
Subject:Re: [rest-discuss] POSTING to a URI that contains a query string ?
Message:

----- Original Message -----
From: "Jan Algermissen" <algermissen@...>

> Here is a fictitious example:
>
> Suppose there is a web service that serves manuals for all kinds
> of technical goods, among them air conditioner XYZ. Also suppose that
> the only way to tell the services which machine's manual I need to see
> is via a URI. I would have to issue requests such as
>
> GET
/documentation/manuals?item=http://www.brandX.com/products/air-contitioners#
XYZ
>
> (not url encoded for clarity)
>
> Would there be any way to put the air conditioner's URI into the service's
> URI other than via a query string ?
If this is not purely a pass-through - the brandX.com is a registered data
entity on your server - then you don't have to have http: in there. You
would use an id that your server knew about, do the lookup to the base URL
for the third party, and merge some text strings.

If you don't need the protocol portion, you can just put it in a path
segment (between the '/' characters). You can define for your internal
implementation that any segments past a certain point are part of the other
site.

GET /documentation/manuals/www.brandX.com/products/air-contitioners#XYZ

If you do need the protocol, then you probably need a query string.








-----------------------------------------------------------------------------------
Post ID:2757
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-10-15 13:48:47
Subject:RE: [rest-discuss] Re: Resources always exist
Message:

Paul,

Just cleaning out my inbox and I found this message from you.
I had saved it because it hinted at the potential value of some
mathematical models aimed at clarifying HTTP method semantics.

Since then, about a month has passed, during which time myself
and a few others who read the rest-explore list have been
experimenting with such models, and probably now have enough
skill with one particular modeling language (Alloy) to be able
to do what you suggest below, notably:

	"Roy describes a very mathematical mode for HTTP
	(resource is a mapping etc.) and if the HTTP methods
	were described in those terms it would be much easier
	to build interoperable software."

I think, for one reason or another, we've gone off more in the
direction of a pure REST model, rather than an HTTP model,
probably mostly because those famous two sentences from Roy's
thesis are about all we really have to go on...

Could you please comment on this effort and your current
thoughts about it.  I have been unsuccessful to date in trying
to interest Roy in the benefits of developing such models.
That makes it harder to know what it is we're modeling, and
on whose authority, but it's still possible to build a small
set of models, each of which clarifies a particular interpretation
of an HTTP method.  If not authority, at least it might lend
some clarity, especially if we can leverage graphical
representations of the models as a more accessable form for
general consumption.  Perhaps the modeling effort converges
on a small number of method usage patterns, which could then
be named, and those names might become useful to applications
that want to extend the HTTP contract?

You haven't said anything about this since mid-September, so
an update from you would be quite valuable, I think.

Thanks,

Walden

> -----Original Message-----
> From: Paul Prescod [mailto:paul@...]
> Sent: Wednesday, September 18, 2002 4:31 PM
> To: S. Mike Dierken
> Cc: Roy T. Fielding; rest-discuss
> Subject: [rest-discuss] Re: Resources always exist
> 
> 
> S. Mike Dierken wrote:
> > ----- Original Message -----
> > From: "Paul Prescod" <paul@...>
> > 
> >>If you DELETE something twice, you usually expect an error 
> message or a
> >>core dump.
> > 
> > Do you mean 'delete' in the classic programming language 
> sense (releasing
> > system memory, calling destructors, etc.) or do you mean 
> the HTTP concept of
> > DELETE?
> 
> The fact that there is potentially a divergence there is exactly my 
> point. It's okay for HTTP to diverge but if the spec doesn't 
> say clearly 
> one way or another, then people will just guess. HTTP says basically 
> "DELETE means you should delete."
> 
> Roy describes a very mathematical mode for HTTP (resource is 
> a mapping 
> etc.) and if the HTTP methods were described in those terms 
> it would be 
> much easier to build interoperable software.
> 
> There are hints that it was politics that prevented this from 
> happening 
> the first time around, but what should we do about it now? 
> Just transmit 
> the true meanings of the methods through mailing lists? 
> Increment HTTP? 
> Write an RFC clarifying? Wait for Roy's new protocol? I'm 
> being serious 
> here: I think that there is a problem and a variety of 
> solutions and am 
> soliciting opinions on both issues.
> 
>   Paul Prescod
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 








-----------------------------------------------------------------------------------
Post ID:2758
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-10-15 16:27:26
Subject:Re: Why GET is an application semantic
Message:

http://lists.w3.org/Archives/Public/www-ws-arch/2002Jun/0085

Can you do the same exercise with POST, PUT and DELETE? That would be a 
valuable set of articles.

  Paul Prescod
	







-----------------------------------------------------------------------------------
Post ID:2759
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-10-15 16:41:21
Subject:Re: Why GET is an application semantic
Message:

On Tue, Oct 15, 2002 at 09:27:26AM -0700, Paul Prescod wrote:
> http://lists.w3.org/Archives/Public/www-ws-arch/2002Jun/0085
> 
> Can you do the same exercise with POST, PUT and DELETE? That would be a 
> valuable set of articles.

I'll add it to my to-do list.  Ick.  POST would be fun though.

BTW, my to-do list is one item smaller today (well, until that last
paragraph 8-); Webdot is now integrated into the RESTwiki, and the
Wiki itself was upgraded to Moin-1.0, so we've got a whole bunch of
new features including the rather annoying and unRESTful navigation
bar that shows you your navigation path through the Wiki.

See my page for an example of Webdot/Moindot;

http://internet.conveyor.com/RESTwiki/moin.cgi/MarkBaker

P.S. I had to patch a bug in Jeff's moindot.py code;

dotfile = file(localdir+dotfilename,'w')
->
dotfile = open(localdir+dotfilename,'w')

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2760
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-10-15 16:57:37
Subject:Re: [rest-discuss] Re: Why GET is an application semantic
Message:

On Tuesday, Oct 15, 2002, at 17:27 Europe/Dublin, Paul Prescod wrote:
> http://lists.w3.org/Archives/Public/www-ws-arch/2002Jun/0085
>
> Can you do the same exercise with POST, PUT and DELETE? That would be a
> valuable set of articles.

ditto!  explaining it as a matter of increasing generality emphasizes 
why GET et al are 'axiomatic'.

this is something i can send my non-believer colleagues.







-----------------------------------------------------------------------------------
Post ID:2761
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-10-15 17:38:15
Subject:RE: [rest-discuss] Re: Why GET is an application semantic
Message:

> BTW, my to-do list is one item smaller today (well, until that last
> paragraph 8-); Webdot is now integrated into the RESTwiki, and the
> Wiki itself was upgraded to Moin-1.0, so we've got a whole bunch of
> new features including the rather annoying and unRESTful navigation
> bar that shows you your navigation path through the Wiki.

Yipee!! I enabled the dotcode on WebState already.  Looks purdy.

-Walden







-----------------------------------------------------------------------------------
Post ID:2762
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-10-15 21:30:21
Subject:OT: Python
Message:

Mark Baker wrote:
>...
> 
> P.S. I had to patch a bug in Jeff's moindot.py code;
> 
> dotfile = file(localdir+dotfilename,'w')
> ->
> dotfile = open(localdir+dotfilename,'w')

Not a bug, a version skew.

Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> id(file)
679816
 >>> id(open)
679816
 >>> file is open
1

Essentially open() is a C-ism but file() allows you to think of it as a 
constructor for an object (which it is). Presumably sometime when our 
children are programmers, the "open" spelling will be removed or 
strongly deprecated.

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2763
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-10-15 21:46:37
Subject:Re: [rest-discuss] OT: Python
Message:

On Tuesday, October 15, 2002, at 04:30  PM, Paul Prescod wrote:

> Mark Baker wrote:
>> ...
>>
>> P.S. I had to patch a bug in Jeff's moindot.py code;

Wouldn't be surprising. ;-)  (Last-minute pre-customer build frenzy, 
I've crashed the build at work twice today with untested changes 
including single-character ytpos...)

>> dotfile = file(localdir+dotfilename,'w')
>> ->
>> dotfile = open(localdir+dotfilename,'w')
>
> Not a bug, a version skew.

Yup, sorry 'bout that, should've noted it.  WORKSFORME. ;-)

> Essentially open() is a C-ism but file() allows you to think of it as a
> constructor for an object (which it is). Presumably sometime when our
> children are programmers, the "open" spelling will be removed or
> strongly deprecated.

Interesting bit I just learned recently...  in (a) recent Python 
version (?) file objects are implicitly iterators, meaning you can do 
the following:

    for line in file:
       print line # or whatever

jb







-----------------------------------------------------------------------------------
Post ID:2764
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-10-19 20:03:21
Subject:ANN: Tutorial on Building XML-Based Web Services
Message:

Hi Folks,

I have created a step-by-step guide to building XML-based Web Services. 
The tutorial employs the REST architectural style.

Here is the online, HTML version of the tutorial:

    http://www.xfront.com/WS/XML-based-Web-Services.html

Here is the web page to download a zip file containing the tutorial
along with all the XML documents, stylesheets, database, labs, etc
(warning: the zip file is big! --> 50MB):

    http://www.xfront.com/XML-based-Web-Services.html


/Roger







-----------------------------------------------------------------------------------
Post ID:2765
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-19 22:38:37
Subject:Re: [rest-discuss] ANN: Tutorial on Building XML-Based Web Services
Message:

----- Original Message -----
From: "Roger L. Costello" <costello@...>

>
> Here is the online, HTML version of the tutorial:
>
>     http://www.xfront.com/WS/XML-based-Web-Services.html
>
Neat. (although it would be nice if the text were text and not a graphic)
A few comments.

In general
I'd like to see some discussion of why providing machine-to-machine access
through a SQL connection is a Bad Thing. Or is it?

Slide 39 of 136
You might mention that a different app may want to return some amount of
metadata, rather than requiring another request for each line item.
Otherwise you might have a query explosion. If it turns out to be a
problem - just adjust the 'listing' format to include metadata, or have
another resource with slightly a 'deeper' view over the information.

Slide 54 of 136
You may want to mention that alternate approaches to getting XML from an
RDBMS would not need an extra transformation step. This is - once again - an
optimization/performance issue.








-----------------------------------------------------------------------------------
Post ID:2766
Sender:"Peter Drayton" <peter@...>
Post Date/Time:2002-10-23 16:25:56
Subject:RESTful SOAP presentation
Message:

Hi all,

At the recent Web Services DevCon I did a talk on REST & SOAP, and how
they can be combined in a RESTful manner. The slides are at [1] - I'd be
interested in any feedback this group has to help me improve the talk. 

Thanks especially to all the participants in this group (which I've been
lurking in for ages now :-)) for helping to shape my thinking on REST &
SOAP. I'm hoping that RESTful SOAP will start to gain traction as people
figure out that REST & SOAP can be complimentary and that RESTian
thinking contains some important ideas.

--Peter
http://www.razorsoft.net/weblog
http://staff.develop.com/peterd

[1] http://www.razorsoft.net/weblog/2002/10/22.html#a362







-----------------------------------------------------------------------------------
Post ID:2767
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-10-23 16:49:27
Subject:Re: [rest-discuss] RESTful SOAP presentation
Message:

Any chance of converting powerpoint to html so those of us without 
powerpoint can look at the slides too.

--Chuck

Peter Drayton wrote:

>Hi all,
>
>At the recent Web Services DevCon I did a talk on REST & SOAP, and how
>they can be combined in a RESTful manner. The slides are at [1] - I'd be
>interested in any feedback this group has to help me improve the talk. 
>
>Thanks especially to all the participants in this group (which I've been
>lurking in for ages now :-)) for helping to shape my thinking on REST &
>SOAP. I'm hoping that RESTful SOAP will start to gain traction as people
>figure out that REST & SOAP can be complimentary and that RESTian
>thinking contains some important ideas.
>
>--Peter
>http://www.razorsoft.net/weblog
>http://staff.develop.com/peterd
>
>[1] http://www.razorsoft.net/weblog/2002/10/22.html#a362
>
>
>
>To unsubscribe from this group, send an email to:
>rest-discuss-unsubscribe@yahoogroups.com
>
> 
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
>








-----------------------------------------------------------------------------------
Post ID:2768
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-23 16:55:36
Subject:Re: [rest-discuss] RESTful SOAP presentation
Message:

----- Original Message -----
From: "Peter Drayton" <peter@...>

> At the recent Web Services DevCon I did a talk on REST & SOAP, and how
> they can be combined in a RESTful manner. The slides are at [1] - I'd be
> interested in any feedback this group has to help me improve the talk.

Any chance I could get a representation of this resource in an HTML format
(or text, or XML, or something)?







-----------------------------------------------------------------------------------
Post ID:2769
Sender:"Peter Drayton" <peter@...>
Post Date/Time:2002-10-23 17:21:53
Subject:RE: [rest-discuss] RESTful SOAP presentation
Message:

Certainly! I've just posted PDF [1] & HTML [2] versions as well. Note
that there's a small animation [3] on slide 3, which gets mangled in the
PDF & static HTML versions - either use the PPT itself, or the
"slideshow" option on the HTML version if you care. 

--Peter

[1] http://www.razorsoft.net/slides/RESTfulSOAP.pdf
[2] http://www.razorsoft.net/slides/RESTfulSOAP/RESTfulSOAP.htm
[3] The animation is 2 circles, one labelled HTML and one labelled
OO/RPC, representing the 2 distinct worlds that application developers
tended to fall into in the mid-90s. The labels then change to REST and
SOAP, representing the evolution of the two viewpoints (My assertion is
if you're an HTML & Web App person, REST seems natural. Similarly, if
you're used to DCOM, CORBA, etc. SOAP seems fine & dandy). The circles
then move to overlap partially, and a question-mark appear in the
overlap area. This represents the point of intersection of the 2 models,
which is also one of the pain points. I don't believe this is a
coincidence. The thesis for my talk is that this area of intersection
(called RESTful SOAP) is actually a good thing, as it provides an
opportunity for SOAP to learn valuable architectural lessons from REST,
and an opportunity for REST to benefit from SOAP's widespread acceptance
among corporate developers.

> -----Original Message-----
> From: Chuck Hinson [mailto:cmhinson@...] 
> Sent: Wednesday, October 23, 2002 9:49 AM
> To: Peter Drayton
> Cc: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] RESTful SOAP presentation
> 
> 
> Any chance of converting powerpoint to html so those of us without 
> powerpoint can look at the slides too.
> 
> --Chuck
> 
> Peter Drayton wrote:
> 
> >Hi all,
> >
> >At the recent Web Services DevCon I did a talk on REST & 
> SOAP, and how
> >they can be combined in a RESTful manner. The slides are at 
> [1] - I'd be
> >interested in any feedback this group has to help me improve 
> the talk. 
> >
> >Thanks especially to all the participants in this group 
> (which I've been
> >lurking in for ages now :-)) for helping to shape my 
> thinking on REST &
> >SOAP. I'm hoping that RESTful SOAP will start to gain 
> traction as people
> >figure out that REST & SOAP can be complimentary and that RESTian
> >thinking contains some important ideas.
> >
> >--Peter
> >http://www.razorsoft.net/weblog
> >http://staff.develop.com/peterd
> >
> >[1] http://www.razorsoft.net/weblog/2002/10/22.html#a362
> >
> >
> >------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> >Get 128 Bit SSL Encryption!
> >http://us.click.yahoo.com/JjlUgA/vN2EAA/kG8FAA/W6uqlB/TM
> >-------------------------------------------------------------
> --------~->
> >
> >To unsubscribe from this group, send an email to:
> >rest-discuss-unsubscribe@yahoogroups.com
> >
> > 
> >
> >Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> >
> 
> 
> 







-----------------------------------------------------------------------------------
Post ID:2770
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-10-23 19:33:58
Subject:Re: [rest-discuss] RESTful SOAP presentation
Message:

Thanks for the presentation Peter, it was most excellent.

Some comments below ...

On Wed, Oct 23, 2002 at 10:21:53AM -0700, Peter Drayton wrote:
> [3] The animation is 2 circles, one labelled HTML and one labelled
> OO/RPC, representing the 2 distinct worlds that application developers
> tended to fall into in the mid-90s. The labels then change to REST and
> SOAP, representing the evolution of the two viewpoints (My assertion is
> if you're an HTML & Web App person, REST seems natural. Similarly, if
> you're used to DCOM, CORBA, etc. SOAP seems fine & dandy). The circles
> then move to overlap partially, and a question-mark appear in the
> overlap area. This represents the point of intersection of the 2 models,
> which is also one of the pain points. I don't believe this is a
> coincidence. The thesis for my talk is that this area of intersection
> (called RESTful SOAP) is actually a good thing, as it provides an
> opportunity for SOAP to learn valuable architectural lessons from REST,
> and an opportunity for REST to benefit from SOAP's widespread acceptance
> among corporate developers.

I think you did a good job in the presentation of staying away from
suggesting that the term "SOAP" suggested a use, but here you appear to
do just that.

SOAP is certainly well deployed, but the problem is that "SOAP" means
"RPC" (either explicitly or implicitly) to practically everybody who
uses it.  And while I'm all for using SOAP with REST - indeed, I spent
a substantial amount of time and my own money in the XMLP WG ensuring
that I could - I don't think that "widespread acceptance" is sufficient
when it's being misused.  We need a *MASSIVE* educational campaign to
fix this.  And IMO, it's too late; just look at all the secondary specs
written by the supposed *gurus* of Web services; chroeography,
transactions, coordination.  All crap.  If these people don't understand
the mistake they're making, how will a regular developer?

Like you, about a year ago I was still optimistic that SOAP had a
chance because I expected more people to recognize the error of their
ways by now.  I've since given up.  Already people are asking "Where
are the Web services?" - that question will be asked more and more in
the coming year, until finally, nobody cares.

P.S.  I think the circles are concentric, with REST's circle being of
radius X, and SOAP's being of radius X*1.01.

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2771
Sender:"Donald Ball" <dball@...>
Post Date/Time:2002-10-23 20:26:50
Subject:How to handle in a RESTful fashion?
Message:

I'm trying to develop a webapp in a RESTful fashion, but recently ran into
a conundrum that I'm hoping y'all can help me solve. I've already scoured
the wiki and the white papers but don't see any specific advice for my
situation.

The webapp is framed (not necessarily my choice, but it's also not
necessarily a bad choice for it either). The left frame contains an
explorer-type folder tree containing essentially the names of columns in a
database table. The right frame is a content pane. When the user selects a
column from the tree, the column's values should be added to a table in the
content frame. Selecting another column from the tree adds more columns to
the table.

Question is, how do I make all of this happen in a RESTful fashion? Is it,
in fact, even possible given our design constraints? The links in the tree
are going to have to be of the form:

GET /viewer?column=foo

on the server-side, when processing such a request, we add the requested
column to a session variable and render the new table. But the URL for the
table frame is going to be incorrect after a couple such requests. If the
user were to bookmark the URL and revisit it later, they would get a table
with only the last column that was added. Clearly, that's not RESTful.

I was idly wondering, would it be RESTful if the server-side piece that
adds the requested column to the session variable were to redirect the
browser to a URL for the table that was, well, unique? e.g.

/viewer?column=foo&column=bar&column=bat

Alternately, would it be RESTful if the server-side piece were to create a
named resource which stores the state of the table and return a URL to that
resource? e.g.

/viewer?table=23

Or is there another, better possibility that would make for a cleaner, more
RESTful urlspace?

- donald








-----------------------------------------------------------------------------------
Post ID:2772
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-24 02:39:21
Subject:Re: [rest-discuss] How to handle in a RESTful fashion?
Message:

----- Original Message -----
From: "Donald Ball" <dball@...>

>
> Or is there another, better possibility that would make for a cleaner,
more
> RESTful urlspace?

Two possiblities

a) use client-side state for the set of column selected
If the left panel has a list of db columns, and each were a checkbox in a
form, auto-submit the form when a checkbox is checked, and have the form use
method=GET. This will cause a URL to be generated of the format
?col1=on&col3=on&col7=on
This URI identifies a resource which is that particular permutation of
column names. This can be easily rendered into HTML
Of course, using a FORM literally might not be the most chrome looking UI,
so let your script kiddies go nuts.

b) use persistent data on the server to maintain state
If this information should be long-lived, have the server maintain a URI
that doesn't change and is unique for that user (in the same sense that a
session variable is unique to a user). When the left hand panel POSTs data
to that URI, keep updating the selected columns and return a representation
of the table with the users current set of selected columns.
This is nice if the purpose of the app is to later use that selected 'db
view' in some way - perhaps to modify attributes (like 'max rows' or
something), as well as this approach makes that 'db view' an identifable
concept so you could do something like 'show me db #2 with view #27'

mike






-----------------------------------------------------------------------------------
Post ID:2773
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-24 04:04:20
Subject:Fw: How to handle in a RESTful fashion?
Message:

Forwarded...

----- Original Message ----- 
From: "firepipe_au" <michael@...>
To: "S. Mike Dierken" <mdierken@...>
Sent: Wednesday, October 23, 2002 8:50 PM
Subject: Re: How to handle in a RESTful fashion?


> --- In rest-discuss@y..., "S. Mike Dierken" <mdierken@h...> wrote:
> > 
> > ----- Original Message -----
> > From: "Donald Ball" <dball@r...>
> > 
> > >
> > > Or is there another, better possibility that would make for a 
> cleaner,
> > more
> > > RESTful urlspace?
> > 
> > Two possiblities
> > 
> > a) use client-side state for the set of column selected
> > If the left panel has a list of db columns, and each were a 
> checkbox in a
> > form, auto-submit the form when a checkbox is checked, and have the 
> form use
> > method=GET. This will cause a URL to be generated of the format
> > ?col1=on&col3=on&col7=on
> > This URI identifies a resource which is that particular permutation 
> of
> > column names. This can be easily rendered into HTML
> > Of course, using a FORM literally might not be the most chrome 
> looking UI,
> > so let your script kiddies go nuts.
> 
> As the parameters that you're passing are always of the same 'type' 
> (a column, here), I'd be inclined to put all selected columns in the 
> one parameter:
> 
> /viewer?columns=foo,bar,bob,harriet
> 
> You can also rewrite your links that update the view:
> 
> heres a link in your control pane that selects the column called foo:
> /viewdb?columns=foo
> this one assumes you have no columns already selected.
> 
> when you update the view pane, you also update the control pane
> so that all of the links are rewritten.  Here's the href for 
> selected a column called bar, with the foo column already selected
> /viewer?columns=foo,bar
> another column called bob has a href like so:
> /viewer?columns=foo,bob
> 
> this way also means that you don't need to maintain state in a
> session variable, which some of the people around here consider a
> bad thing.  Using it or not, however, depends on whether you want to
> maintain a user's view across browser sessions, as Mike mentions 
> below (although as this is entirely a GET scenario, you could
> provide a link that bookmarks a particular view, keeping your 256 
> byte limit in mind.  Your parent frameset would of course have to 
> process that URL to create the control and view panes...)
> 
> 
> 
> > b) use persistent data on the server to maintain state
> > If this information should be long-lived, have the server maintain 
> a URI
> > that doesn't change and is unique for that user (in the same sense 
> that a
> > session variable is unique to a user). When the left hand panel 
> POSTs data
> > to that URI, keep updating the selected columns and return a 
> representation
> > of the table with the users current set of selected columns.
> > This is nice if the purpose of the app is to later use that 
> selected 'db
> > view' in some way - perhaps to modify attributes (like 'max rows' or
> > something), as well as this approach makes that 'db view' an 
> identifable
> > concept so you could do something like 'show me db #2 with view #27'
> > 
> > mike
> 






-----------------------------------------------------------------------------------
Post ID:2774
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-24 05:04:51
Subject:Allaire's discussion of web services
Message:

http://radio.weblogs.com/0113297/stories/2002/09/24/wholisticWebServices.htm
l

This is an interesting read on what some WebServices may grow into.

"The original idea of "software as service" emerged before the current hype
around web services. It was the notion that applications would run in the
network. That the user interface could be downloaded and used on the fly on
any Internet-connected device (most likely a PC), and that substantial
portions of the application --- in particular those that were focused on
logic and data --- could be exposed and used by other applications easily.

I love the idea of being able to use a high-quality, desktop-like,
media-rich software application over the Internet --- to have a means to
have that application cached on my local computer; to work offline; to
synchronize new versions when needed, and the ability to easily consume and
integrate logic and data in other applications on the network. "

This is a concise description of the kinds of problems that REST-based
systems are good at solving.
Forget the HTML/browser mess that we have today - build for the future.
Solve these problems with clean design and strong automation capabilities.






-----------------------------------------------------------------------------------
Post ID:2775
Sender:"Uday .S" <kumarudaya@...>
Post Date/Time:2002-10-24 14:03:52
Subject:Implemented REST interface to OASIS ebxml-rr
Message:

Dear REST'ers,
     I am happy to share the news with you all that very recently I implemented the REST interface to the open source ebxml registry/repository.This REST binding is a v3.0 feature.
you can find the announcement@
http://www.geocrawler.com/lists/3/SourceForge/21818/0/9957605/
The project home page is,
http://ebxmlrr.sf.net

If you have any question about the usage of the product,you can send email to: 'ebxmlrr-tech@...'

Thanks,
-Uday.









-----------------------------------------------------------------------------------
Post ID:2776
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-25 16:12:22
Subject:OSAF - a new open source p2p PIM
Message:

I'm not sure everybody had heard about this, but Mitch Kapor is starting a
group to build an open source PIM - email, contacts, schedule, etc.
It's going to be a P2P client app and all information items will be URI
addressable and that is where the REST crowd may be interested - we can
watch the growth of and possibly help a URI based design for a potentially
large-scale networked application.

It'll have RDF, Python, Jabber, etc. technology, so I'm sure PaulP will be
all over that...






-----------------------------------------------------------------------------------
Post ID:2777
Sender:"Donald Ball" <dball@...>
Post Date/Time:2002-10-28 15:56:46
Subject:Re: [rest-discuss] How to handle in a RESTful fashion?
Message:

>a) use client-side state for the set of column selected
>If the left panel has a list of db columns, and each were a checkbox in a
>form, auto-submit the form when a checkbox is checked, and have the form
>use
>method=GET. This will cause a URL to be generated of the format
>?col1=on&col3=on&col7=on
>This URI identifies a resource which is that particular permutation of
>column names. This can be easily rendered into HTML
>Of course, using a FORM literally might not be the most chrome looking UI,
>so let your script kiddies go nuts.

Can't / don't want to reload this frame every time the link is checked.
It's a big tree and somewhat expensive to render. Could use javascript to
generate the links on the fly, but that's also not necessarily desirable
from a RESTful pov.

>b) use persistent data on the server to maintain state
>If this information should be long-lived, have the server maintain a URI
>that doesn't change and is unique for that user (in the same sense that a
>session variable is unique to a user). When the left hand panel POSTs data
>to that URI, keep updating the selected columns and return a
representation
>of the table with the users current set of selected columns.
>This is nice if the purpose of the app is to later use that selected 'db
>view' in some way - perhaps to modify attributes (like 'max rows' or
>something), as well as this approach makes that 'db view' an identifable
>concept so you could do something like 'show me db #2 with view #27'

I think that's the one I'd like to run with. Question is, what do the
mechanics look like? When adding a column to a view, I issue a request
something like:

GET /view?task=add&var=foo

then I redirect the user to:

/view?id=23

which is the long-lived URL for the dataset view they're constructing. This
solution isn't entirely RESTful for two reasons, though, I think:

1. I'm not specifying the view id in the change request. Due to the fact
that I don't want to regenerate the link tree, though, this is largely
unavoidable. I'll just store the user's active view id in their session,
but always redirect them to a URL which they can use absent a session.

2. I should be using a POST request when changing the dataset view. There
are two reasons why I can't/shouldn't though:

  a. The change request is activated by a link, which can't issue a POST
request unless use javascript links

  b. You're not supposed to issue a redirect from a POST request

Any thoughts on either the proposed solution or the (nitpicky) problems I
see in the solution?

- donald







-----------------------------------------------------------------------------------
Post ID:2778
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-28 17:25:51
Subject:Re: [rest-discuss] How to handle in a RESTful fashion?
Message:

----- Original Message -----
From: "Donald Ball" <dball@...>
To: <rest-discuss@yahoogroups.com>
Sent: Monday, October 28, 2002 7:56 AM
Subject: Re: [rest-discuss] How to handle in a RESTful fashion?


> >a) use client-side state for the set of column selected
> >If the left panel has a list of db columns, and each were a checkbox in a
> >form, auto-submit the form when a checkbox is checked, and have the form
> >use
> >method=GET. This will cause a URL to be generated of the format
> >?col1=on&col3=on&col7=on
> >This URI identifies a resource which is that particular permutation of
> >column names. This can be easily rendered into HTML
> >Of course, using a FORM literally might not be the most chrome looking
UI,
> >so let your script kiddies go nuts.
>
> Can't / don't want to reload this frame every time the link is checked.
> It's a big tree and somewhat expensive to render.
You don't re-load the frame on the left, you use <form target='panel_right'
> to reload the panel on the right.

> Could use javascript to generate the links on the fly, but that's also not
necessarily desirable
> from a RESTful pov.
You are in a classical browser, you aren't going to get very far into REST
land that way.
Serve the user first, and the architecture second.

>
> >b) use persistent data on the server to maintain state
> >If this information should be long-lived, have the server maintain a URI
> >that doesn't change and is unique for that user (in the same sense that a
> >session variable is unique to a user). When the left hand panel POSTs
data
> >to that URI, keep updating the selected columns and return a
> representation
> >of the table with the users current set of selected columns.
> >This is nice if the purpose of the app is to later use that selected 'db
> >view' in some way - perhaps to modify attributes (like 'max rows' or
> >something), as well as this approach makes that 'db view' an identifable
> >concept so you could do something like 'show me db #2 with view #27'
>
> I think that's the one I'd like to run with. Question is, what do the
> mechanics look like? When adding a column to a view, I issue a request
> something like:
>
> GET /view?task=add&var=foo
No, no, no. Did I mention, no? Do not do an 'update' with a GET.
If you have a single view that you add names to over time, then the requests
will go to the /same uri/ - so don't put things in the query terms (it is
part of the URI).
You will want something like:

====
// request #1
POST /view?task=add
Content-Type: application/x-www-form-urlencoded

var=foo

// request #2
POST /view?task=add
Content-Type: application/x-www-form-urlencoded

var=bar

=====
Notice how the same URI is used twice. That is because the same resource is
updated twice. Also, notice that the URI that is being used isn't all that
great - all users would be appending column names all day long. You need to
get some qualifying information intothe URI - either the userID, the viewID,
or something.


>
> then I redirect the user to:
>
> /view?id=23
>
> which is the long-lived URL for the dataset view they're constructing.
This
> solution isn't entirely RESTful for two reasons, though, I think:
>
> 1. I'm not specifying the view id in the change request. Due to the fact
> that I don't want to regenerate the link tree, though, this is largely
> unavoidable. I'll just store the user's active view id in their session,
> but always redirect them to a URL which they can use absent a session.
Tell me again why using a viewId causes the tree to change?

>
> 2. I should be using a POST request when changing the dataset view. There
> are two reasons why I can't/shouldn't though:
>
>   a. The change request is activated by a link, which can't issue a POST
> request unless use javascript links
Causing updates on the server via a link is to be avoided. I know it would
be really nice to do this, but you need to avoid this anyway.
If you really want that kind of silent update, use javascript. If you use
checkboxes and send the form on each click, then you'll know when the user
de-selects a column. Clicking links won't allow you do de-select columns.

>
>   b. You're not supposed to issue a redirect from a POST request
There are two different response status codes - one means 'request
finished - see this link for results', the other means 'request not
processed - try again at this location'.
Why aren't you supposed to redirect from a POST?









-----------------------------------------------------------------------------------
Post ID:2779
Sender:"Donald Ball" <dball@...>
Post Date/Time:2002-10-28 18:52:17
Subject:Re: [rest-discuss] How to handle in a RESTful fashion?
Message:

>> >a) use client-side state for the set of column selected
>> >If the left panel has a list of db columns, and each were a checkbox in
>a
>> >form, auto-submit the form when a checkbox is checked, and have the
form
>> >use
>> >method=GET. This will cause a URL to be generated of the format
>> >?col1=on&col3=on&col7=on
>> >This URI identifies a resource which is that particular permutation of
>> >column names. This can be easily rendered into HTML
>> >Of course, using a FORM literally might not be the most chrome looking
>UI,
>> >so let your script kiddies go nuts.
>>
>> Can't / don't want to reload this frame every time the link is checked.
>> It's a big tree and somewhat expensive to render.
>You don't re-load the frame on the left, you use <form
target='panel_right'
>> to reload the panel on the right.

I take your point, if the thing on the left was a form with checkboxes, but
UI constraints dictate that it's an explorer tree with links. c'e la vie.

>> Could use javascript to generate the links on the fly, but that's also
>not
>necessarily desirable
>> from a RESTful pov.
>You are in a classical browser, you aren't going to get very far into REST
>land that way.
>Serve the user first, and the architecture second.

I think the REST architecture principles have just as much to offer
traditional HTML webapps as new-fangled XML web services. But that's beside
the point.

>> I think that's the one I'd like to run with. Question is, what do the
>> mechanics look like? When adding a column to a view, I issue a request
>> something like:
>>
>> GET /view?task=add&var=foo
>No, no, no. Did I mention, no? Do not do an 'update' with a GET.
>If you have a single view that you add names to over time, then the
>requests
>will go to the /same uri/ - so don't put things in the query terms (it is
>part of the URI).

So you're of the opinion that, given the design constraints, it would be
preferable to massage the requests to POSTs using javascript than to issue
GET requests without relying on javascript?

>You will want something like:
>
>====
>// request #1
>POST /view?task=add
>Content-Type: application/x-www-form-urlencoded
>
>var=foo
>
>// request #2
>POST /view?task=add
>Content-Type: application/x-www-form-urlencoded
>
>var=bar
>
>=====
>Notice how the same URI is used twice. That is because the same resource
is
>updated twice. Also, notice that the URI that is being used isn't all that
>great - all users would be appending column names all day long. You need
to
>get some qualifying information intothe URI - either the userID, the
>viewID,
>or something.

unless the semantics for the /view URL dictate that, absent a specific
identifier, the current view for the user is the one being modified. Is
that legit from a REST pov?

>> 1. I'm not specifying the view id in the change request. Due to the fact
>> that I don't want to regenerate the link tree, though, this is largely
>> unavoidable. I'll just store the user's active view id in their session,
>> but always redirect them to a URL which they can use absent a session.
>Tell me again why using a viewId causes the tree to change?

because I don't know the view id until the user has created one by clicking
on a link in the tree. It would be undesirable for a couple of other
reasons as well, actually.

>> 2. I should be using a POST request when changing the dataset view.
There
>> are two reasons why I can't/shouldn't though:
>>
>>   a. The change request is activated by a link, which can't issue a POST
>> request unless use javascript links
>Causing updates on the server via a link is to be avoided. I know it would
>be really nice to do this, but you need to avoid this anyway.
>If you really want that kind of silent update, use javascript. If you use
>checkboxes and send the form on each click, then you'll know when the user
>de-selects a column. Clicking links won't allow you do de-select columns.

Once a column is in the active dataset view, there are a number of things
that can be done to the column in the view frame, including removing it
from the dataset.

>>   b. You're not supposed to issue a redirect from a POST request
>There are two different response status codes - one means 'request
>finished - see this link for results', the other means 'request not
>processed - try again at this location'.
>Why aren't you supposed to redirect from a POST?

I had been given to understand that it was technically not allowed
according to the HTTP spec, but as it turns out, that's untrue. It _is_
true that browsers are supposed to verify a redirect request with a user if
the server issues a 302 or a 307 in response to a POST (although none do,
it would seem), but HTTP/1.1 added a 303 response which is suitable for
redirects from POST requests. Doesn't work with NN4, but 302 is an
acceptable fallback.

So the upshot seems to be that, given my constraints, the links in the
explorer should silently turn into POST requests, which send back 303
redirects to a long-lived URL for the dataset view. I can live with that,
thanks for the conversation.

- donald







-----------------------------------------------------------------------------------
Post ID:2780
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-10-28 19:21:57
Subject:Re: [rest-discuss] How to handle in a RESTful fashion?
Message:

----- Original Message -----
From: "Donald Ball" <dball@...>

> >You don't re-load the frame on the left, you use <form
> target='panel_right'
> >> to reload the panel on the right.
>
> I take your point, if the thing on the left was a form with checkboxes,
but
> UI constraints dictate that it's an explorer tree with links. c'e la vie.
Use a hidden frame with a form to send control messages. The onClick for the
link calls script that submits a non-visible form in a zero or one pixel
high frame. This can be used to communicate with the server without bumping
into UI/presentation issues.


>
> So you're of the opinion that, given the design constraints, it would be
> preferable to massage the requests to POSTs using javascript than to issue
> GET requests without relying on javascript?
If doing a GET modifies data on the server, then I would use POST - even if
that means using script on the client.
What happens if the user clicks the same link twice?
How does a user remove the column name from the view?
What happens when a spider crawls the link?
What happens when a user bookmarks a link or drags the link to their
desktop?
What does the user see when they click link A, then link B, then link A? The
second time they click link A they won't see the same as the first time they
clicked on link A - it'll look like they are still on link B.

>
> unless the semantics for the /view URL dictate that, absent a specific
> identifier, the current view for the user is the one being modified. Is
> that legit from a REST pov?
No. The resource identifier should identify the same resource for all
clients.
If you generate the HTML for the tree control with href= links that have the
userid in a query term, then that isn't a problem.
It makes the HTML slightly larger though.

>
> >> 1. I'm not specifying the view id in the change request. Due to the
fact
> >> that I don't want to regenerate the link tree, though, this is largely
> >> unavoidable. I'll just store the user's active view id in their
session,
> >> but always redirect them to a URL which they can use absent a session.
> >Tell me again why using a viewId causes the tree to change?
>
> because I don't know the view id until the user has created one by
clicking
> on a link in the tree. It would be undesirable for a couple of other
> reasons as well, actually.
What about always having a view ID for each user - even if it is empty.
The tree would always have that URI in the href= links.


> So the upshot seems to be that, given my constraints, the links in the
> explorer should silently turn into POST requests, which send back 303
> redirects to a long-lived URL for the dataset view. I can live with that,
> thanks for the conversation.

No problem. But this conversation is like many I've had when designing
systems in the past.
It's also very indicative of why I believe that REST based resource
modelling is best suited for 'automation' based Web systems and classical UI
based systems with existing browsers & server technology just run into too
many issues that are counter to good REST based design. Essentially I
believe that usability requirements (projected onto browsers and their use
of HTTP) conflict with REST principles projected onto HTTP.

So, it's okay to strive for RESTfulness with HTML and browsers, but don't
sweat the (sometimes major) conflicts that are going to pop up.








-----------------------------------------------------------------------------------
Post ID:2781
Sender:Michael Smith <michaelsmith@...>
Post Date/Time:2002-11-04 21:11:44
Subject:[rest-discuss] Groove Web Services
Message:

http://www.infoworld.com/articles/pl/xml/02/11/04/021104plgroove.xml

I've just read this article on the upcoming Groove web services
interfaces. It talks about how Groove have tried to create a RESTful
interface using SOAP/WSDL and that the result is an "exceptionally
elegant and productive Web services API".

Then I read that;
"It's all organized as a web of linked XML documents controlled by a
handful of verbs such as Create, Read, Update, and Delete." !

They really seem to have grasped the value of uri-addressable resources
represented in xml, accessed using a small number of standardised methods.
So what did they need SOAP for ?
I have to hope that their next step is to make SOAP optional. Or will
they continue, and start reinventing http-caching.

Any thoughts ?
Michael Smith.








-----------------------------------------------------------------------------------
Post ID:2782
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-05 02:25:39
Subject:Re: [rest-discuss] Groove Web Services
Message:

On Mon, Nov 04, 2002 at 09:11:44PM +0000, Michael Smith wrote:
> Then I read that;
> "It's all organized as a web of linked XML documents controlled by a
> handful of verbs such as Create, Read, Update, and Delete." !
> 
> They really seem to have grasped the value of uri-addressable resources
> represented in xml, accessed using a small number of standardised methods.
> So what did they need SOAP for ?
> I have to hope that their next step is to make SOAP optional. Or will
> they continue, and start reinventing http-caching.
> 
> Any thoughts ?

It sounds just like Hailstorm/My-Services.  I think their protocol was
called HSML or something, but was basically CRUD (in more ways than
one).

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2783
Sender:Phil Eskelin <philip.eskelin@...>
Post Date/Time:2002-11-05 16:24:36
Subject:RE: [rest-discuss] Groove Web Services
Message:

Michael wrote:
> Then I read that;
> "It's all organized as a web of linked XML documents controlled by a
> handful of verbs such as Create, Read, Update, and Delete." !
> 
> They really seem to have grasped the value of uri-addressable resources
> represented in xml, accessed using a small number of standardised methods.
> So what did they need SOAP for ?
> I have to hope that their next step is to make SOAP optional. Or will
> they continue, and start reinventing http-caching.
> 
> Any thoughts ?

When there was buzz around P2P, and Groove was the first mover, I really
thought Groove would be the "Netscape" of the P2P wave.  After downloading
and attempting to use it, I found that it was worth the space it took on my
hard disk, so I removed it.  My sense was that it was more hype than
anything.

Regarding Groove Web Services, my thought is that their interface may in
fact be very RESTful, but the sentence you quote above leads me to believe
that nothing has changed - more hype than anything.  A REST developer who
*really* got it would call them like they are: GET, PUT, POST, and DELETE.
And that same developer would know that SOAP was irrelevant.

Philip

________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.






-----------------------------------------------------------------------------------
Post ID:2784
Sender:Phil Eskelin <philip.eskelin@...>
Post Date/Time:2002-11-05 16:29:08
Subject:RE: [rest-discuss] Groove Web Services
Message:

I wrote:
> After downloading and attempting to use it, I found that it was
> worth the space it took on my hard disk, so I removed it.  My
> sense was that it was more hype than anything.

I meant that it was *not* worth the space it took on my hard drive.  I don't
know what others thought, and I don't mean to venture off-topic, but it was
a classic example of a tight, simple concept gone overbloated and
overcomplicated.

Philip

________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.






-----------------------------------------------------------------------------------
Post ID:2785
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-11-05 17:16:17
Subject:Re: [rest-discuss] Groove Web Services
Message:

From: "Phil Eskelin" <philip.eskelin@...>
>
> Regarding Groove Web Services, my thought is that their interface may in
> fact be very RESTful, but the sentence you quote above leads me to believe
> that nothing has changed - more hype than anything.  A REST developer who
> *really* got it would call them like they are: GET, PUT, POST, and DELETE.
> And that same developer would know that SOAP was irrelevant.

All other arguments aside, I strongly disagree that a REST developer would
only get it right if they were to use HTTP verbs.  HTTP verbs have specific,
limited meanings that are not necessarily a good match with the Groove Web
Services.  It is just as RESTful to create ones own set of verbs that
actually provide the exact functionality needed.  While I admit that HTTP
(and its verbs) is fairly prolific, it is not the "be all, end all" of web
protocols.  While HTTP is RESTful, not all things RESTful are HTTP.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2786
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-05 17:32:08
Subject:Re: [rest-discuss] Groove Web Services
Message:

On Tue, Nov 05, 2002 at 12:16:17PM -0500, Seairth Jacobs wrote:
> It is just as RESTful to create ones own set of verbs that
> actually provide the exact functionality needed.

No it isn't.  You've been here long enough to know that Seairth! 8-O
With REST, you're constrained to using methods that you could use on
anything.  So "CREATE" isn't a REST method, because I don't know what
it would mean to invoke that on a URI identifying a stock quote.

This is a severe constraint on *form*, but does not in any way constrain
*function*. i.e. every problem has a solution with a system built with
this constraint in mind.

> While HTTP is RESTful, not all things RESTful are HTTP.

That's true, but largely irrelevant today; it's all we've got that is.

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2787
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-11-05 18:06:38
Subject:Security and REST
Message:

Hi,

I'm just wondering about the interplay of authorization with
resource space when developing web applications.  Is there anything
un-RESTful about constraining resources implicitly based on the
user's authenticated identity?  It makes me uneasy, but I'm not sure
why.

Let's say we have a simple DBMS-based application that relates
Users to Products and allows, say, a subscription mechanism to build
more such bindings and a cancellation mechanism to break them
down.  Now we want the users to subscribe and unsubscribe themselves,
and we want to expose this through a web interface.  A User ought
to be able to manage his own space without constraint, but should
not be able to see or change other Users' subscriptions.  Therefore,
we need to authenticate users and authorize their activities based
on their identity.

What happens if there is a resource, say /Subscriptions, that spans
many users, and one particular user, with authentication, wants to
dereference that?  One answer is that because part of /Subscriptions
is out of bounds of that user, the entire resource is "Unauthorized".
Another answer is that the representation given to a user is filtered, based
on his authenticated identity.  In that case, two different users
accessing /Subscriptions via GET will see disjoint subsets of the
resource.  By extension, an entire resource schema (application) may
be implicitly constrained by the security properties of the access.

What does REST have to say about this, if anything?

Walden Mathews
MIS Special Projects
Sales, Trading and Wealth Management
Thomson Financial 
Voice (212) 510-3121
Fax (212) 732-7191






-----------------------------------------------------------------------------------
Post ID:2788
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-11-05 19:09:32
Subject:Re: [rest-discuss] Groove Web Services
Message:

From: "Mark Baker" <distobj@...>
>
> On Tue, Nov 05, 2002 at 12:16:17PM -0500, Seairth Jacobs wrote:
> > It is just as RESTful to create ones own set of verbs that
> > actually provide the exact functionality needed.
>
> No it isn't.  You've been here long enough to know that Seairth! 8-O
> With REST, you're constrained to using methods that you could use on
> anything.  So "CREATE" isn't a REST method, because I don't know what
> it would mean to invoke that on a URI identifying a stock quote.

Huh?  This is the first time I've heard that all RESTful methods must be
usable on *anything*.  All I understood of REST was that you should use a
few, generic methods.  Within the domain that Groove is functioning, their
choice of methods are RESTful.

*sigh* Just when I thought that I understood this REST thing...

> This is a severe constraint on *form*, but does not in any way constrain
> *function*. i.e. every problem has a solution with a system built with
> this constraint in mind.
>
> > While HTTP is RESTful, not all things RESTful are HTTP.
>
> That's true, but largely irrelevant today; it's all we've got that is.

If it is largely irrelevant today, then why do we talk about REST at all?
Why not just talk about HTTP Best Practices instead?  If HTTP is the only
RESTful thing we will be using for any forseeable future, REST concepts
would get much further if we were to just put it aside and get people to
focus on HTTP...

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2789
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-05 19:41:03
Subject:Re: [rest-discuss] Groove Web Services
Message:

On Tue, Nov 05, 2002 at 02:09:32PM -0500, Seairth Jacobs wrote:
> > No it isn't.  You've been here long enough to know that Seairth! 8-O
> > With REST, you're constrained to using methods that you could use on
> > anything.  So "CREATE" isn't a REST method, because I don't know what
> > it would mean to invoke that on a URI identifying a stock quote.
> 
> Huh?  This is the first time I've heard that all RESTful methods must be
> usable on *anything*.  All I understood of REST was that you should use a
> few, generic methods.  Within the domain that Groove is functioning, their
> choice of methods are RESTful.
> 
> *sigh* Just when I thought that I understood this REST thing...

Oops. 8-(

Yah, that's what "uniform interface" means.  If a method doesn't mean
something to everything you can invoke it on, then it's not uniform!
It's like being restricted to interacting with Java objects by using
java.lang.Object.

The uniform interface constraint is really two constraints in one.
First, there's the constraint that you need to prespecify the methods
you'll use, for visibility and low-coordination cost reasons.  Second,
there's the additional constraint that the interface will be the most
general one possible, which you get by constraining that all methods
are usable on everything.

> > > While HTTP is RESTful, not all things RESTful are HTTP.
> >
> > That's true, but largely irrelevant today; it's all we've got that is.
> 
> If it is largely irrelevant today, then why do we talk about REST at all?
> Why not just talk about HTTP Best Practices instead?  If HTTP is the only
> RESTful thing we will be using for any forseeable future, REST concepts
> would get much further if we were to just put it aside and get people to
> focus on HTTP...

That's what some of us are doing, but it's also useful to focus on REST
to explain how some HTTP related things are broken. e.g. cookies.  Plus,
sometimes it's not obvious from just looking at RFC 2616 why things are
the way they are.  That's where REST helps.  For example, statelessness.

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2790
Sender:Phil Eskelin <philip.eskelin@...>
Post Date/Time:2002-11-05 19:47:28
Subject:RE: [rest-discuss] Groove Web Services
Message:

Mark Baker wrote:
> Seairth Jacobs wrote:
> > It is just as RESTful to create ones own set of verbs that
> > actually provide the exact functionality needed.
> 
> No it isn't.  You've been here long enough to know that Seairth!
> 8-O With REST, you're constrained to using methods that you could
> use on anything.  So "CREATE" isn't a REST method, because I
> don't know what it would mean to invoke that on a URI identifying
> a stock quote.

One of the big benefits that one should receive from taking a RESTful
approach is purification and simplification of an otherwise ugly situation
that will only get uglier.  If Groove uses 'Create', then someone else will
use 'myCreate', then someone else will use hungarian notiation with
'urilstCreate', and then in a few years we circle back to the same recursive
scope creep scenario that led to the creation of SOAP in the first place.
People agreeing on HTTP and its verbs is a key success factor of REST.
 
> This is a severe constraint on *form*, but does not in any way
> constrain *function*. i.e. every problem has a solution with a
> system built with this constraint in mind.

I went back and read the entire article [1], written by Jon Udell at
InfoWorld.  I can't tell if my problem comes from what I perceive as a
writer trying to sound smart, Groove trying to cash in on hype, or from
those who created the notion of RESTful SOAP trying to start a riot.

Udell says GWS is a textbook example of "RESTful SOAP" - is that good or
bad?  To elaborate on what that means, he references the SOAP 1.2 working
draft, saying that URIs should be used as resource identifiers.  DUH!!  Then
comes this paragraph:

   For example, the root of GWS is a SOAP service with an address
   like http://localhost:9080/GWS/Groove/1.0/Accounts. Since a
   Groove account is a container of identities, a Read operation
   on this resource produces an XML document that enumerates them.
   Each identity includes an element like
   /GWS/Groove/1.0/Spaces/grooveIdentity/123...xyz -- that is, the
   URI of the SOAP service that enumerates the shared spaces for
   that identity. Traversal of spaces, tools, and data proceeds
   in a similar fashion. It's all organized as a web of linked
   XML documents controlled by a handful of verbs such as Create,
   Read, Update, and Delete.

First (if I was claiming to be RESTful), I would replace every instance of
'SOAP service' with 'resource'.  Then, I would replace 'Create, Read,
Update, and Delete' with 'PUT, GET, POST, and DELETE'.  To clarify my point,
I might reword the last sentence to say "...web of linked resources accessed
by a handful of verbs that allow you to create, read, update, and delete
them."  I would then elaborate on the connection between a RESTful style and
HTTP and make sure I reference Fielding's thesis.

Philip

1. http://www.infoworld.com/articles/pl/xml/02/11/04/021104plgroove.xml

________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.






-----------------------------------------------------------------------------------
Post ID:2791
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-06 03:54:46
Subject:Re: [rest-discuss] Groove Web Services
Message:

----- Original Message -----
From: "Phil Eskelin" <philip.eskelin@...>

>
> First (if I was claiming to be RESTful), I would replace every instance of
> 'SOAP service' with 'resource'.  Then, I would replace 'Create, Read,
> Update, and Delete' with 'PUT, GET, POST, and DELETE'.  To clarify my
point,
> I might reword the last sentence to say "...web of linked resources
accessed
> by a handful of verbs that allow you to create, read, update, and delete
> them."  I would then elaborate on the connection between a RESTful style
and
> HTTP and make sure I reference Fielding's thesis.

I don't believe that REST depends on those /particular/ operations. Any
self-consistent system can pick whatever small number of operations it
wants. It will only be consistent with itself though, unless it uses the
same operations (with the same meanings, etc) as other systems though.

If your job is to build a system, without regard to interoperability with
other systems, then using those particular operations is a lower priority.
But if you are successful, you will eventually run into them, so you better
be prepared to translate, or just use them from day one.







-----------------------------------------------------------------------------------
Post ID:2792
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-06 04:00:22
Subject:Re: [rest-discuss] Security and REST
Message:

----- Original Message -----
From: "Mathews, Walden" <walden.mathews@...>

>
> What happens if there is a resource, say /Subscriptions, that spans
> many users, and one particular user, with authentication, wants to
> dereference that?  One answer is that because part of /Subscriptions
> is out of bounds of that user, the entire resource is "Unauthorized".
> Another answer is that the representation given to a user is filtered,
based
> on his authenticated identity.  In that case, two different users
> accessing /Subscriptions via GET will see disjoint subsets of the
> resource.  By extension, an entire resource schema (application) may
> be implicitly constrained by the security properties of the access.
>
> What does REST have to say about this, if anything?
>

Cool... filtered views. Good question.
My guess is that with HTTP you might be able to indicate how the response
was dependent on the request - I think the 'vary' header is used for that.
So you could say that the response varies according to the auth header. This
is useful for caching, etc. It essentially creates a 'meta-key' or
'meta-identifier' that can be used to a small degree as an identifier for
the transient representations.







-----------------------------------------------------------------------------------
Post ID:2793
Sender:"Yannick Loiseau" <yloiseau@...>
Post Date/Time:2002-11-06 07:35:29
Subject:Rest Protocol (was Groove Web Services)
Message:

Does anyone had a look at Jabber as a Rest protocol ? It's full XML, based
on few methods (get,set,result,error) for the <iq/> element. I'm quite new
to Rest and very new to Jabber, but it sounds like they could work together
fine.

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>
> If it is largely irrelevant today, then why do we talk about REST at all?
> Why not just talk about HTTP Best Practices instead?  If HTTP is the only
> RESTful thing we will be using for any forseeable future, REST concepts
> would get much further if we were to just put it aside and get people to
> focus on HTTP...
>








-----------------------------------------------------------------------------------
Post ID:2794
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-11-06 12:44:02
Subject:REST achieves hype status (was: Groove etc.)
Message:

Phil Eskelin wrote:
> I went back and read the entire article [1], written by Jon Udell at
> InfoWorld.  I can't tell if my problem comes from what I perceive 
as a
> writer trying to sound smart, Groove trying to cash in on hype...

This development marks the onset of REST as a buzzword.
The pioneers should feel both proud and appalled.

I remember when the same thing happened to patterns,
and objects before that.

A new concept gets promoted, initially adopted by a few
and disdained by many.  If the promoters are successful,
the new concept becomes synonymous with goodness.
Pretty soon everybody wants to claim the goodness.
Unfortunately, many of them only put it on like lipstick.

Next step, a rack of REST books,
some of them based on RPC-oriented SOAP?

But the fact remains, Roy, Mark, Paul and colleagues
have executed a remarkably successful education campaign!
Going from disdain to hype-as-goodness in about a year?








-----------------------------------------------------------------------------------
Post ID:2795
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-11-06 14:45:57
Subject:RE: [rest-discuss] Security and REST
Message:

> ----- Original Message -----
> From: "Mathews, Walden" <walden.mathews@...>
> 
> >
> > What happens if there is a resource, say /Subscriptions, that spans
> > many users, and one particular user, with authentication, wants to
> > dereference that?  One answer is that because part of /Subscriptions
> > is out of bounds of that user, the entire resource is 
> "Unauthorized".
> > Another answer is that the representation given to a user 
> is filtered,
> based
> > on his authenticated identity.  In that case, two different users
> > accessing /Subscriptions via GET will see disjoint subsets of the
> > resource.  By extension, an entire resource schema (application) may
> > be implicitly constrained by the security properties of the access.
> >
> > What does REST have to say about this, if anything?
> >
> 
> Cool... filtered views. Good question.
> My guess is that with HTTP you might be able to indicate how 
> the response
> was dependent on the request - I think the 'vary' header is 
> used for that.
> So you could say that the response varies according to the 
> auth header. This
> is useful for caching, etc. It essentially creates a 'meta-key' or
> 'meta-identifier' that can be used to a small degree as an 
> identifier for
> the transient representations.

Okay, that's ringing a bell (I'm not sure which bell, but one
having to do with shared caches I think), but it doesn't really answer
my question.  My question is whether that sort of filtering
is consistent with the constraints of REST, or whether it violates
the latter in some subtle way that I can't seem to put my finger
on.

Unless you answered that when you said "Cool..".

This has got to be an awfully common pattern in web applications.
Jesus, I've only developed two such, and it's in both!


Walden






-----------------------------------------------------------------------------------
Post ID:2796
Sender:Phil Eskelin <philip.eskelin@...>
Post Date/Time:2002-11-06 15:29:40
Subject:RE: [rest-discuss] REST achieves hype status (was: Groove etc.)
Message:

Bob wrote:
> This development marks the onset of REST as a buzzword.
> The pioneers should feel both proud and appalled.
> 
> I remember when the same thing happened to patterns,
> and objects before that.

Very very true.  Remember requests like 'I need a pattern to search a string
for a token' on patterns-discussion?  Journalists thrive on change, and
often you see them struggle with a new concept when they're early adopters
to a potentially mainstream trend.  In this case, I don't think Udell
struggled with the concept, since in my experience he seems to articulate
new concepts well, but he seems to be stuck somewhere in the gray area
between being a SOAP and REST (clearly anybody who boasts 'RESTful SOAP' is
missing or hiding something).

> Next step, a rack of REST books,
> some of them based on RPC-oriented SOAP?

It must be funny for people browsing in bookstores who are not technical.
First they see patterns, thinking maybe programmers are sewers.  Then they
see SOAP, thinking that programmers finally discovered hygiene.  Now
REST...will they think it's a new form of meditation?  It sort of is, if you
do it right ;-)

> But the fact remains, Roy, Mark, Paul and colleagues
> have executed a remarkably successful education campaign!
> Going from disdain to hype-as-goodness in about a year?

Gush gush gush!  For me, all three have contributed greatly to my
understanding of what I'm doing in my own efforts.  Roy's dissertation
helped me understand the core concepts, but Mark and Paul helped me realize
I needed to refactor and redesign my toolkit a lot more before it was
RESTful enough for release.

Philip

________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.






-----------------------------------------------------------------------------------
Post ID:2797
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-06 20:12:01
Subject:Re: [rest-discuss] REST achieves hype status (was: Groove etc.)
Message:

On Wed, Nov 06, 2002 at 12:44:02PM -0000, bhaugen32 wrote:
> But the fact remains, Roy, Mark, Paul and colleagues
> have executed a remarkably successful education campaign!
> Going from disdain to hype-as-goodness in about a year?

More like two-and-a-half for me.  It was March 2000 when I started the
REST/Web promotion on soap@....  I got one convert out
of that brief stint (though I'm still subscribed), Ken MacLeod. 8-)

Thanks for the kind words.

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2798
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-06 21:23:15
Subject:Re: [rest-discuss] REST achieves hype status (was: Groove etc.)
Message:

(from the thread at http://groups.yahoo.com/group/rest-discuss/message/2781)

bhaugen32 wrote:
>...
> This development marks the onset of REST as a buzzword.
> The pioneers should feel both proud and appalled.

Yes, REST has been quite a buzzword for a while. For some it means "use 
existing Internet infrastructure". For others it means "use few methods, 
whether they are HTTP's or not." For others it means "use lots of URIs."

If people are thinking about the issues enough to misunderstand them, 
that's at least progress. ;)

I'm somewhat confused about how the RESTful SOAP Groove thing will work. 
First, I wonder how they will work around the well-known problems in 
using service URIs in WSDL. Second, I wonder why they would use a READ 
method instead of the GET method embedded in the implementations of 
hundreds of tools and standards, from Xalan to Squid, XPath to the DOM.

My guess is that the answers to those questions are linked. They 
couldn't use HTTP GET because WSDL has such poor support for REST. I 
would guess they've built a REST-a-like on top of a standard 
single-endpoint SOAP services. I would guess that the addressing model 
is *still* broken into domain/port/service-path and resource-path 
whereas the Web has domain/port/resource-path. The 
service-path/resource-path split is still proprietary, just as if 
resource-path was using some kind of proprietary GrooveIDs. And of 
course the method names and semantics are still proprietary to Groove.

If we all do this then we will end up with hundreds of incompatible 
web-alikes.

I understand the position Groove is in: they have to ship software and 
can't wait until WSDL is fixed. And they have to demo Visual Studio.NET 
integration so they can't dump WSDL. Maybe they did the right thing from 
a marketing and sales point of view.

But nevertheless, fans of "RESTful SOAP" should get out there and 
publicize the problems with WSDL so that they will be fixed one day. It 
would be really tragic if five years from now that the REST acronym is 
associated with a design pattern that has been deployed in hundreds of 
incompatible ways in hundreds of incompatible services.

These issues are discussed further here:

  * http://www.blogstream.com/pauls/1032521623/index_html
  * http://www.prescod.net/rest/wsdlhttp.html

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2799
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-11-06 22:24:17
Subject:4xx response codes
Message:

Hi,

To indicate that a POSTed XML file is not valid against a schema, which of
these response codes would be more appropriate:

	400 Bad Request		(HTTP request contains syntax error?)
	403 Forbidden		(I understand, but won't do it?)
	406 Not Acceptable	(You won't like the response?)
	409 Conflict		(Change something, then repeat request?)
	415 Unsupported Media Type	(...)

Any thoughts?

Michael







-----------------------------------------------------------------------------------
Post ID:2800
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-07 01:59:38
Subject:Re: [rest-discuss] 4xx response codes
Message:

On Thu, Nov 07, 2002 at 09:24:17AM +1100, Michael Day wrote:
> 
> Hi,
> 
> To indicate that a POSTed XML file is not valid against a schema, which of
> these response codes would be more appropriate:
> 
> 	400 Bad Request		(HTTP request contains syntax error?)
> 	403 Forbidden		(I understand, but won't do it?)
> 	406 Not Acceptable	(You won't like the response?)
> 	409 Conflict		(Change something, then repeat request?)
> 	415 Unsupported Media Type	(...)
> 
> Any thoughts?

This is a good question, and I have to admit to getting caught by it
on occasion.  I haven't developed a fool proof, simple model yet.

But I'd say that it depends on your application.  If you consider
"invalid document" to be a valid state of your app, then 2xx would be
the correct response.  This would be the case if anything needed to
explicitly reference the "invalid document" state, or if the
implications of the submission of it were more than just "fix and
resubmit" (though those are the same thing, I think).

Like I say, the model is a work in progress.

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2801
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-07 03:44:41
Subject:Re: [rest-discuss] Security and REST
Message:

Mathews, Walden wrote:
> Hi,
> 
> I'm just wondering about the interplay of authorization with
> resource space when developing web applications.  Is there anything
> un-RESTful about constraining resources implicitly based on the
> user's authenticated identity?  It makes me uneasy, but I'm not sure
> why.

You are varying the view based on something explicitly in the message 
*and* defined by HTTP. I think that's okay. It is not that different 
than content-negotiation or language-negotiation.

> ... In that case, two different users
> accessing /Subscriptions via GET will see disjoint subsets of the
> resource.  By extension, an entire resource schema (application) may
> be implicitly constrained by the security properties of the access.
> 
> What does REST have to say about this, if anything?

It is implicit in that there is no flag saying: "This representation is 
specific to you" but it is triggered by something in the request message 
and in that sense it is explicit.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2802
Sender:=?ISO-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-11-07 09:43:00
Subject:Re: [rest-discuss] 4xx response codes
Message:

Mark Baker wrote:
> On Thu, Nov 07, 2002 at 09:24:17AM +1100, Michael Day wrote:
> 
>>Hi,
>>
>>To indicate that a POSTed XML file is not valid against a schema, which of
>>these response codes would be more appropriate:
>>
>>	400 Bad Request		(HTTP request contains syntax error?)
>>	403 Forbidden		(I understand, but won't do it?)
>>	406 Not Acceptable	(You won't like the response?)
>>	409 Conflict		(Change something, then repeat request?)
>>	415 Unsupported Media Type	(...)
>>
>>Any thoughts?
> 
> 
> This is a good question, and I have to admit to getting caught by it
> on occasion.  I haven't developed a fool proof, simple model yet.

I don't think there is one for POST. Which is odd; you would think 
the CGI would have run up against input validation years ago.

> But I'd say that it depends on your application.  

That might couple the client and server with private definitions. 
The server side of the application can't possibly know ahead of time 
all its clients. Nor is it ideal to expect a client to be able to 
handle error codes on a per server basis (think what it would be 
like if RSS used schema validation). You really want to pick one 
code - or have HTTP extended to deal with this use case.

Bill de h�ra







-----------------------------------------------------------------------------------
Post ID:2803
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-07 15:39:18
Subject:Jabber/REST
Message:

On Wed, Nov 06, 2002 at 08:35:29AM +0100, Yannick Loiseau wrote:
> Does anyone had a look at Jabber as a Rest protocol ? It's full XML, based
> on few methods (get,set,result,error) for the <iq/> element. I'm quite new
> to Rest and very new to Jabber, but it sounds like they could work together
> fine.

Well, like every system out there, a REST interface could be built to
Jabber.  But not the other direction.  Jabber itself is not based on a
REST architecture; having a few verbs isn't sufficient, not even for
the "uniform interface" constraint.

The RESTwiki has a Jabber FAQ;

http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq#head-250b927a770c13278503a632e209fef4dd1b3f6e

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2804
Sender:=?ISO-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-11-07 16:18:18
Subject:SASL auth for HTTP
Message:

  <http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-05.txt>

this draft might be interesting to anyone working with secure http 
systems.

  Bill de h�ra

 > -------- Original Message --------
 > Subject: I-D ACTION:draft-nystrom-http-sasl-05.txt
 > Date: Thu, 07 Nov 2002 06:23:59 -0500
 > From: Internet-Drafts@...
 > Reply-To: Internet-Drafts@...
 > To: IETF-Announce: ;
 >
 > A New Internet-Draft is available from the on-line Internet-Drafts
 > directories.
 >
 >
 >     Title        : SASL in HTTP/1.1
 >     Author(s)    : M. Nystrom, R. Zuccherato, A. Melnikov
 >     Filename    : draft-nystrom-http-sasl-05.txt
 >     Pages        : 25
 >     Date        : 2002-11-6
 >
 > This memo suggest the use of SASL [RFC2222] as a framework to enable
 > the use of strong authentication mechanisms in http/1.1 [RFC2616],
 > and defines one approach to accomplish this.
 >
 > A URL for this Internet-Draft is:
 > http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-05.txt
 >
 >







-----------------------------------------------------------------------------------
Post ID:2805
Sender:"Lee Fife" <lee@...>
Post Date/Time:2002-11-07 21:08:20
Subject:Re: [rest-discuss] Security and REST
Message:

This seems exactly like content or language negotiation. So, it seems like the right thing is to have /Subscriptions return different content (representations) depending on user.

Or at least as long as the user credentials are explicitly contained in the request. Right? Don't play magic games with cookies containing session ids. Which, I think, for HTTP says that you have to use the Authorization header in the request, and the response would have a Vary: Authorization header.

Looks like HTTP restricts Vary to using the set of defined request headers, so you can't add your own extension header and have the response Vary on it. That seems a little strange -- I don't see why it would be hard for caches to understand any set of request headers that the particular returned representation depended on. After all, if you used an extension header to carry auth credentials, no client that doesn't understand the header will generate it. And so, there doesn't seem to be any danger of the cache returning the wrong rep. At worst, the cache doesn't cache as much as it could.

Which makes me think ... Can someone run the argument for why cookies are evil by me again, please? How does the client end up holding more state in a cookie than it does to fill in an Authorization header? In either case, you need more than the URI to get a useful representation of the resource back.

I accept that having some of the resource identification stored in the URI and some stored in a cookie is a bad thing.  I also accept that using a "session" id that refers to a hidden resource on the server and identifying that hidden resource in a cookie using a proprietary addressing scheme, rather than mentioning the session resource directly via its URI, is a bad thing.

Of course, there's judgement involved in deciding what's the resource (identified by URI) and what's a representation (varying on request headers or cookie values). But in Walden's example, the URI identifies the resource (/Subscriptions) and you need extra info beyond the URI to carry authentication info. In either case (request header or cookie) the extra info is in the message.

Maybe the distinction is that intermediaries like caches can know the fixed set of request headers, can know that server-driven negotiation uses those headers and that the headers of interest will be returned in a Vary response header, and can then serve appropriate cached content using efficient means. 

But, is there some hard technical reason that makes limiting the range of Vary a requirement? I.e., if you allowed Vary response to indicate any header in the request (extension headers as well as request headers) or to name a cookie, then caches would have a real hard time dealing with server-driven negotiation? It would be so expensive to support that caches would just pass the request thru? Or else, they'd do the wrong thing?

-Lee
  ----- Original Message ----- 
  From: Paul Prescod 
  To: Mathews, Walden 
  Cc: 'rest-discuss@yahoogroups.com' 
  Sent: Wednesday, November 06, 2002 8:44 PM
  Subject: Re: [rest-discuss] Security and REST


  Mathews, Walden wrote:
  > Hi,
  > 
  > I'm just wondering about the interplay of authorization with
  > resource space when developing web applications.  Is there anything
  > un-RESTful about constraining resources implicitly based on the
  > user's authenticated identity?  It makes me uneasy, but I'm not sure
  > why.

  You are varying the view based on something explicitly in the message 
  *and* defined by HTTP. I think that's okay. It is not that different 
  than content-negotiation or language-negotiation.

  > ... In that case, two different users
  > accessing /Subscriptions via GET will see disjoint subsets of the
  > resource.  By extension, an entire resource schema (application) may
  > be implicitly constrained by the security properties of the access.
  > 
  > What does REST have to say about this, if anything?

  It is implicit in that there is no flag saying: "This representation is 
  specific to you" but it is triggered by something in the request message 
  and in that sense it is explicit.

    Paul Prescod





-----------------------------------------------------------------------------------
Post ID:2806
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-07 21:24:48
Subject:Re: [rest-discuss] Security and REST
Message:

On Thu, Nov 07, 2002 at 04:08:20PM -0500, Lee Fife wrote:
> This seems exactly like content or language negotiation. So, it seems
> like the right thing is to have /Subscriptions return different content
> (representations) depending on user.

There's a tradeoff, of course.  It's my understanding that many
caches can't handle this type of use very well (though maybe it's
improved).

> Or at least as long as the user credentials are explicitly contained in
> the request. Right? Don't play magic games with cookies containing
> session ids. Which, I think, for HTTP says that you have to use the
> Authorization header in the request, and the response would have a Vary:
> Authorization header.

Right.

> Which makes me think ... Can someone run the argument for why cookies
> are evil by me again, please? How does the client end up holding more
> state in a cookie than it does to fill in an Authorization header? In

The client ends up holding *less* state; state that it would
normally have, such as id/password, are held on the server and
the client is just given a "receipt" for them.  The server is
holding state on the client's behalf.  That's the problem.

> But, is there some hard technical reason that makes limiting the range
> of Vary a requirement? I.e., if you allowed Vary response to indicate
> any header in the request (extension headers as well as request headers)

Vary can name any header, even extension ones.  Just like Connection.

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2807
Sender:"Lee Fife" <lee@...>
Post Date/Time:2002-11-07 21:38:30
Subject:Re: [rest-discuss] Security and REST
Message:

Mark,

From: "Mark Baker" <distobj@...>
> On Thu, Nov 07, 2002 at 04:08:20PM -0500, Lee Fife wrote:
> > This seems exactly like content or language negotiation. So, it seems
> > like the right thing is to have /Subscriptions return different content
> > (representations) depending on user.
>
> There's a tradeoff, of course.  It's my understanding that many
> caches can't handle this type of use very well (though maybe it's
> improved).

So, the caches are built to only support negotiation on the Accept and
Accept-* headers? The set of headers the cache looks at is built in? And
presumably if the response Vary header specifies some other request header,
then the response isn't cached?

> > But, is there some hard technical reason that makes limiting the range
> > of Vary a requirement? I.e., if you allowed Vary response to indicate
> > any header in the request (extension headers as well as request headers)
>
> Vary can name any header, even extension ones.  Just like Connection.

So, am I misreading the rfc: " Field-names listed in Vary headers are those
of request-headers.".  (Sect 14.3) Instead, you're saying that Vary can name
any of the headers present in a request message? (sect 5)

           Request       = Request-Line              ; Section 5.1
                           *( general-header         ; Section 4.5
                            | request-header         ; Section 5.3
                            | entity-header )        ; Section 7.1
                           CRLF
                           [ message-body ]          ; Section 7.2

So, Vary can include anything from general-header + request-header +
entity-header?

(BTW, the def for Connection appears to allow any header from the message.)

thanks,
Lee








-----------------------------------------------------------------------------------
Post ID:2808
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-08 02:08:58
Subject:Re: [rest-discuss] Security and REST
Message:

Mark Baker wrote:
>...
> 
> 
> The client ends up holding *less* state; state that it would
> normally have, such as id/password, are held on the server and
> the client is just given a "receipt" for them.  The server is
> holding state on the client's behalf.  That's the problem.

My thought is that if the Web-as-we-use it were architected entirely 
according to REST, then "client-side" state (not username/passwords, but 
preferences, etc.) would more likely live at any URI-addressable home. 
So you might launch your favorite news site like this:

http://www.mynews.com/

or like this:

http://www.mynews.com?prefs=http://mypreferences.com/~prescod

No matter what device you were using, you would point the site at your 
consistent preferences-URI. The browser would (at your _request_) send 
the information to remote servers. Servers would _ask you_ for read 
and/or write permission to your preferences-URI and the information 
stored there would tend to be open, textual and in many cases defined 
independent of any particular application. If you "publish" your 
favourite sports team, it should be provided to all services _and all of 
your devices_ unless you specifically override it for some particular 
application or device.

The problem with this vision is it requires a trusted third party to 
hold your preference information. Most people do not run their own 
servers. ISPs are the logical choice except who trusts AOL or MSN???
But even so, there could be a degenerate case where the preference-URI 
is something like "local://mybrowser/preference-cache" and some protocol 
magic would make that work as if it were a real, full-time preference 
server.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2809
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-08 02:19:30
Subject:Re: [rest-discuss] Security and REST
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

>
> My thought is that if the Web-as-we-use it were architected entirely
> according to REST, then "client-side" state (not username/passwords, but
> preferences, etc.) would more likely live at any URI-addressable home.
> So you might launch your favorite news site like this:
>
> http://www.mynews.com/
>
> or like this:
>
> http://www.mynews.com?prefs=http://mypreferences.com/~prescod

Wouldn't it be hard to do caching that way? Or was the thought that
preferences (per representation changes based on personal choices) breaks
caching anyway?

>
> No matter what device you were using, you would point the site at your
> consistent preferences-URI.
The same URI for each device? This is what I would like, but in practice
that doesn't happen all that often.

> The browser would (at your _request_) send
> the information to remote servers. Servers would _ask you_ for read
> and/or write permission to your preferences-URI and the information
> stored there would tend to be open, textual and in many cases defined
> independent of any particular application. If you "publish" your
> favourite sports team, it should be provided to all services _and all of
> your devices_ unless you specifically override it for some particular
> application or device.
Wasn't there several attempts at this 'shared preferences' approach? I can't
find any references right now...






-----------------------------------------------------------------------------------
Post ID:2810
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-08 02:25:12
Subject:Re: [rest-discuss] Security and REST
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>

> The client ends up holding *less* state; state that it would
> normally have, such as id/password, are held on the server and
> the client is just given a "receipt" for them.  The server is
> holding state on the client's behalf.  That's the problem.
>
Since the Web has migrated on its own to a system where the server holds
authentication information on the client's behalf, doesn't this indicate an
actual benefit to that approach?

Why is it that nobody uses HTTP Auth? Regardless of the 'Basic' auth-type
being unsecure, why do so many systems use something else?
And why isn't there an RFC describing/standardizing current practice? The
servlet engines I know have a servlet config for authentication called 'form
auth' which makes it easy to use POST to authenticate & then pass down a
cookie.

Wouldn't it make sense to describe a use of HTML FORM that indicated to the
user-agent (the browser) that it was 'authentication' information and then
the browser could send it in the correct header? Or maybe a new HTML element
like <AUTH> or something...







-----------------------------------------------------------------------------------
Post ID:2811
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-08 02:31:30
Subject:Re: [rest-discuss] Security and REST
Message:

S. Mike Dierken wrote:
>...
>>http://www.mynews.com/
>>
>>or like this:
>>
>>http://www.mynews.com?prefs=http://mypreferences.com/~prescod
> 
> 
> Wouldn't it be hard to do caching that way? Or was the thought that
> preferences (per representation changes based on personal choices) breaks
> caching anyway?

Exactly!

But perhaps we can use persistent connections, inclusions and 
prefetching to get more granular. Perhaps the page that is returned 
consists mostly of "includes" and those includes are cached or not 
cached based on whether they are specific to you or not.

>>No matter what device you were using, you would point the site at your
>>consistent preferences-URI.
> 
> The same URI for each device? This is what I would like, but in practice
> that doesn't happen all that often.

None of this happens in practice. It is a proposal. ;)

>...
> 
> Wasn't there several attempts at this 'shared preferences' approach? I can't
> find any references right now...

Netscape had a remote preferences feature but I'm not sure if it covered 
cookies. Hailstorm was to be more or less a remote cookie repository. 
But they couldn't find a business model for it because the natural home 
for it is at the ISP (or at least portal) and the biggest ISP in the 
world would NEVER cooperate with Microsoft. Plus, ISPs seem to have 
frozen the set of applications they are willing to deliver around 1995. 
How many of them are working to roll out Jabber or multicast or smart 
content caching techniques or decent spam filtering or universal inboxes 
(=phone and email) or ...

They are about as imaginative as cable TV companies because these days 
they _are_ cable TV companies.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2812
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-11-08 02:55:20
Subject:client-side state (was Re: Security and REST)
Message:

In REST, we agree that all state should be kept on the client side.  Now,
what is the best way to go about doing that?  I am not necessarily talking
about using existing HTTP browser/server technology.  I am talking about
creating a ficticious client and server that did this correctly.  Paul
mentioned the idea of having a URI-referencable client state that the server
could query.  However, what sets the state in the first place (presumably in
a RESTful manner)?  Who is responsible for setting the state?  Client?
Server? Both?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2813
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-08 03:01:19
Subject:Re: [rest-discuss] Security and REST
Message:

On Thu, Nov 07, 2002 at 06:08:58PM -0800, Paul Prescod wrote:
> My thought is that if the Web-as-we-use it were architected entirely 
> according to REST, then "client-side" state (not username/passwords, but 
> preferences, etc.) would more likely live at any URI-addressable home. 
> So you might launch your favorite news site like this:
> 
> http://www.mynews.com/
> 
> or like this:
> 
> http://www.mynews.com?prefs=http://mypreferences.com/~prescod

That's certainly *an* approach, but it's stateful not stateless because
the preferences form part of the meaning of the message, but are not in
the message.

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2814
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-08 03:26:57
Subject:Re: [rest-discuss] Security and REST
Message:

On Thu, Nov 07, 2002 at 02:38:30PM -0700, Lee Fife wrote:
> So, the caches are built to only support negotiation on the Accept and
> Accept-* headers? The set of headers the cache looks at is built in? And
> presumably if the response Vary header specifies some other request header,
> then the response isn't cached?

All I know about this, I heard from others.  Mnot would be the best
person to comment on the specifics.

> > Vary can name any header, even extension ones.  Just like Connection.
> 
> So, am I misreading the rfc: " Field-names listed in Vary headers are those
> of request-headers.".  (Sect 14.3) Instead, you're saying that Vary can name
> any of the headers present in a request message? (sect 5)
> 
>            Request       = Request-Line              ; Section 5.1
>                            *( general-header         ; Section 4.5
>                             | request-header         ; Section 5.3
>                             | entity-header )        ; Section 7.1
>                            CRLF
>                            [ message-body ]          ; Section 7.2
> 
> So, Vary can include anything from general-header + request-header +
> entity-header?

Sorry, I meant any *request* header.  But it can be any extension
header too, not just those in the HTTP spec, which is what I thought
you were talking about.

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2815
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-08 03:56:32
Subject:Re: [rest-discuss] Security and REST
Message:

On Thu, Nov 07, 2002 at 09:25:12PM -0500, S. Mike Dierken wrote:
> Since the Web has migrated on its own to a system where the server holds
> authentication information on the client's behalf, doesn't this indicate an
> actual benefit to that approach?

For sure, there's lots of benefits to them; they're a catch-all, they're
easy to use and implement, etc..  But there's also serious disadvantages,
such as messing up browsing (i.e. hitting "Back" doesn't remove the
cookie), plus resource consumption on the server.  Obviously the pros
outweight the cons for browsers.

Cookies are the way they are because they got deployed first, and they
did the job.  That doesn't mean we can't do better for non-browser based
apps, which was I was so disappointed to see the WS-I Basic Profile
support them as a state mechanism.

> Why is it that nobody uses HTTP Auth? Regardless of the 'Basic' auth-type
> being unsecure, why do so many systems use something else?

As you suggest below, I believe it's the lack of a UI.

> And why isn't there an RFC describing/standardizing current practice? The
> servlet engines I know have a servlet config for authentication called 'form
> auth' which makes it easy to use POST to authenticate & then pass down a
> cookie.

Well, that doesn't impact the protocol, so I don't know what value
there would be to doing that, other than illustrative.

> Wouldn't it make sense to describe a use of HTML FORM that indicated to the
> user-agent (the browser) that it was 'authentication' information and then
> the browser could send it in the correct header? Or maybe a new HTML element
> like <AUTH> or something...

Yep.

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2816
Sender:=?ISO-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-11-08 10:31:56
Subject:Re: [rest-discuss] Security and REST
Message:

Mark Baker wrote:

> For sure, there's lots of benefits to them; they're a catch-all, they're
> easy to use and implement, etc..  But there's also serious disadvantages,
> such as messing up browsing (i.e. hitting "Back" doesn't remove the
> cookie), plus resource consumption on the server.  Obviously the pros
> outweight the cons for browsers.

The back button is a (literally) a world in itself and cookies are 
incidental to it.

> Cookies are the way they are because they got deployed first, and they
> did the job.  

Maybe. But if we keep refusing to use TTPs then there isn't a better 
game in town that storing state on servers. I'll also observe that 
even if cookies vanished tommorrow, the server would still need to 
hold state to deal with back button 'semantics', which are not 
unlike trying to write software while an evil pixie inserts random 
goto statements into the code.


>That doesn't mean we can't do better for non-browser based
> apps, which was I was so disappointed to see the WS-I Basic Profile
> support them as a state mechanism.

Absolutely.

Bill de h�ra







-----------------------------------------------------------------------------------
Post ID:2817
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-11-08 11:13:34
Subject:Resource-Type header
Message:

Hi,

I would really like to use the Resource-Type header defined here:

	http://lists.w3.org/Archives/Public/www-archive/2002Mar/att-0054/01-draft-palmer-resrep-type-00.txt

for linking resources to an RDF Schema, allowing clients to infer the POST
interface that they support.

Is this header any kind of standard? Is there any way to achieve the same 
effect without using HTTP headers?

Michael







-----------------------------------------------------------------------------------
Post ID:2818
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-11-08 14:16:48
Subject:RE: [rest-discuss] client-side state (was Re: Security and REST)
Message:

I think we need to be careful to say "conversational state"
in instances like this.  When you propose to capture conversational
state as a globally addressable resource, you're promoting it
to something "higher" than conversational state.  Indeed, you're
likely factoring out the conversation in doing that, maintaining
only the points of agreement.

Think: If clients were responsible for *all* application state, then
there would be no need for servers.  Please let's try to keep the
word "conversational" in there where it belongs.

Thanks,
Walden 

> -----Original Message-----
> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Thursday, November 07, 2002 9:55 PM
> To: rest-discuss
> Subject: [rest-discuss] client-side state (was Re: Security and REST)
> 
> 
> In REST, we agree that all state should be kept on the client 
> side.  Now,
> what is the best way to go about doing that?  I am not 
> necessarily talking
> about using existing HTTP browser/server technology.  I am 
> talking about
> creating a ficticious client and server that did this correctly.  Paul
> mentioned the idea of having a URI-referencable client state 
> that the server
> could query.  However, what sets the state in the first place 
> (presumably in
> a RESTful manner)?  Who is responsible for setting the state?  Client?
> Server? Both?
> 
> ---
> Seairth Jacobs
> seairth@...
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/JjlUgA/vN2EAA/kG8FAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
> 






-----------------------------------------------------------------------------------
Post ID:2819
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-08 14:44:54
Subject:Re: [rest-discuss] client-side state (was Re: Security and REST)
Message:

On Fri, Nov 08, 2002 at 09:16:48AM -0500, Mathews, Walden wrote:
> I think we need to be careful to say "conversational state"
> in instances like this.

Definitely.  Either that or "application state" or maybe "session
state".  I used to prefer "session state", but "application state"
has grown on me despite many people thinking it means data.
"conversational state" is arguably better, especially when talking
to Web services folks, since, of course, "conversations" are a big
deal.

>  When you propose to capture conversational
> state as a globally addressable resource, you're promoting it
> to something "higher" than conversational state.  Indeed, you're
> likely factoring out the conversation in doing that, maintaining
> only the points of agreement.
>
> Think: If clients were responsible for *all* application state, then
> there would be no need for servers.

I like to call that "application data".  "application state" should
refer to the state of the application (duh!), such as "waiting for
input from user", etc..

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2820
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-11-08 15:45:02
Subject:RE: [rest-discuss] client-side state (was Re: Security and REST)
Message:

> -----Original Message-----
> From: Mark Baker [mailto:distobj@...]
> Sent: Friday, November 08, 2002 9:45 AM
> To: Mathews, Walden
> Cc: 'Seairth Jacobs'; rest-discuss
> Subject: Re: [rest-discuss] client-side state (was Re: Security and
> REST)
> 
> 
> On Fri, Nov 08, 2002 at 09:16:48AM -0500, Mathews, Walden wrote:
> > I think we need to be careful to say "conversational state"
> > in instances like this.
> 
> Definitely.  Either that or "application state" or maybe "session
> state".  I used to prefer "session state", but "application state"
> has grown on me despite many people thinking it means data.
> "conversational state" is arguably better, especially when talking
> to Web services folks, since, of course, "conversations" are a big
> deal.
> 
> >  When you propose to capture conversational
> > state as a globally addressable resource, you're promoting it
> > to something "higher" than conversational state.  Indeed, you're
> > likely factoring out the conversation in doing that, maintaining
> > only the points of agreement.
> >
> > Think: If clients were responsible for *all* application state, then
> > there would be no need for servers.
> 
> I like to call that "application data".  "application state" should
> refer to the state of the application (duh!), such as "waiting for
> input from user", etc..

There are scope ambiguities inherent in "application state" when
the application is distributed between a client and a server.  My
view is that "the application" spans client and server, and spans
ephemeral states (conversational) and durable states (persistent
data).  In other words, Application State is the whole enchelada.
In Alloy, you'd typically model it under a signature called "System {}"
or something suitably global sounding.

"Waiting for input from user" is a server state scoped by the
message-passing domain, so it's not even part of conversational state
proper, unless you promote it to "Waiting for confirmation to the
pending proposal" or some such.  We'd best be careful here, lest we
conflate transport and application layers, after all that work
educating the public as to the difference(!).

"Application data" carries no special meaning to me, but I agree
that we need a term that distinguishes the state of the application's
problem domain from the state of conversations about it.  For
instance, the conference room scheduler's problem domain consists
of rooms, people, reservations and the resulting schedules.  The
state of that domain at any given time controls what room you can
occupy and what room you can reserve for the future.

Although you can get some benefit from a separation of concerns like
the above, it's interesting to note that mutable applications exist
to shape conversations into durable facts about the domain.  For
example, when you converse with the conference room scheduler, you
pass back and forth half-baked specifications of a reservation until
it achieves permanent (problem domain) status by agreement.

Forgive me, for I take the anal-retentive modeler's view of
what "state" is, namely: everything that isn't change.  Forgive
me again, for I didn't mean to rant or preach on the subject;
just to gather my own thoughts (and share them).

Waldoon






-----------------------------------------------------------------------------------
Post ID:2821
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-08 18:17:25
Subject:Re: [rest-discuss] client-side state (was Re: Security and REST)
Message:

On Fri, Nov 08, 2002 at 10:45:02AM -0500, Mathews, Walden wrote:
> There are scope ambiguities inherent in "application state" when
> the application is distributed between a client and a server.  My
> view is that "the application" spans client and server, and spans
> ephemeral states (conversational) and durable states (persistent
> data).

Ditto.

>  In other words, Application State is the whole enchelada.
> In Alloy, you'd typically model it under a signature called "System {}"
> or something suitably global sounding.

Hmm, that's reasonable I suppose.  But I think it's still fair to say
that the term is currently ambiguous, so one should also try to
expand on what you mean by it.

> "Waiting for input from user" is a server state scoped by the

Actually I meant that a user agent was waiting for the user.

> "Application data" carries no special meaning to me, but I agree

The word "data" is definitely understandable by more people.  Maybe
the word "application" is unnecessary.

We need a glossary in the Wiki.  Obviously the Wiki *is* a glossary,
but I mean getting some more basic terms defined as Wiki words,
including distributed systems stuff.  Volunteers?

> Forgive me, for I take the anal-retentive modeler's view of
> what "state" is, namely: everything that isn't change.  Forgive
> me again, for I didn't mean to rant or preach on the subject;
> just to gather my own thoughts (and share them).

Depending on who I'm talking to (!!), it either means "anything that is
remembered", or what you call conversation state.  Of course, the former
is a superset of the latter.

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com






-----------------------------------------------------------------------------------
Post ID:2822
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-08 18:56:57
Subject:Re: [rest-discuss] Security and REST
Message:

S. Mike Dierken wrote:
>...
> 
> Wouldn't it make sense to describe a use of HTML FORM that indicated to the
> user-agent (the browser) that it was 'authentication' information and then
> the browser could send it in the correct header? Or maybe a new HTML element
> like <AUTH> or something...

Yes, and this is a known deficiency with both HTML forms and XForms.

Unfortunately the REST/HTTP community didn't push the issue with XForms. 
By the time I became very knowledgable about XForms, REST and the 
interaction between them, the XForms working group was already exhausted 
and in somewhat of a defensive mode. Now they are almost at CR stage and 
will resist changes even more strongly.

Perhaps XHTML 2.0 is the next opportunity to attack the problem. Another 
option is to just write a W3C NOTE ... or if anyone is ambitious enough 
(and works at a member company) to try to push the NOTE through the 
process as its own WD. "HTTP Authentication extensions for XForms and 
XHTML".

When I mentioned the problem to Dan Connolly at a conference he slapped 
his head and said something like: "We STILL haven't fixed that? Damn." 
It's a little thing but with a wide impact on how people build websites...

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2823
Sender:"Lee Fife" <lee@...>
Post Date/Time:2002-11-08 19:02:59
Subject:Re: [rest-discuss] Security and REST
Message:

Sorry to beat a dead horse here, but I'm trying to understand what the HTTP
rfc actually means.

Anyway, Mark said:
> Vary can name any header, even extension ones.  Just like Connection.

I replied, quoting from rfc 2068:
> So, am I misreading the rfc: "Field-names listed in Vary headers are those
> of request-headers.".  (Sect 14.3)

And Mark responded:
> Sorry, I meant any *request* header.  But it can be any extension
> header too, not just those in the HTTP spec, which is what I thought
> you were talking about.

Finally:
* yes, I was talking about extension headers. Those seem like a natural
place to put authentication credentials if you're using some non-standard
scheme
* I was interpreting "request-headers" as referring specifically to the set
of headers defined in the production for request-header in Sect 5.3. It
seems like Mark is saying "request-headers" should mean any header in the
request message? BTW, I'd like this better, cause then you could Vary on
extension headers. But, then I'd expect the rfc to say something like "any
request header".

But, practically, what's the impact of this? Is an intermediary justified in
rejecting a response message if it has illegal headers in it? E.g., could a
firewall fail to pass thru a response containing a "Vary: foobar" header
(where foobar is some extension header from the request)? Or could a cache
ignore the unrecognized Vary header fields and return the wrong page to a
subsequent request? (Of course, a broken firewall or cache could do anything
... I'm talking about "correct per the rfc" behavior.)

-Lee








-----------------------------------------------------------------------------------
Post ID:2824
Sender:"Lee Fife" <lee@...>
Post Date/Time:2002-11-08 19:11:42
Subject:Re: [rest-discuss] Security and REST
Message:

>> Why is it that nobody uses HTTP Auth? Regardless of the 'Basic' auth-type
>> being unsecure, why do so many systems use something else?

>As you suggest below, I believe it's the lack of a UI.

My two cents: In the systems I've built, lack of UI is exactly the reason
we're rejected HTTP Auth. Two main problems:
* usability: simple as it seems, the uname/pw dialog that the browsers
present seems to stump naive users. There's no feedback if you enter bad
credentials (besides the dialog popping up again), there's no help, there's
no way to retrieve a forgotten password.
* branding/look&feel: no way to control the UI. So you can't make it look
like the rest of your app.

Insecurity of the Basic scheme hasn't been a big deal for a these apps:
newsletters, targetted prof databases, etc.

Given configurable client-side control of the auth UI, I think we would have
happily used HTTP auth for almost all these apps.

-Lee








-----------------------------------------------------------------------------------
Post ID:2825
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-08 19:31:01
Subject:Re: [rest-discuss] Security and REST
Message:

Mark Baker wrote:
> On Thu, Nov 07, 2002 at 06:08:58PM -0800, Paul Prescod wrote:
> 
>>My thought is that if the Web-as-we-use it were architected entirely 
>>according to REST, then "client-side" state (not username/passwords, but 
>>preferences, etc.) would more likely live at any URI-addressable home. 
>>So you might launch your favorite news site like this:
>>
>>http://www.mynews.com/
>>
>>or like this:
>>
>>http://www.mynews.com?prefs=http://mypreferences.com/~prescod
> 
> 
> That's certainly *an* approach, but it's stateful not stateless because
> the preferences form part of the meaning of the message, but are not in
> the message.

So you would say that all your preferences should be sent in every 
message? We're talking about HTTP GET, so it would have to be HTTP 
headers...which is a pain for structured information.

What if each individual page on a site uses only some small subset of 
them? There are performance costs to sending them all every time. It is 
quite a bit cheaper to send a URL or list of URLs and let the recipient 
choose which to dereference and how deeply to follow links into the 
representations it finds.

====

To me, statelessness has these advantages:

  1. Conversations can migrate between agents and devices because there 
is no privileged information associated with the connection between the 
initial "initator" and the "listener". My proposal preserves this.

  2. Filtering, caching and other intermediary projects are easier 
because there is no need to store state between messages. My proposal 
preserves this. Filters and caches _may_ need to dereference URIs, but 
they don't have to maintain state themselves. That is important for 
scalability. It means cache's memory usage does not increase with the 
number of conversations they watch.

  3. If a message is missed or a conversation partner dies, it is easy 
to "reboot" and "resynch" the client and server state through transfer 
of representations. My proposal preserves this.

  4. Logs are explicit so that historically you can look at a single 
message in isolation and understand its meaning entirely. My proposal 
does not preserve this.

In a perfect world, I would get all 4 every time. But if the only 
problem is really "4." then I consider that an acceptable cost. On the 
other hand, if there is some other major benefit of scalability I am 
missing...

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2826
Sender:Andrew Tipton <atipton@...>
Post Date/Time:2002-11-08 20:25:54
Subject:Re: [rest-discuss] Security and REST
Message:

> >> Why is it that nobody uses HTTP Auth? Regardless of the 'Basic'
> >> auth-type being unsecure, why do so many systems use something else?
> >
> >As you suggest below, I believe it's the lack of a UI.
>
> My two cents: In the systems I've built, lack of UI is exactly the reason
> we're rejected HTTP Auth. Two main problems:
> * usability: simple as it seems, the uname/pw dialog that the browsers
> present seems to stump naive users. There's no feedback if you enter bad
> credentials (besides the dialog popping up again), there's no help, there's
> no way to retrieve a forgotten password.
> * branding/look&feel: no way to control the UI. So you can't make it look
> like the rest of your app.
My biggest concern with HTTP Auth (as currently implemented by browsers) is 
that once you've logged in, there is no way for the user to tell the browser 
to "forget" that username and password!  You have to close ALL browser 
windows to get it to forget the authentication.

Wouldn't it be nice if the web browser had a statusbar icon (similar to the 
lock for HTTPS) indicating that it was currently sending authentication 
information with each request?  Clicking on this icon would allow the user to 
"manage" their current logins, including an easy way to logout from a given 
site (where logout simply means no longer sending authentication 
information).

Fixing this problem would make HTTP auth usable by browsers.  Of course, UI 
improvements would be welcome.........
> Given configurable client-side control of the auth UI, I think we would
> have happily used HTTP auth for almost all these apps.
Agreed!   The server should be able to return a simple HTML document as the 
entity-body of the HTTP 401 Unauthorized response.  Just need a standard way 
to inform the browser which field is the username, and which is the password.

-Andrew








-----------------------------------------------------------------------------------
Post ID:2827
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-08 20:52:29
Subject:Re: [rest-discuss] Security and REST
Message:

On Fri, Nov 08, 2002 at 12:02:59PM -0700, Lee Fife wrote:
> * I was interpreting "request-headers" as referring specifically to the set
> of headers defined in the production for request-header in Sect 5.3. It
> seems like Mark is saying "request-headers" should mean any header in the
> request message? BTW, I'd like this better, cause then you could Vary on
> extension headers. But, then I'd expect the rfc to say something like "any
> request header".

Hmm, interesting, I never noticed that.  Not sure what the general
implications of it are, or if it's a bug, but at least there's this
bit from 12.1 to cover your Vary question;

  "However, an
   origin server is not limited to these dimensions and MAY vary the
   response based on any aspect of the request, including information
   outside the request-header fields or within extension header fields
   not defined by this specification."

> But, practically, what's the impact of this? Is an intermediary justified in
> rejecting a response message if it has illegal headers in it? E.g., could a
> firewall fail to pass thru a response containing a "Vary: foobar" header
> (where foobar is some extension header from the request)? Or could a cache
> ignore the unrecognized Vary header fields and return the wrong page to a
> subsequent request? (Of course, a broken firewall or cache could do anything
> ... I'm talking about "correct per the rfc" behavior.)

HTTP's processing model is a bit loose, but basically most software out
there is "liberal in what it receives" meaning that they won't likely
reject a message for containing a header which it doesn't recognize.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2828
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-11-08 23:31:33
Subject:conversation (was client-side) state
Message:

I'm still thinking in terms of conversational state.

Maybe I spent too much time in ebXML, don't know.

But it still seems to me that if everything gets modeled as business-
semantic concepts and speech acts, and both business-semantic 
concepts and speech acts are implemented as Web resources, then the 
state of the conversation is represented by the speech acts that have 
been "uttered".

I haven't written down all my thoughts on this in any accessible way, 
but this document might give an idea:
http://www.openebxml.org/information/papers/ecomo02stockholm.pdf 

It's framed in terms of an ebXML-like model (EDI mailbox-style 
messages), but one of my goals in joining Rest-discuss was to reframe 
the speech acts and economic concepts as REST resources.

<excerpt>
5.1 Pragmatic Actions
The basic notion introduced for relating business actions to economic 
concepts is that of a pragmatic action, see Fig. 5. A Pragmatic 
Action is a speech act, as defined in Section 2, and consists of two 
parts: a content and an illocutionary force. 

In ecommerce applications, the content is always an economic concept. 
The illocutionary force of a pragmatic action indicates in what way 
the action is related to its content.

An agent can perform a pragmatic action and thereby influence an 
economic concept in a specific way.

Depending on which economic concept a pragmatic action addresses, 
different illocutionary forces are applicable. The pragmatic actions 
are, therefore, divided into several subclasses as indicated in Fig. 
5. The three main subclasses are information actions, deontic 
actions, and fulfilment actions. The underling intuition for 
identifying these three sub classes of pragmatic actions is that in 
an e-commerce scenario, trading partners exchange business 
information, then establish different obligations, and finally 
exchange economic resources, thereby fulfilling the obligations.
[...]
A Fulfilment Action has an economic event as its content. The action 
may declare that an Economic Event has been performed, or it may 
express that such a declaration is accepted or rejected. There are 
three possible illocutionary forces for information actions: Declare 
states that an economic event has been performed, Accept states that 
a preceding declaration of performing an economic event is accepted, 
Reject states that such a declaration is rejected. Examples of 
fulfilment actions are "declare shipment completed" and "accept 
shipment".

A Deontic Action can have a commitment or contract as its content. 
Thus, a deontic action concerns obligations to carry out events in 
the future. There are seven possible illocutionary forces for deontic 
actions: Propose means that an agent proposes the establishment of a 
commitment or contract. Accept is the acceptance of such a proposal 
while Reject is the rejection of a preceding proposal, Request-
Cancellation is a request to cancel an established commitment or 
contract, AcceptCancellation is the acceptance of such a request, 
while RejectCancellation is the rejection of a preceding request to 
cancel, Cancel is a unilateral cancellation.

Examples of Deontic Actions are "request purchase order" and "accept 
purchase order request".
</excerpt> 

It's clear that some of their Actions should just be GETs.

Commitment and Fulfillment actions are the ones that seem to me to be 
the basis for making business conversations into resource models.  
The state of the conversation is the combination of the Pragmatic 
Actions uttered and the states of the economic concepts they 
affected.  

There's two levels:  the utterances and their relationships (e.g. 
Offer and Acceptance utterances refer to an Order, Fulfillment 
actions refer to the Order they fulfill, etc.

I think what this means in REST terms is that Pragmatic Actions would 
be POSTed as statements and result in the creation or updating of 
economic concept resources, but the Pragmatic Actions would 
themselves become resources and could refer to each other.  For 
example, an Accept statement would need to refer to an Offer or 
Assertion statement.

With a small number of economic concepts and statements and 
relationships, it would be possible to configure conversations on the 
fly from hyperlinked Web resources, and know what the state of the 
conversation was by examining the resources.

Still not quite soup yet, but coming along, as I get time and figure 
out the details.

-Bob Haugen








-----------------------------------------------------------------------------------
Post ID:2829
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-09 14:56:35
Subject:Re: [rest-discuss] Security and REST
Message:

----- Original Message -----
From: "Andrew Tipton" <atipton@...>

> My biggest concern with HTTP Auth (as currently implemented by browsers)
is
> that once you've logged in, there is no way for the user to tell the
browser
> to "forget" that username and password!  You have to close ALL browser
> windows to get it to forget the authentication.
Same thing with cookies.
Typical cookie based (distributed) apps send a response that has a cookie
with negative duration or something that signals the browser to delete the
cookie. There should be a corresponding capability in the HTTP Auth
approach.

>
> Wouldn't it be nice if the web browser had a statusbar icon (similar to
the
> lock for HTTPS) indicating that it was currently sending authentication
> information with each request?  Clicking on this icon would allow the user
to
> "manage" their current logins, including an easy way to logout from a
given
> site (where logout simply means no longer sending authentication
> information).
Giving the users control over highly technical issues usually doesn't work.
Let the web app author present to the user the most appropriate form for
'log out'.

Okay... sounds like everybody wants this.
Who knows how to write a W3C NOTE?









-----------------------------------------------------------------------------------
Post ID:2830
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-11-09 19:07:11
Subject:webbib
Message:

This may already be widely known, but it just occured to me that this
might be a useful resource (ahem) for this group;
  http://www.cs.wpi.edu/~webbib/

I've used it for years in regards to caching (which a lot of it focuses
on), but the topic is actually just the WWW as a distributed system, which
seems to be of interest here. The bibliography-by-reverse-date and list of
conferences are especially useful.

Cheers,

--
Mark Nottingham







-----------------------------------------------------------------------------------
Post ID:2831
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-10 21:44:07
Subject:Re: [rest-discuss] Security and REST
Message:

On Fri, Nov 08, 2002 at 11:31:01AM -0800, Paul Prescod wrote:
> So you would say that all your preferences should be sent in every 
> message? We're talking about HTTP GET, so it would have to be HTTP 
> headers...which is a pain for structured information.

As long as it's part of the *message*.  Headers seem the obvious place,
but the body's fine too.  There's many ways to do this.

> What if each individual page on a site uses only some small subset of 
> them? There are performance costs to sending them all every time. It is 
> quite a bit cheaper to send a URL or list of URLs and let the recipient 
> choose which to dereference and how deeply to follow links into the 
> representations it finds.

Yep, very true.  The WAPforum went back and forth on this for quite a
while with CC/PP.  Initially, everybody assumed that the preferences
would be cached, but I'm pretty sure the final decision was to send
all the data in each message.  I could be wrong, the final decision
happened after I left, and after I cared.

> To me, statelessness has these advantages:
> 
>   1. Conversations can migrate between agents and devices because there 
> is no privileged information associated with the connection between the 
> initial "initator" and the "listener". My proposal preserves this.

Yep.

>   2. Filtering, caching and other intermediary projects are easier 
> because there is no need to store state between messages. My proposal 
> preserves this. Filters and caches _may_ need to dereference URIs, but 
> they don't have to maintain state themselves. That is important for 
> scalability. It means cache's memory usage does not increase with the 
> number of conversations they watch.

Yep.

>   3. If a message is missed or a conversation partner dies, it is easy 
> to "reboot" and "resynch" the client and server state through transfer 
> of representations. My proposal preserves this.

State of preferences?  Ok.

>   4. Logs are explicit so that historically you can look at a single 
> message in isolation and understand its meaning entirely. My proposal 
> does not preserve this.

Right.

> In a perfect world, I would get all 4 every time. But if the only 
> problem is really "4." then I consider that an acceptable cost. On the 
> other hand, if there is some other major benefit of scalability I am 
> missing...

No, that's a good summary.  With any design choice, it's pros vs. cons.

On the other hand, a simple policy decision could turn the same message
syntax into a stateless transaction, if the URI were to identify a
fixed preferences profile that didn't change over time.  So if the
preferences change, the URI changes.  This would allow you to include
URIs for fixed and common preference profiles, while including the
frequently-changing preferences by-value.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2832
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-11-11 01:21:15
Subject:Re: [rest-discuss] Resource-Type header
Message:

> > Come to think of it, is there a nice demonstration of content negotiation
> > on the web anywhere, preferably at a high profile / popular web site? It
> > would be nice to have a working example to show people.
> 
> http://www.w3.org

I should have mentioned, w3.org is a no-brainer, and does not fit in the
category of high profile / popular except on mailing lists for the
discussion of web architecture, HTML or XML :)

Does anyone *else* use content negotiation?

Michael







-----------------------------------------------------------------------------------
Post ID:2833
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-11 01:23:29
Subject:Re: [rest-discuss] Resource-Type header
Message:

On Mon, Nov 11, 2002 at 12:21:15PM +1100, Michael Day wrote:
> Does anyone *else* use content negotiation?

I don't know.  The problem is, if it's done right (for server-driven),
you don't know you're using it.

Since most big sites use content management tools combined with a Web
server, you start looking to see which tools support it.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2834
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-11 01:12:22
Subject:Re: [rest-discuss] Resource-Type header
Message:

On Mon, Nov 11, 2002 at 11:32:23AM +1100, Michael Day wrote:
> Unfortunately, mechanisms that rely on "unusual" HTTP headers such as
> Resource-Type and even content negotiation headers like Accept are very
> difficult to deploy in environments unfamiliar with their usage.

I agree with Resource-Type because it's non-standard, but I think Accept
and conneg is quite well deployed, even though a lot of user agents still
send "Accept: */*".

> Come to think of it, is there a nice demonstration of content negotiation
> on the web anywhere, preferably at a high profile / popular web site? It
> would be nice to have a working example to show people.

http://www.w3.org

Specifically, the XML Rec, and presumably others, are available in three
formats; HTML, PDF, and "xmlspec";

HTML; http://www.w3.org/TR/REC-xml.html
PDF; http://www.w3.org/TR/REC-xml.pdf
XMLSPEC; http://www.w3.org/TR/REC-xml.xml

GET on http://www.w3.org/TR/REC-xml with the appropriate Accept header
will return the variant you ask for, with Content-Location set to the
URI listed above.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2835
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-11 00:23:11
Subject:Re: [rest-discuss] Resource-Type header
Message:

On Fri, Nov 08, 2002 at 10:13:34PM +1100, Michael Day wrote:
> 
> Hi,
> 
> I would really like to use the Resource-Type header defined here:
> 
> 	http://lists.w3.org/Archives/Public/www-archive/2002Mar/att-0054/01-draft-palmer-resrep-type-00.txt
> 
> for linking resources to an RDF Schema, allowing clients to infer the POST
> interface that they support.
> 
> Is this header any kind of standard?

Nope, but that doesn't prevent you from using it.

> Is there any way to achieve the same 
> effect without using HTTP headers?

You could content-negotiate for RDF and look for an rdf:type assertion
in there.  Resource-Type is simpler and more efficient, though it's a
new thing to deploy.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2836
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-11-11 00:32:23
Subject:Re: [rest-discuss] Resource-Type header
Message:

> > Is there any way to achieve the same 
> > effect without using HTTP headers?
> 
> You could content-negotiate for RDF and look for an rdf:type assertion
> in there.  Resource-Type is simpler and more efficient, though it's a
> new thing to deploy.

Unfortunately, mechanisms that rely on "unusual" HTTP headers such as
Resource-Type and even content negotiation headers like Accept are very
difficult to deploy in environments unfamiliar with their usage.

Come to think of it, is there a nice demonstration of content negotiation
on the web anywhere, preferably at a high profile / popular web site? It
would be nice to have a working example to show people.

Michael







-----------------------------------------------------------------------------------
Post ID:2837
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-11-11 03:30:11
Subject:draft-nystrom-http-sasl-05.txt
Message:

This [1] is an Internet-Draft that proposes how SASL should be integrated
into HTTP authentication.

What concerns me is this section:

 [[[
  4.3.9 "Web farm" considerations

   Implementation and configuration of the SASL negotiation mechanism
   described in this memo requires special considerations in the case of
   web farm environments where several servers may serve user requests
   since authentication state information otherwise may be lost. In
   particular, if a persistent connection to a particular server cannot
   be guaranteed, means for sharing of authentication negotiation state
   must be available.
]]]

In other words, there is apparently server-side state kept during the
negotiation of authentication. This seems broken to me, and I have a
feeling it's going to cause problems (for reasons that should be clear to
REST-heads). Assuming you have a persistent connection isn't possible *or*
a good idea in the HTTP.

Thoughts?


1. http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-05.txt

--
Mark Nottingham







-----------------------------------------------------------------------------------
Post ID:2838
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-11 03:48:21
Subject:Re: [rest-discuss] draft-nystrom-http-sasl-05.txt
Message:

On Sun, Nov 10, 2002 at 07:30:11PM -0800, Mark Nottingham wrote:
> This [1] is an Internet-Draft that proposes how SASL should be integrated
> into HTTP authentication.
> 
> What concerns me is this section:
> 
>  [[[
>   4.3.9 "Web farm" considerations
> 
>    Implementation and configuration of the SASL negotiation mechanism
>    described in this memo requires special considerations in the case of
>    web farm environments where several servers may serve user requests
>    since authentication state information otherwise may be lost. In
>    particular, if a persistent connection to a particular server cannot
>    be guaranteed, means for sharing of authentication negotiation state
>    must be available.
> ]]]
> 
> In other words, there is apparently server-side state kept during the
> negotiation of authentication. This seems broken to me, and I have a
> feeling it's going to cause problems (for reasons that should be clear to
> REST-heads). Assuming you have a persistent connection isn't possible *or*
> a good idea in the HTTP.

Good catch, yeah, that seems broken and unnecessary.  I don't know a lot
about SASL, but the little I do suggests to me that it need not be
stateful.

Better let the author now, if you haven't already ...

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2839
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-11-11 03:57:01
Subject:Re: [rest-discuss] draft-nystrom-http-sasl-05.txt
Message:

> > In other words, there is apparently server-side state kept during the
> > negotiation of authentication. This seems broken to me, and I have a
> > feeling it's going to cause problems (for reasons that should be clear to
> > REST-heads). Assuming you have a persistent connection isn't possible *or*
> > a good idea in the HTTP.

Doesn't HTTP over SSL (HTTPS) involve persistent connections?

Michael







-----------------------------------------------------------------------------------
Post ID:2840
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-11-11 04:03:28
Subject:Re: [rest-discuss] draft-nystrom-http-sasl-05.txt
Message:

Looking a bit deeper, it *appears* that server-side state is only required
when the underlying SASL mechanism requires three-stage negotiation (I'm
not a SASL expert, but a houseguest is ;)

It may be that this scheme will work, but may still be REST-unfriendly.
Will dig deeper...


----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "Mark Nottingham" <mnot@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Sunday, November 10, 2002 7:48 PM
Subject: Re: [rest-discuss] draft-nystrom-http-sasl-05.txt


> On Sun, Nov 10, 2002 at 07:30:11PM -0800, Mark Nottingham wrote:
> > This [1] is an Internet-Draft that proposes how SASL should be
integrated
> > into HTTP authentication.
> >
> > What concerns me is this section:
> >
> >  [[[
> >   4.3.9 "Web farm" considerations
> >
> >    Implementation and configuration of the SASL negotiation mechanism
> >    described in this memo requires special considerations in the case
of
> >    web farm environments where several servers may serve user requests
> >    since authentication state information otherwise may be lost. In
> >    particular, if a persistent connection to a particular server
cannot
> >    be guaranteed, means for sharing of authentication negotiation
state
> >    must be available.
> > ]]]
> >
> > In other words, there is apparently server-side state kept during the
> > negotiation of authentication. This seems broken to me, and I have a
> > feeling it's going to cause problems (for reasons that should be clear
to
> > REST-heads). Assuming you have a persistent connection isn't possible
*or*
> > a good idea in the HTTP.
>
> Good catch, yeah, that seems broken and unnecessary.  I don't know a lot
> about SASL, but the little I do suggests to me that it need not be
> stateful.
>
> Better let the author now, if you haven't already ...
>
> MB
> --
> Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca
>
>    Will distribute objects for food
>







-----------------------------------------------------------------------------------
Post ID:2841
Sender:"Mark Nottingham" <mnot@...>
Post Date/Time:2002-11-11 05:18:14
Subject:Re: [rest-discuss] draft-nystrom-http-sasl-05.txt
Message:

Yes, but HTTP is layered above SSL, not below it.

----- Original Message -----
From: "Michael Day" <mikeday@...>
To: <rest-discuss@yahoogroups.com>
Sent: Sunday, November 10, 2002 7:57 PM
Subject: Re: [rest-discuss] draft-nystrom-http-sasl-05.txt


>
> > > In other words, there is apparently server-side state kept during
the
> > > negotiation of authentication. This seems broken to me, and I have a
> > > feeling it's going to cause problems (for reasons that should be
clear to
> > > REST-heads). Assuming you have a persistent connection isn't
possible *or*
> > > a good idea in the HTTP.
>
> Doesn't HTTP over SSL (HTTPS) involve persistent connections?
>
> Michael
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:2842
Sender:Daniel Biddle <deltab@...>
Post Date/Time:2002-11-11 06:34:03
Subject:High-profile example of content negotiation
Message:

On Mon, Nov 11, 2002 at 11:32:23AM +1100, Michael Day wrote:
> Come to think of it, is there a nice demonstration of content negotiation
> on the web anywhere, preferably at a high profile / popular web site? It
> would be nice to have a working example to show people.

http://www.google.com/ has supported Accept-Language for at least a year.
(Change the list of acceptable languages to demonstrate it in a browser.)

They don't come much more high profile / popular than that!

-- 
Daniel Biddle <deltab@...>






-----------------------------------------------------------------------------------
Post ID:2843
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-11-13 00:14:00
Subject:Re: [rest-discuss] High-profile example of content negotiation
Message:

> http://www.google.com/ has supported Accept-Language for at least a year.
> (Change the list of acceptable languages to demonstrate it in a browser.)
> 
> They don't come much more high profile / popular than that!

Thanks, that's a good one! It would be nice to dispell some of the voodoo
people feel is associated with HTTP headers.

Michael







-----------------------------------------------------------------------------------
Post ID:2844
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-11-13 00:23:21
Subject:Re: [rest-discuss] 4xx response codes
Message:

> That might couple the client and server with private definitions. 
> The server side of the application can't possibly know ahead of time 
> all its clients. Nor is it ideal to expect a client to be able to 
> handle error codes on a per server basis (think what it would be 
> like if RSS used schema validation). You really want to pick one 
> code - or have HTTP extended to deal with this use case.

I picked "403 Forbidden" as the response code for invalid input for my
application. It seemed to match the meaning of the request, which was
"Please do X with this data" and as the data is invalid the server says
"No", which in HTTP is a 403 response. The *reason* the server said no has
to be indicated in the body of the response in HTML or RDF or whatever is
appropriate.

In fact the more I think about it, the more that 403 seems like the right
choice. Quoting the spec:

	The server understood the request, but is refusing to fulfill it 
	... the request SHOULD NOT be repeated ... it SHOULD describe the 
	reason for the refusal in the entity

It could be worth changing the status message for 403 from "Forbidden" to
"No", to make it clearer that it's not necessarily an access permission
issue.

Michael







-----------------------------------------------------------------------------------
Post ID:2845
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-11-13 20:27:27
Subject:Some KnowNow technology going Open Source
Message:

From Scott Andrew LePera's weblog:

"In a strange twist of events, the brass at KnowNow have given the green light
to Open Source some of the early prototypes of our 2-way-web technology. The
legacy code includes a notification server written in Perl (for the Apache
HTTP server) and a JavaScript library (called a microserver) which takes care
of the publish-and-subscribe stuff. The project is called mod_pubsub, with all
of the code available at the Sourceforge project page, with the goal of
melding these concepts into an full C module that turns Apache into a
real-time messaging bus. Whew."

http://www.scottandrew.com/weblog/2002_11#a000462







-----------------------------------------------------------------------------------
Post ID:2846
Sender:Jan Algermissen <algermissen@...>
Post Date/Time:2002-11-18 22:08:42
Subject:Question on extending HTTP Headers
Message:

Hi,

I have a question regarding the use of non-standardised HTTP Headers:

Suppose there is a serach engine that annotates the returned hit list
with meta data (e.g. title, author, creation date) and suppose this
search engine would be able to use several vocabularies (e.g. Dublin Core)
for this annotation.

What I would like to do, is to base the serch engine's decision about what
meta data vocabulary to use on HTTP content negotioation to anable the client
tell the serach engine what metadata it understands.

Would that be a RESTful approach ?


Example header:

Accept-MetadataEncodingScheme: Dublin-Core


Jan



-- 
Jan Algermissen
Consultant & Programmer

Tel:   ++49 (0)40 89 700 511
       ++49 (0)177 283 1440
Fax:   ++49 (0)40 89 700 841 
Email: algermissen@...
Web:   http://www.topicmapping.com






-----------------------------------------------------------------------------------
Post ID:2847
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-18 22:19:33
Subject:Re: [rest-discuss] Question on extending HTTP Headers
Message:

On Mon, Nov 18, 2002 at 11:08:42PM +0100, Jan Algermissen wrote:
> Hi,
> 
> I have a question regarding the use of non-standardised HTTP Headers:
> 
> Suppose there is a serach engine that annotates the returned hit list
> with meta data (e.g. title, author, creation date) and suppose this
> search engine would be able to use several vocabularies (e.g. Dublin Core)
> for this annotation.
> 
> What I would like to do, is to base the serch engine's decision about what
> meta data vocabulary to use on HTTP content negotioation to anable the client
> tell the serach engine what metadata it understands.
> 
> Would that be a RESTful approach ?
> 
> 
> Example header:
> 
> Accept-MetadataEncodingScheme: Dublin-Core

Sure!  I might use the DC namespace as an identifier, but the idea of
using content negotiation here is fine.

For more complicated header semantics, where the client needs to be
guaranteed that the server understands the extension, something like
PEP, RFC 2774, or SOAP would be required.  But it doesn't sound like
that's critical for this example.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2848
Sender:Jan Algermissen <algermissen@...>
Post Date/Time:2002-11-18 23:47:18
Subject:Re: [rest-discuss] Question on extending HTTP Headers
Message:

Mark,

thanks very much!

I should propably proof-read the next time....

Jan



Mark Baker wrote:
> 
> On Mon, Nov 18, 2002 at 11:08:42PM +0100, Jan Algermissen wrote:
> > Hi,
> >
> > I have a question regarding the use of non-standardised HTTP Headers:
> >
> > Suppose there is a serach engine that annotates the returned hit list
> > with meta data (e.g. title, author, creation date) and suppose this
> > search engine would be able to use several vocabularies (e.g. Dublin Core)
> > for this annotation.
> >
> > What I would like to do, is to base the serch engine's decision about what
> > meta data vocabulary to use on HTTP content negotioation to anable the client
> > tell the serach engine what metadata it understands.
> >
> > Would that be a RESTful approach ?
> >
> >
> > Example header:
> >
> > Accept-MetadataEncodingScheme: Dublin-Core
> 
> Sure!  I might use the DC namespace as an identifier, but the idea of
> using content negotiation here is fine.
> 
> For more complicated header semantics, where the client needs to be
> guaranteed that the server understands the extension, something like
> PEP, RFC 2774, or SOAP would be required.  But it doesn't sound like
> that's critical for this example.
> 
> MB
> --
> Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca
> 
>    Will distribute objects for food
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

-- 
Jan Algermissen
Consultant & Programmer

Tel:   ++49 (0)40 89 700 511
       ++49 (0)177 283 1440
Fax:   ++49 (0)40 89 700 841 
Email: algermissen@...
Web:   http://www.topicmapping.com






-----------------------------------------------------------------------------------
Post ID:2849
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-11-20 00:10:49
Subject:fielding talks about waka at apachecon
Message:

for those who don't know, waka is fielding's (creator of REST) vision of
a next-gen http, and therefore may be of interest to those here.

http://www.radwin.org/michael/blog/archives/2002_11_19.html#000049







-----------------------------------------------------------------------------------
Post ID:2850
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-20 02:13:04
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

Wow!  A lot more good stuff on Waka than he had previously discussed.
RENDER?  Hmm, interesting.  Not sure why an extended POST wouldn't
suffice for that, but I suppose a new method could be an optimization.
MONITOR sounds familiar. 8-)

Note that Michael Radwin got the Web services comments backwards; they
don't solve the N^2 problem, they are the N^2 problem.  Roy's point is
that a uniform interface drives integration complexity to O(N) (which
was Jeff's earlier comment)

MB

On Wed, Nov 20, 2002 at 12:10:49AM +0000, Vincent D Murphy wrote:
> for those who don't know, waka is fielding's (creator of REST) vision of
> a next-gen http, and therefore may be of interest to those here.
> 
> http://www.radwin.org/michael/blog/archives/2002_11_19.html#000049

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2851
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-11-20 15:05:18
Subject:RE: [rest-discuss] fielding talks about waka at apachecon
Message:

> Note that Michael Radwin got the Web services comments backwards; they
> don't solve the N^2 problem, they are the N^2 problem.  Roy's point is
> that a uniform interface drives integration complexity to O(N) (which
> was Jeff's earlier comment)
> 
> MB

A couple of minor points on big O.  First "uniform interface drives
integration complexity to O(N)" is too easy to be true.  It doesn't
take into account that while there is much similarity among peer businesses,
there is also individuality, a/k/a competitive edge, which mandates, to
a degree, custom interfaces.  "Uniform interface" is like "software process
improvement".  You use it to factor away known redundancy, but no more.
Any time POST doesn't mean "add this to a list", uniformity is only
skin deep.

Secondly, your position in the scheme of things determines whether you,
personally will feel integration as O(N) or O(N^2) or something else.
Basically, God is the only one with the N^2 problem, because it's the
system view of the system.  An individual newcomer to a party without
uniform interfaces causes an integration problem (for itself and all others
who wish to integrate with him) with a sum total of O(N).  Over time,
from historical (God) perspecive, you would observe the N^2 thing, but
it's not a price paid daily.

Thank you.

Waldne






-----------------------------------------------------------------------------------
Post ID:2852
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-11-20 16:01:45
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

Mathews, Walden wrote,
> A couple of minor points on big O.

I made related points offlist ... may as well repost them here ...

Mark Baker wrote,
> what it says is that with Web services, integration complexity is
> O(N^2), while O(N) with a common interface.

As an aside ...

I think this is a double-edged sword. Certainly the integration 
complexity is reduced. But OTOH the effort of reaching agreement on the 
common interface is increased.

Just to spell this out a bit more, with multiple point-to-point 
interfaces only two parties need to agree on any particular interface, 
whereas all N have to agree on the common interface. I'd conjecture 
that the cost of reaching agreement is exponential in the number of 
parties to the agreement. That gives us O(N^2)*O(2^2) (ie. just O(N^2)) 
cost for agreement in the multiple interface case (O(N^2) pairs each 
having to reach an independent bilateral agreement) vs. O(2^N) cost for 
agreement in the common interface case.

I'd also conjecture that O(N^2) is a wildly pessimistic worst case 
because in practice not everybody needs to talk to everybody else. You 
only need O(NlogN) edges in a random graph to get complete 
connectivity, so O(NlogN) seems like a good guess for the typical, as 
opposed to the worst, case. FWIW ... not proof, but I've seen data from 
a major (ie. one that hasn't gone bust yet ;-) B2B exchange which 
supports this.

For multiple interfaces that'd give us,

  O(NlogN)     cost of integration (ie. NlogN implemented interfaces)
  O(NlogN)     cost of agreement   (ie. NlogN bilateral agreements)

For a common interface it'd give us,

  O(N)         cost of integration
  O(2^N)       cost of agreement

Notice that the cost of agreement won't scale down to the typical case 
for the common interface in the same way as it does for multiple 
interfaces, because the common interface still requires global 
agreement whether or not all parties need to communicate with each 
other.

I guess that you know as well as I do that agreements are fraught, 
messy, political and expensive. I take that as a hint that reducing 
that element of the _total_ cost is likely to be a win.

And I also think that multiple interfaces are likely to scale better in 
the face of growth and change (yup, I realize that this runs completely 
counter to what _everyone_ else is saying ;-). That's because changes 
are liable to be local, hence in the multiple interface case only 
require local renegotiation and reimplementation; and because new 
participants only have to reach agreements with the subset of existing 
participants they actually need to communicate with.

OTOH, on the common interface model every change requires global 
renegotiation and reimplementation; and new particpants either have to 
get along with what the first-movers already decided on whether or not 
it's fully appropriate for them, or alternatively simply not become 
participants at all (or become participants in something else). And, 
again FWIW, I've seen data from several B2B exchanges that this last 
problem is a real one ... they have a tough time signing up anyone 
beyond the initial consortia.

Interestingly, the numbers above generate the exact opposite of the 
typical "network effect" on the common interface model ... we actually 
end up with _decreasing_ returns to scale.

Thoughts?

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2853
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-11-20 16:02:25
Subject:Re: fielding talks about waka at apachecon
Message:

"Mathews, Walden" wrote:
 > A couple of minor points on big O.  First "uniform interface drives
> integration complexity to O(N)" is too easy to be true.  It doesn't
> take into account that while there is much similarity among peer 
businesses,
> there is also individuality, a/k/a competitive edge, which 
mandates, to
> a degree, custom interfaces.  

Depends on what interfaces you are thinking about.
If it's for exchanges between companies, then uniform interface will 
be a big win.  Companies exist as members of value systems composed 
of many other companies.  So you might think "uniform interface for 
this value system", as WalMart does.  But most of WalMart's suppliers 
also belong to other value systems, including some with big dogs at 
the head (e.g. Home Depot).  So even in WalMart's value system, there 
are forces for global uniformity.

That's why UN/CEFACT (the UN trade facilitation org) exists.

> Any time POST doesn't mean "add this to a list", uniformity is only
> skin deep.

I agree with you on this point, but think the second-level of "what 
POST means" can also be boiled down to a minimal set of meanings.  A 
Swedish project connected to UN/CEFACT is working this out in terms 
of speech acts as we discuss here.  I've tried to bring this topic up 
in rest-discuss several times, but no bites yet.  Regardless, I 
remain convinced it's on target.

> Secondly, your position in the scheme of things determines whether 
you,
> personally will feel integration as O(N) or O(N^2) or something 
else.
> Basically, God is the only one with the N^2 problem, because it's 
the
> system view of the system.  

It's also the value-system view of the system.  For example, one 
international trade deal may involve 30 parties.  Right now, such 
deals are very difficult to automate in-total.  Uniform interfaces 
(including what POST means in economic terms) will be required.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2854
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-11-20 16:21:23
Subject:Re: fielding talks about waka at apachecon
Message:

Miles Sabin wrote:
> I think this is a double-edged sword. Certainly the integration 
> complexity is reduced. But OTOH the effort of reaching agreement on 
the 
> common interface is increased.

Miles, your opinion is really interesting and I agree with it from 
one angle, but disagree from another angle.

> Just to spell this out a bit more, with multiple point-to-point 
> interfaces only two parties need to agree on any particular 
interface, 
> whereas all N have to agree on the common interface. 

That's true, but the actual practice since the early days of EDI says 
it's best to have a combination of aspects that are standardized and 
aspects are negotiated between each pair of trading partners.  

The more aspects that are standardized, the easier it is to negotiate 
the operational interface between trading partners.

Plus, each trading partner usually has many other partners. So unless 
you want a different interface for each of your trading partners, the 
forces for uniform interface remain in play, even locally.

> I guess that you know as well as I do that agreements are fraught, 
> messy, political and expensive. I take that as a hint that reducing 
> that element of the _total_ cost is likely to be a win.

That still says to me, standardize as many aspects as possible, but 
keep the scope of each detailed trading contract as small as possible 
(e.g. two parties per).

> OTOH, on the common interface model every change requires global 
> renegotiation and reimplementation; 

That assumes everything is standardized and mandatory, doesn't it?

> and new particpants either have to 
> get along with what the first-movers already decided on whether or 
not 
> it's fully appropriate for them, or alternatively simply not become 
> participants at all (or become participants in something else). 
And, 
> again FWIW, I've seen data from several B2B exchanges that this 
last 
> problem is a real one ... they have a tough time signing up anyone 
> beyond the initial consortia.

There's a lot more to the B2B exchanges problems than common 
interfaces.  In fact, the major B2B exchanges I know about are all 
involved in efforts to create global uniform standards.  (I don't 
think interfaces have anything to do with their business problems, by 
the way, so standards won't help them either.)

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2855
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-11-20 16:46:03
Subject:Re: [rest-discuss] Re: fielding talks about waka at apachecon
Message:

bhaugen32 wrote,
> Miles Sabin wrote:
> > Just to spell this out a bit more, with multiple point-to-point
> > interfaces only two parties need to agree on any particular
> > interface, whereas all N have to agree on the common interface.
>
> That's true, but the actual practice since the early days of EDI says
> it's best to have a combination of aspects that are standardized and
> aspects are negotiated between each pair of trading partners.

Right, but isn't this conceeding the point? Once we have bilateral 
agreements we've departed from a common interface.

That said, I completely agree that where _partial_ global agreements are 
already in effect, then it would almost certainly help to factor them 
out of any bilateral agreement ... eg. we agree on TCP/IP and HTTP, 
XML, maybe REST, so no need to negotiate over them).

But that's a fixed, already sunk, cost. The problem is all the stuff 
that comes _afterwards_.

> The more aspects that are standardized, the easier it is to negotiate
> the operational interface between trading partners.

The trouble is that the higher you climb up the semantic ladder the 
harder this stuff becomes.

> Plus, each trading partner usually has many other partners. So unless
> you want a different interface for each of your trading partners, the
> forces for uniform interface remain in play, even locally.

That's already taken into account in the (admittedly crude) model I 
suggested ... I'm assuming O(logN) partners each (hence O(NlogN) 
trading pairs).

> > OTOH, on the common interface model every change requires global
> > renegotiation and reimplementation;
>
> That assumes everything is standardized and mandatory, doesn't it?

If it isn't, then how is it a common interface?

> > And, again FWIW, I've seen data from several B2B exchanges that this
> > last problem is a real one ... they have a tough time signing up
> > anyone beyond the initial consortia.
>
> There's a lot more to the B2B exchanges problems than common
> interfaces.

Oh, sure, I agree with that ;-)

> In fact, the major B2B exchanges I know about are all involved in
> efforts to create global uniform standards.  (I don't think interfaces
> have anything to do with their business problems, by the way, so
> standards won't help them either.)

Agreed ... but I take that as evidence that they're doomed ;-)

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2856
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-11-20 18:32:25
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

On Tuesday, November 19, 2002, at 08:13  PM, Mark Baker wrote:

> Note that Michael Radwin got the Web services comments backwards; they
> don't solve the N^2 problem, they are the N^2 problem.  Roy's point is
> that a uniform interface drives integration complexity to O(N) (which
> was Jeff's earlier comment)

Now, for the bonus bucks, give a comprehensive (formal) definition of 
"integration complexity."  (Please, please, please...  make my life 
easier. ;-)

jb







-----------------------------------------------------------------------------------
Post ID:2857
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-20 18:51:01
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

On Wed, Nov 20, 2002 at 12:32:25PM -0600, Jeff Bone wrote:
> Now, for the bonus bucks, give a comprehensive (formal) definition of 
> "integration complexity."  (Please, please, please...  make my life 
> easier. ;-)

Ha!  After you! 8-)

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2858
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-11-20 18:49:59
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

On Wednesday, November 20, 2002, at 10:01  AM, Miles Sabin wrote:

> I think this is a double-edged sword. Certainly the integration
> complexity is reduced. But OTOH the effort of reaching agreement on the
> common interface is increased.

Who says agreement has to be reached at all?  Take a look at the world: 
  most real innovation occurs as the result of one or a few persons 
defining / implementing disruptive technology that has good survival 
characteristics.  Once "in the wild," the masses simply adopt and adapt 
to this technology;  but once in the wild, this technology usually 
evolves slowly if at all.  (HTTP is certainly an example of this.)

Very little if any innovation happens as the result of a 
consensus-making process.  Progress is driven by unilateral invention, 
and the rest of the world just follows along.  Hence, optimizing a 
software architecture on its ability to minimize consensus-making 
efforts among its users is, IMHO, of little real value --- 
*particularly* if doing so increases the cost of its actual deployment 
and usage in the field.

> For multiple interfaces that'd give us,
>
>   O(NlogN)     cost of integration (ie. NlogN implemented interfaces)
>   O(NlogN)     cost of agreement   (ie. NlogN bilateral agreements)
>
> For a common interface it'd give us,
>
>   O(N)         cost of integration
>   O(2^N)       cost of agreement

Modification:  need to "weight" these costs.  As mentioned above, I 
believe that the top weight is in practice much greater than the bottom 
weight;  lots of effort gets spent on agreement, but most real progress 
happens by fiat or near-fiat.  (Case study:  rate of RFCs from IETF 
modulo number of participants at IETF meetings over history;  standards 
evolution through RFCs.)

> Notice that the cost of agreement won't scale down to the typical case
> for the common interface in the same way as it does for multiple
> interfaces, because the common interface still requires global
> agreement whether or not all parties need to communicate with each
> other.

It would be interesting to consider what the far-reaching implications 
are when you start with a bias of "everyone needs to *be able to* talk 
to everyone else" vs. "each party only needs to be able to talk to 
certain other parties."  Also interesting:  whether and to what extent 
assumption of a priori knowledge of "co-communicants" has any impact.

> Interestingly, the numbers above generate the exact opposite of the
> typical "network effect" on the common interface model ... we actually
> end up with _decreasing_ returns to scale.

Only if agreement-cost is weighted equal to or greater than 
integration-cost...

jb







-----------------------------------------------------------------------------------
Post ID:2859
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-11-20 19:10:02
Subject:Re: fielding talks about waka at apachecon
Message:

 Miles Sabin wrote:
> > the actual practice since the early days of EDI says
> > it's best to have a combination of aspects that are standardized 
and
> > aspects are negotiated between each pair of trading partners.
> 
> Right, but isn't this conceeding the point? Once we have bilateral 
> agreements we've departed from a common interface.

Of course, but it's conceding only part of the point:  there will be 
bilateral agreements.  It doesn't detract from the value of the 
common interface.  The common parts make the bilateral agreements 
much simpler and easier.  

For example, there are now and will continue to emerge "wannabe 
standard" business protocols for the order-to-cash cycle.

I expect (as in Jeff Bone parallel argument) a small number of these 
will be widely adopted and have identities (URIs and common names).  

At that point, the bilateral agreement can just say "let's use 
http://www.PrepaidDropShipOrder.std with these modifications".

As opposed to the several months and many thousands of dollars it 
takes now to negotiate bilateral EDI agreements...

> That said, I completely agree that where _partial_ global 
agreements are 
> already in effect, then it would almost certainly help to factor 
them 
> out of any bilateral agreement ... eg. we agree on TCP/IP and HTTP, 
> XML, maybe REST, so no need to negotiate over them).
> 
> But that's a fixed, already sunk, cost. The problem is all the 
stuff 
> that comes _afterwards_.
> 
> > The more aspects that are standardized, the easier it is to 
negotiate
> > the operational interface between trading partners.
> 
> The trouble is that the higher you climb up the semantic ladder the 
> harder this stuff becomes.

Of course.  Another aspect of agreement.

And WalMart may continue to use the WalMart proprietary flavor of 
everything for a long time to come...

Nothing's perfect.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2860
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-20 19:26:05
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

On Wed, Nov 20, 2002 at 11:01:45AM -0500, Miles Sabin wrote:
> I made related points offlist ... may as well repost them here ...

I was going to suggest that..

> 
> Mark Baker wrote,
> > what it says is that with Web services, integration complexity is
> > O(N^2), while O(N) with a common interface.
> 
> As an aside ...
> 
> I think this is a double-edged sword. Certainly the integration 
> complexity is reduced. But OTOH the effort of reaching agreement on the 
> common interface is increased.

Well, I'm not so sure.  I assume you're not referring to the
standardization portion of the interface, just the decision to use it
in the first place.

I would say that network effects, one the self-catalyzing point has been
reached, make it more expensive to not agree than to agree, the same
way that in 1995/1996, everybody *had* to have a Web site.

> I'd also conjecture that O(N^2) is a wildly pessimistic worst case 
> because in practice not everybody needs to talk to everybody else. You 
> only need O(NlogN) edges in a random graph to get complete 
> connectivity, so O(NlogN) seems like a good guess for the typical, as 
> opposed to the worst, case. FWIW ... not proof, but I've seen data from 
> a major (ie. one that hasn't gone bust yet ;-) B2B exchange which 
> supports this.

Agreed.

> And I also think that multiple interfaces are likely to scale better in 
> the face of growth and change (yup, I realize that this runs completely 
> counter to what _everyone_ else is saying ;-). That's because changes 
> are liable to be local, hence in the multiple interface case only 
> require local renegotiation and reimplementation; and because new 
> participants only have to reach agreements with the subset of existing 
> participants they actually need to communicate with.

Yah, I understand that position, I think.  But I think the Web has shown
that these sort of "local islands of closed-worldlyness" are spurious as
they succumb to the network effects inherrent in the integration,
anywhere, anytime approach of the Web.

As an example of this, I recently wanted to reference a Merriam Webster
definition of a word, but noticed that their primary interface to their
dictionary was via POST, not GET.  They do have a GET interface, which I
later found, but that's not obvious to people.  So dictionary.com is now
the defacto english language dictionary on the Web since its primary
interface is GET.  Goodbye M-W.

That's not exactly the situation you describe, but I think the basic
principles are the same.

There's also the simple maintenance issue that it's cheaper to update
one interface than two, so if you've got a service exposed to the world
via HTTP, then you might as well use that even for private agreements.

> OTOH, on the common interface model every change requires global 
> renegotiation and reimplementation; and new particpants either have to 
> get along with what the first-movers already decided on whether or not 
> it's fully appropriate for them, or alternatively simply not become 
> participants at all (or become participants in something else).

Yes, which is why incrementally deployed extensions are an absolutely
must.  The Web has no "off" switch.  HTTP, and things like RFC 2774
(which improved on that), were designed exactly for this.  Waka will
be even better, by the looks of it, with built in scoping and
mandatory extensions, like PEP and SOAP.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2861
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-11-20 19:28:24
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

Jeff Bone wrote,
> On Wednesday, November 20, 2002, at 10:01  AM, Miles Sabin wrote:
> > I think this is a double-edged sword. Certainly the integration
> > complexity is reduced. But OTOH the effort of reaching agreement on
> > the common interface is increased.
>
> Who says agreement has to be reached at all?
>
> Take a look at the world: most real innovation occurs as the result of
> one or a few persons defining / implementing disruptive technology
> that has good survival characteristics.  Once "in the wild," the
> masses simply adopt and adapt to this technology;  but once in the
> wild, this technology usually evolves slowly if at all.

In rare cases a proposal might be so instantly compelling that's it 
achieves widespread adoption without any kind of negotiation being 
needed.

But let's face it ... that's pretty rare.

> (HTTP is certainly an example of this.)

I think it almost certainly _isn't_ an example of this. Take a look 
through the HTTP WG archives and think how long it took for HTTP/1.1 to 
be widely implemented and deployed.

> Very little if any innovation happens as the result of a
> consensus-making process.

Agreed ... but we're not talking about innovation here, we're talking 
about the adoption of common interfaces. Anyone with a bright idea can 
strike out on their own, but it takes a different (and often more 
expensive) kind of effort to get everyone else to follow.

> Progress is driven by unilateral invention, and the rest of the world
> just follows along.

I admire your optimism, but I'm afraid I don't share it.

Also note that continuous unilateral innovation is _disruptive_ of 
existing standards ... a good thing IMO, and one which I think supports 
my argument.

> Hence, optimizing a software architecture on its ability to minimize
> consensus-making efforts among its users is, IMHO, of little real
> value --- *particularly* if doing so increases the cost of its actual
> deployment and usage in the field.

Well, YMMV ...

> > For multiple interfaces that'd give us,
> >
> >  O(NlogN)   cost of integration (ie. NlogN implemented interfaces) 
> >  O(NlogN)   cost of agreement   (ie. NlogN bilateral agreements)
> >
> > For a common interface it'd give us,
> >
> >   O(N)      cost of integration
> >   O(2^N)    cost of agreement
>
> Modification:  need to "weight" these costs.

Umm ... big-Oh means I _don't_ need to weight anything.

But yes, to relate these to euro/dollar prices they clearly need 
weighting. Nevertheless, 2^N will be bigger than NlogN for some values 
of N and the constant factors.

> As mentioned above, I believe that the top weight is in practice much
> greater than the bottom weight;  lots of effort gets spent on
> agreement, but most real progress happens by fiat or near-fiat.  (Case
> study:  rate of RFCs from IETF modulo number of participants at IETF
> meetings over history;  standards evolution through RFCs.)

Without numbers to attach to this, your belief is just as speculative as 
my conjectures. FWIW, I don't think measuring the raw number of 
published RFC is a particularly useful metric. Measuring the number of 
RFC that actually make it to STD or BCP might be more useful. Measuring 
the number of those that are actually widely deployed would be even 
more useful. And raw numbers of IETF participants isn't a useful metric 
either ... we really need a measure of the true costs (work hours, 
plane trips, implementation costs to achieve interoperability etc.).

> > Notice that the cost of agreement won't scale down to the typical
> > case for the common interface in the same way as it does for
> > multiple interfaces, because the common interface still requires
> > global agreement whether or not all parties need to communicate
> > with each other.
>
> It would be interesting to consider what the far-reaching
> implications are when you start with a bias of "everyone needs to *be
> able to* talk to everyone else" vs. "each party only needs to be able
> to talk to certain other parties."  Also interesting:  whether and to
> what extent assumption of a priori knowledge of "co-communicants" has
> any impact.

Agreed.

As I said, I only have a conjecture and some anecdotal evidence. It'd be 
very interesting to see some serious research work done on this.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2862
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-11-20 19:37:27
Subject:RE: [rest-discuss] fielding talks about waka at apachecon
Message:

> Now, for the bonus bucks, give a comprehensive (formal) definition of 
> "integration complexity."  (Please, please, please...  make my life 
> easier. ;-)
> 
> jb

If this is a joke, I don't quite get it.  The "complexity" referred to
in the Big-Oh expressions is simply the number of interface mismatches
that have to be dealt with, isn't it?

Jeff, you may have to settle for having your life being made simpler,
but not easier.

Walden






-----------------------------------------------------------------------------------
Post ID:2863
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-11-20 19:40:19
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

Mark Baker wrote,
> On Wed, Nov 20, 2002 at 11:01:45AM -0500, Miles Sabin wrote:
> > And I also think that multiple interfaces are likely to scale
> > better in the face of growth and change (yup, I realize that this
> > runs completely counter to what _everyone_ else is saying ;-).
> > That's because changes are liable to be local, hence in the
> > multiple interface case only require local renegotiation and
> > reimplementation; and because new participants only have to reach
> > agreements with the subset of existing participants they actually
> > need to communicate with.
>
> Yah, I understand that position, I think.  But I think the Web has
> shown that these sort of "local islands of closed-worldlyness" are
> spurious as they succumb to the network effects inherrent in the
> integration, anywhere, anytime approach of the Web.

If there were always "network effects inherrent in the integration, 
anywhere, anytime approach of the Web" then I'd have to agree with you. 
But this is really the point at issue. I'm not at all convinced that 
those network effects are always there. Or if they are, their combined 
with a whole bunch of other effects which pull in the opposite 
direction. 

> As an example of this, I recently wanted to reference a Merriam
> Webster definition of a word, but noticed that their primary
> interface to their dictionary was via POST, not GET.  They do have a
> GET interface, which I later found, but that's not obvious to people.
> So dictionary.com is now the defacto english language dictionary on
> the Web since its primary interface is GET.  Goodbye M-W.

Do you have any evidence that this is a "GET vs. POST" issue rather than 
a "dictionary.com is easier to spell than miriam-wibster.com" issue? Or 
better content? Or a better UI (in ways orthogonal to REST)?

> There's also the simple maintenance issue that it's cheaper to update
> one interface than two, so if you've got a service exposed to the
> world via HTTP, then you might as well use that even for private
> agreements.

Not necessarily. Simple maintenance is often evolution (I'm sure you've 
had the experience of a bug fix requiring a non-backwards compatible 
change). Evolution needs agreement, and it's easier to get two parties 
to agree to a change than three ... or three hundred.

> > OTOH, on the common interface model every change requires global
> > renegotiation and reimplementation; and new particpants either have
> > to get along with what the first-movers already decided on whether
> > or not it's fully appropriate for them, or alternatively simply not
> > become participants at all (or become participants in something
> > else).
>
> Yes, which is why incrementally deployed extensions are an absolutely
> must.  The Web has no "off" switch.  HTTP, and things like RFC 2774
> (which improved on that), were designed exactly for this.  Waka will
> be even better, by the looks of it, with built in scoping and
> mandatory extensions, like PEP and SOAP.

Agreed completely ... which is why Waka is a new protocol rather than an 
extension of HTTP.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2864
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-11-20 19:43:32
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

On Wednesday, November 20, 2002, at 01:37  PM, Mathews, Walden wrote:

>> Now, for the bonus bucks, give a comprehensive (formal) definition of
>> "integration complexity."  (Please, please, please...  make my life
>> easier. ;-)
>>
>> jb
>
> If this is a joke, I don't quite get it.  The "complexity" referred to
> in the Big-Oh expressions is simply the number of interface mismatches
> that have to be dealt with, isn't it?

Sure.  And that's an easy thing to intuit and to reason about...  but 
turning that into a useful metric for system complexity has kept me up 
way too late many nights over the last couple of years...  it's a 
subtle and slippery topic.  :-)

> Jeff, you may have to settle for having your life being made simpler,
> but not easier.

I can be satisfied with that. ;-)

jb







-----------------------------------------------------------------------------------
Post ID:2865
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-11-20 19:56:41
Subject:Waka vs WebDAV, was: [rest-discuss] fielding talks about waka at apachecon
Message:

Hi,

does anybody know what Roy is referring to when he says:

"Authoring methods (DAV simplified)
- elimination on non-resource identifiers
"

Maybe QNames that identify properties?

Julian

[1] <http://www.apache.org/~fielding/waka/200211_fielding_apachecon.ppt>

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 







-----------------------------------------------------------------------------------
Post ID:2866
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-11-20 21:12:21
Subject:RE: [rest-discuss] fielding talks about waka at apachecon
Message:

> > If this is a joke, I don't quite get it.  The "complexity" 
> referred to
> > in the Big-Oh expressions is simply the number of interface 
> mismatches
> > that have to be dealt with, isn't it?
> 
> Sure.  And that's an easy thing to intuit and to reason about...  but 
> turning that into a useful metric for system complexity has 
> kept me up 
> way too late many nights over the last couple of years...  it's a 
> subtle and slippery topic.  :-)

The operative word being 'useful' I suppose.  Complexity measure is
just a measure of the number of pieces something has, but that might
vary according to perspective, and not knowing yours, I'm powerless
to comment.

WM






-----------------------------------------------------------------------------------
Post ID:2867
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-11-20 21:22:58
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

On Wednesday, November 20, 2002, at 01:28  PM, Miles Sabin wrote:

> In rare cases a proposal might be so instantly compelling that's it
> achieves widespread adoption without any kind of negotiation being
> needed.
>
> But let's face it ... that's pretty rare.

What's rare is for any technology-by-consensus to achieve enough 
initial adoption to be relevant.

OTOH, almost every technology that is broadly relevant in our industry 
was designed essentially by fiat by a small number of people and 
evolved --- slowly --- through consensus only after the adoption curve 
had already been ascended.  SMTP.  DNS.  POP.  IMAP.  HTTP.  Etc., 
etc., etc.

>
>> (HTTP is certainly an example of this.)
>
> I think it almost certainly _isn't_ an example of this. Take a look
> through the HTTP WG archives and think how long it took for HTTP/1.1 to
> be widely implemented and deployed.

Exactly.  This is an example of slow evolution once out "in the wild" 
--- slowness caused by the consensus-making effort.  But the adoption 
curve had already been mostly ascended at that point.

>> Very little if any innovation happens as the result of a
>> consensus-making process.
>
> Agreed ... but we're not talking about innovation here, we're talking
> about the adoption of common interfaces. Anyone with a bright idea can
> strike out on their own, but it takes a different (and often more
> expensive) kind of effort to get everyone else to follow.

That's true.  My point is that in the best examples of rapid adoption 
of technology that we've got to work with --- the Web, for instance --- 
the "common interface" that drives initial adoption is *not* the result 
of a consensus-building effort, but rather a unilateral innovation.

>> Progress is driven by unilateral invention, and the rest of the world
>> just follows along.
>
> I admire your optimism, but I'm afraid I don't share it.

Actually, I don't see that as optimism at all --- more like something 
between pragmatism and fatalism.  It would be great if it were the case 
that technological progress (wrt network protocols, for example) could 
be driven farther and faster by cooperative groups.  Unf., there's 
almost a reverse scaling factor;  the more heads get thrown at a 
problem, the less progress is made.  I wouldn't call that realization 
"optimism" --- it relies on gestalt to drive things forward.

And this isn't a philosophical position I particularly like, either.  
OTOH, look around:  in the protocol and "killer app" worlds, you can 
clearly identify in every instance a small number of individuals who 
drove initial adoption and deployment.

> Also note that continuous unilateral innovation is _disruptive_ of
> existing standards ... a good thing IMO, and one which I think supports
> my argument.

I think we're arguing two different things, here.  I'm arguing about 
how technological innovation and proliferation happens, you're talking 
about how technology incrementally evolves.

> Umm ... big-Oh means I _don't_ need to weight anything.

Actually, you're using big-Oh to measure dimensionless scalar 
quantities.  What I'm saying is that you assume that you're using the 
*same* dimensionless scalar in both cases, and that's not a safe 
assumption.

> As I said, I only have a conjecture and some anecdotal evidence. It'd 
> be
> very interesting to see some serious research work done on this.

If I ever manage to hit it big again, and manage to get out of the 
market with the shirt on my back, I'd like to do some "serious" 
research work on this.

:-)

jb







-----------------------------------------------------------------------------------
Post ID:2868
Sender:Joe Gregorio <joe@...>
Post Date/Time:2002-11-20 20:48:30
Subject:RESTLog
Message:

I am working on a REST based weblog interface, described here:

    http://wellformedweb.org/RESTLog.cgi/5

the design of which is heavily influenced by:

    http://internet.conveyor.com/RESTwiki/moin.cgi/RestifyingBlogger

Before I get too far along I want to make 
sure I haven't wandered off into the weeds.
Any feedback would be greatly appreciated.

	Thanks,
	-joe

-- 
http://BitWorking.org
http://WellFormedWeb.org








-----------------------------------------------------------------------------------
Post ID:2869
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-11-20 21:54:00
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

One other thought.

On Wednesday, November 20, 2002, at 10:01  AM, Miles Sabin wrote:

> I'd also conjecture that O(N^2) is a wildly pessimistic worst case
> because in practice not everybody needs to talk to everybody else. You
> only need O(NlogN) edges in a random graph to get complete
> connectivity, so O(NlogN) seems like a good guess for the typical, as
> opposed to the worst, case. FWIW ... not proof, but I've seen data from
> a major (ie. one that hasn't gone bust yet ;-) B2B exchange which
> supports this.

I would agree that O(N log N) is a sound estimate in this case...

> For multiple interfaces that'd give us,
>
>   O(NlogN)     cost of integration (ie. NlogN implemented interfaces)
>   O(NlogN)     cost of agreement   (ie. NlogN bilateral agreements)
>
> For a common interface it'd give us,
>
>   O(N)         cost of integration
>   O(2^N)       cost of agreement

Another thing this misses is the asymmetry between consumers of an 
interface and producers of an interface;  i.e., for most interfaces, 
the producer of an interface is not dependent on consensus among all 
intended consumers.  In fact, in the open-world of the Web, the 
producer usually cannot even know a priori more than a very small 
subset of consumers, much less seek consensus among them.

So N in the integration case is the number of interfaces, while in the 
agreement case there's really a different quantity involved --- M, the 
number of parties to the agreement a priori.  And M is guaranteed to be 
a miniscule value relative to N.  M != N!  Perhaps the notation should 
reflect this;  better to say something like:

Closed world assumption, full participation of parties to agreement, 
type-specific interfaces:

O(N log N) integration cost (N = number of implemented interfaces)
O(N * M log M) consensus cost (M = number of bilateral agreements == 
total number of participants)

Open world assumption, many non-agreeing consumers, generic interfaces:

O(N) integration cost
O(N * Q log Q) consensus cost (Q = producers / consumers party to 
agreement, Q << M)


jb







-----------------------------------------------------------------------------------
Post ID:2870
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-21 02:54:41
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

Mathews, Walden wrote:

>
> A couple of minor points on big O.  First "uniform interface drives
> integration complexity to O(N)" is too easy to be true.  It doesn't
> take into account that while there is much similarity among peer 
> businesses, there is also individuality, a/k/a competitive edge, which 
> mandates, to a degree, custom interfaces.  "Uniform interface" is like 
> "software process improvement".  You use it to factor away known 
> redundancy, but no more. 

I think that this is an important point. To me, REST is about 
standardizing what can be standardized. It doesn't take a rocket 
scientist to recognize that addressing models can and should be 
standardized (or it might have taken a rocket scientist in the late 
1990s, but it shouldn't today).

Similarly, it doesn't take a rocket scientist to see that it is possible 
to standardize the method you use to to report or modify the state of a 
resource, or request the destruction of a resource.

But applications do not consist of those two things so there will ALWAYS 
be effort in integrating applications. Just not necessarily in 
integrating their addressing schemes and method names.

> Secondly, your position in the scheme of things determines whether you,
> personally will feel integration as O(N) or O(N^2) or something else.
> Basically, God is the only one with the N^2 problem, because it's the
> system view of the system.  An individual newcomer to a party without
> uniform interfaces causes an integration problem (for itself and all 
> others
> who wish to integrate with him) with a sum total of O(N).  Over time,
> from historical (God) perspecive, you would observe the N^2 thing, but
> it's not a price paid daily.

You don't observe the whole price daily, but when the newcomer cannot 
even conceptualize their service because the integration costs are so 
massive, the overall ecology pays the price.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2871
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-21 02:56:13
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

N is the number of web-based services (not HTTP server implementations, 
but the number of services that use Web infrastructure). That number is 
in the millions. The number of people who "agreed" on the details of 
HTTP are in the hundreds. I don't see how you can plausibly argue that 
there is an O(2^N) relationship there. Much more often, the majority of 
the people who adhere to a standard learn about it long after the 
standardization process is done. They buy the books that describe the 
standard (see also HTML). They don't even really "agree" to use it -- 
certainly not bilaterally, anyhow! They just use what everyone else is 
using, sometimes without even really wanting to!

I really don't by the thesis that standards are created (or even 
adopted) through "agreement" between implementors and users.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2872
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-11-21 09:39:46
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

Jeff Bone wrote,
[snip: lots of stuff I largely agree with]
> I think we're arguing two different things, here.  I'm arguing about
> how technological innovation and proliferation happens, you're
> talking about how technology incrementally evolves.

Yes, I think that's possible.

But I think that the main point I'm trying to make is that just like 
"internet time", the idea of bandwagon and network effects have been 
bandied around a little too lazily. The technological environment is 
subject to many forces pulling in many different directions, and I 
think that the phenomenon I've pointed to can, in at least some 
circumstances, act as a counterveiling pressure to network effects.

I take your point that the initial takeoff of a new technology might 
look more like a bandwagon than a consensus forming process. 
Nevertheless, I can't help wondering if this is partly due to focussing 
primarily on technologies which _did_ take off and ignoring the many 
others that fell by the wayside. Perhaps there's no need for explicit 
agreement, but there is a need to attract attention and foster 
adoption. And that fails more often than not ... just look at the 
activity levels of, eg., SourceForge projects. To a certain extent, I 
think you may be pointing to the successful bandwagons and saying "Hey! 
Look! Getting a bandwagon going isn't all _that_ hard".

I think I'm pointing to a later stage in the game where new technologies 
are applied in pre-existing environments with pre-exisiting 
constraints. It's not so much the technology which is the focus of 
consensus forming, but the details of making it work in any given 
context. And I'm also pointing to higher-level and narrower agreements 
... not about TCP/IP or HTTP or REST or SOAP, but, eg., about how 
widget consumers and producers can use those technologies to buy and 
sell widgets. The semantic escalation makes agreement harder ("just 
what _is_ a widget anyway?") and the narrower constituency means that 
we're a long way from perfect markets (producers and consumers might 
know each other, individual producers/consumers can influence the 
market, political and strategic conflicts loom large).

Clearly things aren't _always_ like that. But equally we're not always 
in the free market of ideas.

I'm also a little non-plussed, because it seems as tho' your argument 
from heroic innovation also undercuts Mark/Roy's original point (but in 
a different way from my argument). The original claim was that a 
uniform interface drives integration complexity to O(N). Heroic 
innovation says "screw the common interface, I'm going _this_ way, 
follow me if you dare". That might settle down to a _new_ common 
interface later ... but if it does I'll bet there will have had to be a 
lot of consensus forming first.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2873
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-11-21 10:01:24
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

Paul Prescod wrote,
> N is the number of web-based services (not HTTP server
> implementations, but the number of services that use Web
> infrastructure). That number is in the millions.

Actually, it's the number of _types_ of web-based services. Those types 
_potentially_ number in the millions, but I think we're a long way from 
that at the moment. And many of those types are of extremely narrow 
applicability and have a correspondingly narrow constituency with 
correspondingly more entrenched vested interests.

> The number of people who "agreed" on the details of HTTP are in the
> hundreds. I don't see how you can plausibly argue that there is an
> O(2^N) relationship there.

Right, but that's because HTTP is general purpose infrastructure, and 
that gets you a natural split between the producers and the largely 
passive consumers. The hundreds who were involved in the process 
represented a significant slice of the producers of that 
infrastructure.

But not everything is general purpose infrastructure. The closer you get 
to the domain-specific the more the biases and interests of the 
participants come to the fore. And that's when consensus forming is 
needed.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:2874
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-21 19:30:50
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

Mark Baker wrote:

> Wow!  A lot more good stuff on Waka than he had previously discussed.
> RENDER?  Hmm, interesting.  Not sure why an extended POST wouldn't
> suffice for that, but I suppose a new method could be an optimization.

I believe RENDER is safe and idempotent. I asked him about it at a 
conference many months ago and I understood what it meant then but am 
not confident in my memory anymore.

Based on this dim recollection I hypothesize that RENDER is about the 
difference between retrieving a rendition and retrieving the "most 
semantically rich" version: DocBook rather than HTML, SVG rather than GIF.

> MONITOR sounds familiar. 8-)

Yes, that will be very interesting. He also mentioned unsolicited 
responses from servers to clients which is something that HTTP has long 
needed.

> Note that Michael Radwin got the Web services comments backwards; they
> don't solve the N^2 problem, they are the N^2 problem.  Roy's point is
> that a uniform interface drives integration complexity to O(N) (which

> was Jeff's earlier comment)

I think that the issue is pretty subtle...if the problem is to connect 
your accounting system to my account auditing system, agreeing on Waka 
methods and addressing is not going to collapse the problem to O(N). You 
need many other levels of agreement. The problem with SOAP/WSDL is that 
they don't standardize the things that CAN be standardized, with the 
most obvious examples being the addressing model and the GET method.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2875
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-21 19:48:50
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> > MONITOR sounds familiar. 8-)
>
> Yes, that will be very interesting. He also mentioned unsolicited
> responses from servers to clients which is something that HTTP has long
> needed.
A response is always solicited due to a request (unless you have multiple
responses or something, but there is still a cause).
Perhaps this means a response not on the same connection - which implies
message correlation. (Implied message correlation via a socket connection
was a great enabling simplification, but adding more complexity will
increase capability)








-----------------------------------------------------------------------------------
Post ID:2876
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-21 19:52:44
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

> 4. Metadata unable to come after data

> I also like the fact that due to the asynchronicity of the protocol, you
can interleave data and metadata.
> This could be pretty handy if you realized that you needed to issue a
Set-Cookie header in the middle of a response.

I don't know the details, but this sounds like it may be easier for the
server to send a stream of information, but it seems to cause clients to
buffer the data until the end of the response which could be disastrous for
perceived response time of a UI. It also might hurt the ability to do
streaming responses if the metadata affects the processing of the streaming
data.






-----------------------------------------------------------------------------------
Post ID:2877
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-21 21:06:39
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

S. Mike Dierken wrote:

> ----- Original Message -----
> From: "Paul Prescod"
>
> >>MONITOR sounds familiar. 8-)
> >
> >Yes, that will be very interesting. He also mentioned unsolicited
> >responses from servers to clients which is something that HTTP has long
> >needed.
>
> A response is always solicited due to a request (unless you have 
> multiple responses or something, but there is still a cause).

 From the presentation:

Unsolicited Responses
	Cache invalidation messages
	Multicast event notices

So yes, there was probably a cause, but this particular response is not 
necessarily correlated with any particular request.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2878
Sender:Phil Eskelin <philip.eskelin@...>
Post Date/Time:2002-11-21 21:19:42
Subject:RE: [rest-discuss] fielding talks about waka at apachecon
Message:

Paul wrote:
> Mark wrote:
> > MONITOR sounds familiar. 8-)
> >
> > Yes, that will be very interesting. He also mentioned unsolicited 
> > responses from servers to clients which is something that HTTP has
> > long needed.

I'm not sure I understand the notion of an unsolicited response, but I think
MONITOR is a great idea.  In spending time trying to think of an approach
for RESTful event notifications that simple, honest plain folks would
understand, I've concluded that a method like MONITOR is the best approach,
since the only alternative seems to be a bunch of state transfers between
publisher, message bus, and subscriber.

Does "unsolicited responses" refer to the zero or more subsequent
state-change notifications that occur from a MONITOR request?

Philip

________________________________________________________________________
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden. TradeWeb reserves the right to monitor all
e-mail communications through its networks.






-----------------------------------------------------------------------------------
Post ID:2879
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-11-21 21:27:26
Subject:RE: [rest-discuss] fielding talks about waka at apachecon
Message:

It's just wording, really, but keeping the lingo clean would
probably mean using some term other than 'response' to mean
unsolicited communiations, and reserving 'response' as the
counterpart to a request.  But what is solicited becomes grey
upon analysis...

Walden

> -----Original Message-----
> From: Paul Prescod [mailto:paul@...]
> Sent: Thursday, November 21, 2002 4:07 PM
> To: S. Mike Dierken
> Cc: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] fielding talks about waka at apachecon
> 
> 
> S. Mike Dierken wrote:
> 
> > ----- Original Message -----
> > From: "Paul Prescod"
> >
> > >>MONITOR sounds familiar. 8-)
> > >
> > >Yes, that will be very interesting. He also mentioned unsolicited
> > >responses from servers to clients which is something that 
> HTTP has long
> > >needed.
> >
> > A response is always solicited due to a request (unless you have 
> > multiple responses or something, but there is still a cause).
> 
>  From the presentation:
> 
> Unsolicited Responses
> 	Cache invalidation messages
> 	Multicast event notices
> 
> So yes, there was probably a cause, but this particular 
> response is not 
> necessarily correlated with any particular request.
> 
>   Paul Prescod
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
> 






-----------------------------------------------------------------------------------
Post ID:2880
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-21 21:43:51
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

----- Original Message -----
From: "Mathews, Walden" <walden.mathews@...>


> It's just wording, really, but keeping the lingo clean would
> probably mean using some term other than 'response' to mean
> unsolicited communiations, and reserving 'response' as the
> counterpart to a request.  But what is solicited becomes grey
> upon analysis...

I'd start with 'unsolicited message' until we figure out what kind of
message it is - request, response to a request, or event (where 'event' is a
new type of message) or 'other'.

I did a project where I defined the message types and sequence as:
- 1 request
- 0-n notifications events indicating interim status of request
- 1 response indicating final status of request (closing the request)

Events were purely advisory and optional. In HTTP the 202 Accepted response
status is like an inital notification, but with no defined means to deliver
the final response.








-----------------------------------------------------------------------------------
Post ID:2881
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-22 07:03:08
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

On Thu, Nov 21, 2002 at 11:30:50AM -0800, Paul Prescod wrote:
> I think that the issue is pretty subtle...if the problem is to connect 
> your accounting system to my account auditing system, agreeing on Waka 
> methods and addressing is not going to collapse the problem to O(N). You 
> need many other levels of agreement. The problem with SOAP/WSDL is that 
> they don't standardize the things that CAN be standardized, with the 
> most obvious examples being the addressing model and the GET method.

Sure.  Another way of saying that is that, apples-to-apples, looking
only at the interfaces, not the data you pass through them, it's O(N)
vs. O(NlogN).

Much useful data integration is also opaque, and therefore O(N).  Any
non-processed, aggregate data feed, like typical news & stock quote
feeds, is opaque.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2882
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-11-22 10:18:38
Subject:dave winer on REST vs SOAP
Message:

http://scriptingnews.userland.com/backissues/2002/11/21#restVsSoap

i'll let you draw your own conclusions about this; suffice to say i take
anything winer says with a pinch of salt since reading his contributions
to the recent RDF flamewar.

found here:
http://use.perl.org/~gnat/journal/9071







-----------------------------------------------------------------------------------
Post ID:2883
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-11-22 13:33:38
Subject:Re: [rest-discuss] dave winer on REST vs SOAP
Message:

Hmm... why is it that people keep comparing REST to SOAP?  This is an
apples-to-oranges comparison (possible more like fruit-to-apples).  There is
no REST toolkit because REST is not an implementable specification, just an
architectural style.  It seems to me that Dave's comments do nothing more
than show he doesn't understand what REST is.  I would have given a bit more
credit to his opinion if he had instead asked/answered why SOAP isn't
RESTful.

Interestingly, (while I think that Dave should know better) I think this is
one of the bigger stumbling blocks to the acceptance of REST.  When I first
heard about it, I too thought it was something like SOAP, XML-RPC, etc.
This may be due to the fact that few people talk about REST separately from
HTTP (at least outside of this list).  As a result, I believe many people
look at REST as competition instead of just another tool to (possibly)
improve what they are working on.

Hey, maybe we all need to come up with a single e-mail sig that says
something to this effect.  If we all use it, maybe people will take notice
and get over some of the incorrect notions they have.  How about:

REST doesn't make the things you use.  REST makes the things you use better.

:)

---
Seairth Jacobs
seairth@...


----- Original Message -----
From: "Vincent D Murphy" <vdm@...>
To: <rest-discuss@yahoogroups.com>
Sent: Friday, November 22, 2002 5:18 AM
Subject: [rest-discuss] dave winer on REST vs SOAP


> http://scriptingnews.userland.com/backissues/2002/11/21#restVsSoap
>
> i'll let you draw your own conclusions about this; suffice to say i take
> anything winer says with a pinch of salt since reading his contributions
> to the recent RDF flamewar.
>
> found here:
> http://use.perl.org/~gnat/journal/9071
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>







-----------------------------------------------------------------------------------
Post ID:2884
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-11-22 14:43:29
Subject:RE: [rest-discuss] dave winer on REST vs SOAP
Message:

The value of REST is something akin to that of common sense,
which is never a big marketing force, no matter how valuable
it may be in practice.

While the comparison between REST and SOAP may seem ill conceived
to those in the know, it's the first line of distinction that
someone embarking on a web services project will encounter,
and there _is_ direct conflict between the poorer practices in
SOAP use and the *constraints* of REST.  So the dichotomy is
not entirely fictional.

This is a bad few decades for *constraints*, for some reason which
I'm not clear on.  The people who truly believe "less is more"
are, well, few... It would seem.

Walden

> -----Original Message-----
> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Friday, November 22, 2002 8:34 AM
> To: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] dave winer on REST vs SOAP
> 
> 
> Hmm... why is it that people keep comparing REST to SOAP?  This is an
> apples-to-oranges comparison (possible more like 
> fruit-to-apples).  There is
> no REST toolkit because REST is not an implementable 
> specification, just an
> architectural style.  It seems to me that Dave's comments do 
> nothing more
> than show he doesn't understand what REST is.  I would have 
> given a bit more
> credit to his opinion if he had instead asked/answered why SOAP isn't
> RESTful.
> 
> Interestingly, (while I think that Dave should know better) I 
> think this is
> one of the bigger stumbling blocks to the acceptance of REST. 
>  When I first
> heard about it, I too thought it was something like SOAP, 
> XML-RPC, etc.
> This may be due to the fact that few people talk about REST 
> separately from
> HTTP (at least outside of this list).  As a result, I believe 
> many people
> look at REST as competition instead of just another tool to (possibly)
> improve what they are working on.
> 
> Hey, maybe we all need to come up with a single e-mail sig that says
> something to this effect.  If we all use it, maybe people 
> will take notice
> and get over some of the incorrect notions they have.  How about:
> 
> REST doesn't make the things you use.  REST makes the things 
> you use better.
> 
> :)
> 
> ---
> Seairth Jacobs
> seairth@...
> 
> 
> ----- Original Message -----
> From: "Vincent D Murphy" <vdm@...>
> To: <rest-discuss@yahoogroups.com>
> Sent: Friday, November 22, 2002 5:18 AM
> Subject: [rest-discuss] dave winer on REST vs SOAP
> 
> 
> > http://scriptingnews.userland.com/backissues/2002/11/21#restVsSoap
> >
> > i'll let you draw your own conclusions about this; suffice 
> to say i take
> > anything winer says with a pinch of salt since reading his 
> contributions
> > to the recent RDF flamewar.
> >
> > found here:
> > http://use.perl.org/~gnat/journal/9071
> >
> >
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/
>
>
>


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2885
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-22 17:06:01
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

On Thu, Nov 21, 2002 at 11:48:50AM -0800, S. Mike Dierken wrote:
> 
> ----- Original Message -----
> From: "Paul Prescod" <paul@...>
> 
> > > MONITOR sounds familiar. 8-)
> >
> > Yes, that will be very interesting. He also mentioned unsolicited
> > responses from servers to clients which is something that HTTP has long
> > needed.
> A response is always solicited due to a request (unless you have multiple
> responses or something, but there is still a cause).
> Perhaps this means a response not on the same connection - which implies
> message correlation. (Implied message correlation via a socket connection
> was a great enabling simplification, but adding more complexity will
> increase capability)

I could imagine a non-opaque message identifier that when used opaquely,
identified message equivalence, but could also be used to correlate
messages as part of a single transaction.  Or perhaps do that as two
separate opaque URIs so that the transaction the message each had their
own URI.  Haven't thought it through.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2886
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-22 17:12:53
Subject:Re: [rest-discuss] fielding talks about waka at apachecon
Message:

On Thu, Nov 21, 2002 at 11:52:44AM -0800, S. Mike Dierken wrote:
> 
> > 4. Metadata unable to come after data
> 
> > I also like the fact that due to the asynchronicity of the protocol, you
> can interleave data and metadata.
> > This could be pretty handy if you realized that you needed to issue a
> Set-Cookie header in the middle of a response.
> 
> I don't know the details, but this sounds like it may be easier for the
> server to send a stream of information, but it seems to cause clients to
> buffer the data until the end of the response which could be disastrous for
> perceived response time of a UI. It also might hurt the ability to do
> streaming responses if the metadata affects the processing of the streaming
> data.

Possible.  But I'm more concerned with implementation complexity, both
of a library, and of applications using the library.  Not all of the
complexity can be isolated from the app.

Are there enough application protocol library developer gurus around
that would know how to build such a library?  I'd guess there would be
an order of magnitude less people qualified to build such a beast.
Would that hurt Waka's chance of success?  I think it could, even if
Roy does lead a libwww-waka project.

Knowing Roy, I'm sure he's considered all this.  Either he feels that
the pros will outweigh the cons, or he's got something in mind for to
address the cons.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2887
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-11-22 17:52:15
Subject:Re: fielding talks about waka at apachecon
Message:

Mark Baker wrote:
> I could imagine a non-opaque message identifier that when used 
opaquely,
> identified message equivalence, but could also be used to correlate
> messages as part of a single transaction.  Or perhaps do that as two
> separate opaque URIs so that the transaction the message each had 
their
> own URI.  Haven't thought it through.

Please try.  This smells suspiciously like the "correlation IDs" from 
mailbox-and-dispatcher-SOAP that we trashed in a previous thread in 
this list.

Why can't messages that are part of a conversation be related by 
references to the same URI, identifying a resource that they are 
conversing about?

E.g. hypertext as engine of coordination.







-----------------------------------------------------------------------------------
Post ID:2888
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-11-22 18:26:24
Subject:Re: [rest-discuss] dave winer on REST vs SOAP
Message:

Where does Dave come up with some of this stuff?

Ridiculous.

jb







-----------------------------------------------------------------------------------
Post ID:2889
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-22 18:37:38
Subject:Re: [rest-discuss] dave winer on REST vs SOAP
Message:

Vincent D Murphy wrote:

> http://scriptingnews.userland.com/backissues/2002/11/21#restVsSoap
>
> i'll let you draw your own conclusions about this; suffice to say i take
> anything winer says with a pinch of salt since reading his contributions
> to the recent RDF flamewar.

You can't take anything Dave Winer says seriously. First, you can't 
believe anything he says because he spins like no tomorrow. Second, you 
can't take it personally because life is too short. If he wants to think 
we are against GUIs (!?!?!?) then I'll just take a deep breath and let 
him think what he wants. I was glad to read that Dave believes that SOAP 
is about taking the Internet and treating it like a LAN. I couldn't have 
said it better myself. ;)

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2890
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-22 18:42:49
Subject:Re: [rest-discuss] dave winer on REST vs SOAP
Message:

Seairth Jacobs wrote:

> Hmm... why is it that people keep comparing REST to SOAP?  This is an
> apples-to-oranges comparison (possible more like fruit-to-apples). 
> There is no REST toolkit because REST is not an implementable 
> specification, just an architectural style.  It seems to me that 
> Dave's comments do nothing more than show he doesn't understand what 
> REST is.  I would have given a bit more credit to his opinion if he 
> had instead asked/answered why SOAP isn't RESTful.

On the one hand, it is true that Dave doesn't understand what REST is. 
On the other hand, he has been told what it is several times, and it 
would only take a willingness to read his own inbox to understand why 
the things he said are BS. In fact, I'm sure as he was writing them, he 
knew what the counter-arguments were. But he sees everything in 
political terms and REST was not properly designed to be a political 
technology. It has an unweildy acronym and it is more about telling 
people to use stuff in the right way rather than selling them something 
new and improved.

> REST doesn't make the things you use.  REST makes the things you use 
> better.

I like it.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2891
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-22 19:22:35
Subject:Transactions
Message:

On Fri, Nov 22, 2002 at 05:52:15PM -0000, bhaugen32 wrote:
> Mark Baker wrote:
> > I could imagine a non-opaque message identifier that when used 
> opaquely,
> > identified message equivalence, but could also be used to correlate
> > messages as part of a single transaction.  Or perhaps do that as two
> > separate opaque URIs so that the transaction the message each had 
> their
> > own URI.  Haven't thought it through.
> 
> Please try.  This smells suspiciously like the "correlation IDs" from 
> mailbox-and-dispatcher-SOAP that we trashed in a previous thread in 
> this list.
> 
> Why can't messages that are part of a conversation be related by 
> references to the same URI,

That's what I'm suggesting be done, by identifying the transaction
by a URI.

For example, we might exchange messages and refer to a transaction
that identifies some persistent contract that governs the rules of
all messages sent as part of that contract.  I recall you using an
example like this before.

> identifying a resource that they are 
> conversing about?

I think that's a different thing, though perhaps you misspoke, or I'm
misinterpreting you.  I take that to mean the URI in the HTTP request
line, e.g. "GET http://example.org/foo", rather than a URI identifying
some context in which the conversation is occuring (while remaining
stateless).

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2892
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-22 20:04:38
Subject:Re: [rest-discuss] dave winer on REST vs SOAP
Message:

On Fri, Nov 22, 2002 at 10:37:38AM -0800, Paul Prescod wrote:
> I was glad to read that Dave believes that SOAP 
> is about taking the Internet and treating it like a LAN. I couldn't have 
> said it better myself. ;)

Yah, exactly.  That's what I responded to in my blog;

http://www.markbaker.ca/blog/2002/11/21#2002-11-winer-soap-rest

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2893
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-11-22 20:10:01
Subject:Re: Transactions
Message:

Mark Baker 
> > Why can't messages that are part of a conversation be related by 
> > references to the same URI,
> 
> That's what I'm suggesting be done, by identifying the transaction
> by a URI.

Ok, I misunderstood.  

> For example, we might exchange messages and refer to a transaction
> that identifies some persistent contract that governs the rules of
> all messages sent as part of that contract.  I recall you using an
> example like this before.

Yes, precisely.  For example, here is the UN/ECE recommended 
agreement for Offer-Acceptance transactions:
http://www.unece.org/cefact/rec/rec31/rec31_2000_00tr257.pdf
 
That's what I've been using as my prototype for such things.  I think 
we have demonstrated that it could be RESTified, although I don't 
think all the details have been worked out yet.

Once RESTified, it could be given a computable representation (e.g. 
XML or RDF, both of which UN/CEFACT is already working on) and 
referenced in all offer-acceptance transactions governed by that 
agreement.

> > identifying a resource that they are 
> > conversing about?
> 
> I think that's a different thing, though perhaps you misspoke, or 
I'm
> misinterpreting you.  I take that to mean the URI in the HTTP 
request
> line, e.g. "GET http://example.org/foo", rather than a URI 
identifying
> some context in which the conversation is occuring (while remaining
> stateless).

No, you're right, you misinterpreted me (as I did you above).

The context for a transaction would include:
* the transaction rules agreement e.g. the UN/ECE recommendation;
* any long-term contracts between the trading partners;
* the economic resources being traded, e.g. products, services, 
financial instruments, intellectual property, etc.;

Then I think the transaction itself should have a URI, and also each 
of the speech acts (e.g. Offer and Acceptance or Rejection in an 
offer-acceptance transaction). 

If the transaction succeeds (e.g. the offer is accepted), then the 
trading partners have a new contract (e.g. an Order) which should 
also have a URI with links to the transaction that created it.

So from the Order you would have a full set of legal evidence showing 
the transaction that created it, the speech acts involved in the 
transaction, message logs, etc. etc., all hyperlinked to the 
transaction rules.  One could also code up an evaluator that 
determined if the transaction evidence followed the rules or not.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2894
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-11-22 20:29:55
Subject:Re: [rest-discuss] dave winer on REST vs SOAP
Message:

> Seairth Jacobs wrote:
> 
> > Hmm... why is it that people keep comparing REST to SOAP?  This is an
> > apples-to-oranges comparison (possible more like fruit-to-apples). 
> > There is no REST toolkit because REST is not an implementable 
> > specification, just an architectural style.  It seems to me that 
> > Dave's comments do nothing more than show he doesn't understand what 
> > REST is.  I would have given a bit more credit to his opinion if he 
> > had instead asked/answered why SOAP isn't RESTful.
> 
> On the one hand, it is true that Dave doesn't understand what REST is.  
> On the other hand, he has been told what it is several times, and it
> would only take a willingness to read his own inbox to understand why
> the things he said are BS.  

Truly bad arguments, especially when made by otherwise itnerllgient
people, come generally from fear rather than ignorance.

> In fact, I'm sure as he was writing them, he knew what the
> counter-arguments were. But he sees everything in political terms and
> REST was not properly designed to be a political technology. 

Thank heavens for that! Of course, if a major investment of your
intellectual capital has been invested in politics, well ...

> It has an unweildy acronym and it is more about telling people to use
> stuff in the right way rather than selling them something new and
> improved.

Nothing wrong with the acronym! A "rest" is just what I want! A rest from
all the hype, a rest from "solutions" that don't work, etc.

> > REST doesn't make the things you use.  REST makes the things you use 
> > better.
> 
> I like it.
> 
>   Paul Prescod
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 

Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.gooseworks.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2895
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-22 20:59:31
Subject:Re: [rest-discuss] Re: Transactions
Message:

On Fri, Nov 22, 2002 at 08:10:01PM -0000, bhaugen32 wrote:
> So from the Order you would have a full set of legal evidence showing 
> the transaction that created it, the speech acts involved in the 
> transaction, message logs, etc. etc., all hyperlinked to the 
> transaction rules.  One could also code up an evaluator that 
> determined if the transaction evidence followed the rules or not.

Right.  And as I remember us talking about before, it's very important
that all this be done in the context of stateless interaction.  How that
would look, given the complexity of the stuff you listed, could be
quite gnarly.  It's the issue about whether the meaning is encapsulated
in the identifier, or in what the identifier might resolve to at any
given time.  Sometimes, it might be necessary to include some of the
things you mentioned by *value* in a message, rather than just by
reference with a URI.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2896
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-22 21:37:38
Subject:Re: [rest-discuss] Re: fielding talks about waka at apachecon
Message:

bhaugen32 wrote:

> Please try.  This smells suspiciously like the "correlation IDs" from
> mailbox-and-dispatcher-SOAP that we trashed in a previous thread in
> this list.

I don't read Roy's mind, but the term "transaction ID" strikes me as 
different than "correlation ID" in the sense that correlation IDs are 
for identifying conversations whereas I think of converstaions as being 
composed of transactions. So we might have a conversation spanning hours 
but a transaction would typically be only the minimal set of messages 
that must be grouped perhaps for atomicity reasons. Nevertheless, I do 
see some competition between the notions of statelessness and 
cross-message transaction identifiers.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2897
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-22 21:39:28
Subject:Re: [rest-discuss] dave winer on REST vs SOAP
Message:

Oh, Dave is just full of Negative Energy(TM) all the time.

----- Original Message -----
From: "Jeff Bone" <jbone@...>
To: "Seairth Jacobs" <seairth@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Friday, November 22, 2002 10:26 AM
Subject: Re: [rest-discuss] dave winer on REST vs SOAP


>
> Where does Dave come up with some of this stuff?
>
> Ridiculous.
>
> jb
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>






-----------------------------------------------------------------------------------
Post ID:2898
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-11-22 22:33:08
Subject:Re: Transactions
Message:

Mark Baker wrote:
> On Fri, Nov 22, 2002 at 08:10:01PM -0000, bhaugen32 wrote:
> > So from the Order you would have a full set of legal evidence 
showing 
> > the transaction that created it, the speech acts involved in the 
> > transaction, message logs, etc. etc., all hyperlinked to the 
> > transaction rules.  One could also code up an evaluator that 
> > determined if the transaction evidence followed the rules or not.
> 
> Right.  And as I remember us talking about before, it's very 
important
> that all this be done in the context of stateless interaction.  How 
that
> would look, given the complexity of the stuff you listed, could be
> quite gnarly.  It's the issue about whether the meaning is 
encapsulated
> in the identifier, or in what the identifier might resolve to at any
> given time.  Sometimes, it might be necessary to include some of the
> things you mentioned by *value* in a message, rather than just by
> reference with a URI.

It would be possible to include things by value, but you could get 
into conflicts if your included value differed from the reference.

One of the simplifications in some of that discussion was Paul's 
suggestion for the reference to include the hash of the canonical 
representation of the referenced resource.  

But do you have any examples in mind of what you think would need to 
be included by value?







-----------------------------------------------------------------------------------
Post ID:2899
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-11-22 22:41:50
Subject:Re: fielding talks about waka at apachecon
Message:

Paul Prescod wrote:
> bhaugen32 wrote:
> 
> > Please try.  This smells suspiciously like the "correlation IDs" 
from
> > mailbox-and-dispatcher-SOAP that we trashed in a previous thread 
in
> > this list.
> 
> I don't read Roy's mind, but the term "transaction ID" strikes me 
as 
> different than "correlation ID" in the sense that correlation IDs 
are 
> for identifying conversations whereas I think of converstaions as 
being 
> composed of transactions. So we might have a conversation spanning 
hours 
> but a transaction would typically be only the minimal set of 
messages 
> that must be grouped perhaps for atomicity reasons. 

Either which way, in business, conversations as well as transactions 
are about things that could be Web resources with URIs, and likewise 
speech acts in a conversation could have URIs and be referenced from 
future speech acts.

> Nevertheless, I do 
> see some competition between the notions of statelessness and 
> cross-message transaction identifiers.

Both conversations and transactions are inherently stateful.  But I 
think the state of the conversation and transaction can be 
represented by Web resources in very much the ways you have outlined 
in several articles, unless I really misunderstood.

So where do you see the competition coming in?









-----------------------------------------------------------------------------------
Post ID:2900
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-11-23 01:53:17
Subject:OT: yahoogroups delivery issues?
Message:

Has anyone else been receiving message threads in a screwed up order?  For
instance, the four messages in the "Transactions" thread between MarkB and
BobH have come through in the order of "1, 3, 4, 2".  There have been
several other threads where I have come across the reply to a message before
the message itself.

Kinda annoying... just wondering if anyone else is experiencing this.  :~\

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2901
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-11-23 03:05:56
Subject:REST and common sense (was Re: dave winer on REST vs SOAP)
Message:

From: "Mathews, Walden" <walden.mathews@...>
> The value of REST is something akin to that of common sense,
> which is never a big marketing force, no matter how valuable
> it may be in practice.

Hmm.  This does bring up the question of whether REST is common sense or not
(I know that's not what Walden was actually saying).  After all this time, I
still have trouble grasping some parts of REST (and still disagree with
other parts).  From discussions on this list and others, I'm not sure that
anyone short of Fielding "totally gets it" (though I could certainly be
wrong;  apologies to those folks).  For those who are steeped in REST, it
would be common sense.  But to the rest of the world, I feel that REST is
anything but common sense.

On the other hand, the paradigm of SOAP treating the Internet like a big LAN
does fall under the category of "common sense".  Most technical and
non-technical people immediately understand what that means.  Many of those
people can conceptualize it with little effort.  Does it mean that it's the
best way to go?  Not necessarily.  But the masses (those that make of the
"common" sense; Dave Winer included) certainly seem to think so.  Heck, I
even see the simplicity and appeal to that model.

Admittedly, I also see the issues involved as well, which is what got me
interested in REST to begin with.  While I can see how REST can help resolve
some of the issues, it is far from clear to me how it will solve all of the
issues.  I think the reason is that REST just doesn't make sense overall.
And as long as REST is not considered to be common sense, it will have
limited acceptance.  I don't see it becoming common sense any time soon,
esp. when so few actually seem to grasp what it is.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2902
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-11-23 10:04:04
Subject:Re: [rest-discuss] REST and common sense (was Re: dave winer on REST vs SOAP)
Message:

Seairth Jacobs wrote:

> Hmm.  This does bring up the question of whether REST is common sense
> or not (I know that's not what Walden was actually saying).

this is an interesting question.

i often wonder how many programmers/developers/whatever you want to call
them actually understand the Web itself.  i mean, i only really
appreciated its fundamental qualities when i read timbl's _weaving the
web_ a few times 2+ years ago.  i feel there are many people out there
who just view HTTP as a request/response mainframe protocol like CICS or
whatever, but more graphical.  URIs don't really feature in their
thinking at all, apart from as a path in the filesystem on the web server.

then i hear people with titles such as "web application developer" gush
about how flash should replace html (or foo should replace bar), and
wonder "what sort of 'web applications' do *you* develop!?"

when i first read the RESTWiki (following a link from some oreillynet
article a few months ago) i was saying "YES, this makes perfect sense".
 i had been struggling to build coherent web sites consisting of
resources since late 2000 and lots of the theoretical and practical
problems i had just evaporated when i read the RESTWiki and the
dissertation.  the other great thing was that there was a like-minded
community to go with REST and i have found that a big help in my efforts.

i'm rambling on a bit here, but my main point is that 'common sense' may
be a subjective thing.  most people would agree that the Web has been a
fabulous success so far (so the web being viewed as a Good Thing is
'common sense') but this would not have been 'common sense' in 1992.
maybe 'common sense' can be viewed as a function of how much new ground
your breaking when introducing a new concept?  how much are you
challenging people's current way of thinking?  in my view REST is 'just'
boiling lots of distributed application theory down to a very simple
core, but this is a radical step in itself.

it seems to me that many distributed application architectures have
tried to make the network look like one big computer, where you just
call functions on other computers the way you call them on your own.
but i think history has taught us that this doesn't work because it
ignores the strengths and weaknesses that networks bring to the table.

-v








-----------------------------------------------------------------------------------
Post ID:2903
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-11-23 14:28:48
Subject:semantic web as "explicit data semantics" REST architectural constraint
Message:

http://www.markbaker.ca/blog//2002/11/17#2002-11-rdf

because i have become interested in the relationship between REST and
the Semantic Web, i found this intriguing.

"
The Semantic Web is the Web with an additional architectural constraint
that could be called "Explicit Data Semantics"; that data
(representations, in the case of the Web) will be constrained to be
explicit about its implied semantics. This adds the additional desirable
property to the system of partial understanding.
"

this is one of the simpler definitions of the semantic web that i have
seen, and i think this is because it is more or less defined in terms of
REST.  (i.e. it's just one additional architectural constraint to an
otherwise RESTful system.)  of course small changes in architecture can
imply large changes in their underlying implementations but i digress.

i'm trying to ground this theory in the real world.  what would it mean
say if amazon have a resource for a book, or ebay has a resource for an
auction?  just imagine for a second that you have these URIs rather than
the actual ugly implementation-dependent (asp/cgi/jsp/cfm)
querystring-ridden cookie-dependent non-idempotent ones.

http://www.ebay.com/auctions/2h4iug29225/
http://www.amazon.com/items/dh75s8d646/

this implies that amazon/ebay actually have well-defined resources for
these URIs to identify.  in the semantic web:

- would the xml representations of these resources look different, or
- would there be a completely seperate RDF representation, or
- something else?

i am involved in similar work to joe gregorio at
http://wellformedweb.org ; we're just using different tools, and i
haven't published my work yet.  i am interested in how RDF can
complement this type of work and make our RESTful systems
Semantic_Web-ready.

TIA,
-vincent







-----------------------------------------------------------------------------------
Post ID:2904
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-11-24 02:46:12
Subject:Re: [rest-discuss] REST and common sense (was Re: dave winer on REST vs SOAP)
Message:

On Sat, 23 Nov 2002, Vincent D Murphy wrote:

> Seairth Jacobs wrote:
> 
> > Hmm.  This does bring up the question of whether REST is common sense
> > or not (I know that's not what Walden was actually saying).
> 
> this is an interesting question.
> 
> i often wonder how many programmers/developers/whatever you want to call
> them actually understand the Web itself.  i mean, i only really
> appreciated its fundamental qualities when i read timbl's _weaving the
> web_ a few times 2+ years ago.  i feel there are many people out there
> who just view HTTP as a request/response mainframe protocol like CICS or
> whatever, but more graphical.  URIs don't really feature in their
> thinking at all, apart from as a path in the filesystem on the web server.
> 
> then i hear people with titles such as "web application developer" gush
> about how flash should replace html (or foo should replace bar), and
> wonder "what sort of 'web applications' do *you* develop!?"

You might say that a lot of non-RESTful (I wish I could think of a good
acronym for STRESSful ;-) approaches are tring to replace
"commonsense" with "proprietary sense" ;-)

Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.gooseworks.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2905
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-24 04:26:51
Subject:Re: [rest-discuss] semantic web as "explicit data semantics" REST architectural constraint
Message:

On Sat, Nov 23, 2002 at 02:28:48PM +0000, Vincent D Murphy wrote:
> this is one of the simpler definitions of the semantic web that i have
> seen, and i think this is because it is more or less defined in terms of
> REST.  (i.e. it's just one additional architectural constraint to an
> otherwise RESTful system.)

Glad you like it.

>  of course small changes in architecture can
> imply large changes in their underlying implementations but i digress.

It depends what architectural elements the constraint effects.  In
this case, it's a constraint purely on the data elements so is well
isolated.

> i'm trying to ground this theory in the real world.  what would it mean
> say if amazon have a resource for a book, or ebay has a resource for an
> auction?  just imagine for a second that you have these URIs rather than
> the actual ugly implementation-dependent (asp/cgi/jsp/cfm)
> querystring-ridden cookie-dependent non-idempotent ones.
> 
> http://www.ebay.com/auctions/2h4iug29225/
> http://www.amazon.com/items/dh75s8d646/
> 
> this implies that amazon/ebay actually have well-defined resources for
> these URIs to identify.  in the semantic web:
> 
> - would the xml representations of these resources look different, or
> - would there be a completely seperate RDF representation, or
> - something else?

Potentially all of those.  It's your choice.  I'd opt for a combo of
#1 and #2 if I can, i.e. if no XML schema is mandated.

> i am involved in similar work to joe gregorio at
> http://wellformedweb.org ; we're just using different tools, and i
> haven't published my work yet.  i am interested in how RDF can
> complement this type of work and make our RESTful systems
> Semantic_Web-ready.

Just use RDF/XML instead of just XML.  I found this article wonderful,
both as a guide for how to introduce some RDF into your XML, but also
as an intro to RDF (assuming you grok the very basics, i.e. triples);

http://www.xml.com/pub/a/2002/10/30/rdf-friendly.html

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2906
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-11-24 10:46:41
Subject:Re: [rest-discuss] REST and common sense (was Re: dave winer on REST vs SOAP)
Message:

Sam Hunting wrote:

> You might say that a lot of non-RESTful (I wish I could think of a
> good acronym for STRESSful ;-)

RESTless?







-----------------------------------------------------------------------------------
Post ID:2907
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-11-24 11:19:53
Subject:Re: [rest-discuss] semantic web as "explicit data semantics" REST architectural constraint
Message:

Mark Baker wrote:

> It depends what architectural elements the constraint effects.  In
> this case, it's a constraint purely on the data elements so is well
> isolated.

cool.

> >- would the xml representations of these resources look different, or
> >- would there be a completely seperate RDF representation, or
> >- something else?
>
> Potentially all of those.  It's your choice.  I'd opt for a combo of
> #1 and #2 if I can, i.e. if no XML schema is mandated.

i think (after studying the article referenced below again) the XML
representation could have RDF merged in to it, or to put it another way,
be 'annotated' with RDF.  and of course there's nothing to stop you
having a seperate RDF representation as well (presuming RDF has its own
mime type already).  and these do indeed seem to be mutually exclusive,
i.e. you can do one without having to do the other.

the way i see it, one of the nice things about designing a RESTful
system is that you're 'forced' or constrained to consider which things
should be resources, which should be properties of resources, etc.  thus
you end up treating the design of the system as (mostly) a matter of
resource modelling.  i suspect that RDF will fit in here very nicely
because it just models all your resources and properties as a graph.

> Just use RDF/XML instead of just XML.  I found this article wonderful,
> both as a guide for how to introduce some RDF into your XML, but also
> as an intro to RDF (assuming you grok the very basics, i.e. triples);
>
> http://www.xml.com/pub/a/2002/10/30/rdf-friendly.html

thanks for the pointers.  i think i'm ready to start playing with this now.

regards,
-vincent







-----------------------------------------------------------------------------------
Post ID:2908
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-11-25 00:29:06
Subject:round 2: dave winer on REST vs XML-RPC
Message:

http://scriptingnews.userland.com/backissues/2002/11/23#When:3:49:18PM

"
If you want to make it easy for developers to try out your web service,
your absolute best bet is to provide an XML-RPC interface. There's the
least variability in what that means, and the greatest wealth of
toolkits to choose from that factor out most of the gritty details for
you.  By and large REST interfaces don't tell you how to serialize and
deserialize complex structures, so you kind of start from scratch every
time. If they use a SOAP encoding, you get some of that. But there just
is nothing simpler than saying "Here's the XML-RPC interface, and some
sample code in a few of the popular scripting languages."
"

i see holes in just about every sentence of this but i wonder is it just
me; i have nothing good to say about it so i'll shut up.







-----------------------------------------------------------------------------------
Post ID:2909
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-25 11:44:56
Subject:Re: [rest-discuss] round 2: dave winer on REST vs XML-RPC
Message:

Vincent D Murphy wrote:

> http://scriptingnews.userland.com/backissues/2002/11/23#When:3:49:18PM
>
> "
> If you want to make it easy for developers to try out your web service,
> your absolute best bet is to provide an XML-RPC interface. There's the
> least variability in what that means, and the greatest wealth of
> toolkits to choose from that factor out most of the gritty details for
> you.  By and large REST interfaces don't tell you how to serialize and
> deserialize complex structures, so you kind of start from scratch 
> every time. If they use a SOAP encoding, you get some of that. But 
> there just is nothing simpler than saying "Here's the XML-RPC 
> interface, and some sample code in a few of the popular scripting 
> languages."
>
> i see holes in just about every sentence of this but i wonder is it 
> just me; i have nothing good to say about it so i'll shut up.

Let me suggest the following theory about Dave's understanding of XML: 
his only experience with the "X" in XML has been negative. People 
extended "his" RSS without his permission. This prevents him from seeing 
the problem with using a bowlderized XML vocabulary with extremely poor 
support for independent extensibility. Nevertheless, until he 
understands this issue, the "market" for XML-RPC-based solutions will be 
inherently capped. People will deploy a few, say, "yeah, that was fun 
and easy, but not extensible and scalable" and will just leave to try 
something else. It is not a flaw that REST applications preserve all of 
the flexibility of XML and even of MIME!

XML-RPC cannot be used for anything as important as SMTP and HTTP while 
it has such a fixed and limited encoding. I can only presume that this 
is a major reason that so few reusable XML-RPC abstract service types 
have arisen...or perhaps it is the lack of a service description 
language. I'm not sure.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2910
Sender:Philip Eskelin <philip_eskelin@...>
Post Date/Time:2002-11-25 15:19:16
Subject:RE: [rest-discuss] round 2: dave winer on REST vs XML-RPC
Message:

Paul wrote:
> XML-RPC cannot be used for anything as important as
> SMTP and HTTP while it has such a fixed and limited
> encoding. I can only presume that this is a major
> reason that so few reusable XML-RPC abstract service
> types have arisen...or perhaps it is the lack of a
> service description language. I'm not sure.

Since Dave Winer says my advocating REST means I don't
actively develop software, I'm not sure if my opinion
is valid ;-), but in my experience the quality and
consistency of source code and design on the XML-RPC
site is poor....it's as if someone threw a mish-mash
of hyperlinks onto a single page so they could brag
that it was implemented in 19 different languages. 
This, in addition to my dislike for both Dave *and*
his opinion, have led me to the conclusion that he's
just not worth my time.  In fact, Dave and the XML-RPC
site have served as a great example of who *not* to be
and what *not* to do.

-Philip


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus � Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com






-----------------------------------------------------------------------------------
Post ID:2911
Sender:Philip Eskelin <philip_eskelin@...>
Post Date/Time:2002-11-25 16:51:22
Subject:Re: [rest-discuss] round 2: dave winer on REST vs XML-RPC
Message:

Vincent D Murphy wrote:
>
http://scriptingnews.userland.com/backissues/2002/11/23#When:3:49:18PM

> "If you want to make it easy for developers to try
> out your web service, your absolute best bet is to
> provide an XML-RPC interface. There's the least
> variability in what that means, and the greatest
> wealth of toolkits to choose from that factor out
> most of the gritty details for you.  By and large
> REST interfaces don't tell you how to serialize and
> deserialize complex structures, so you kind of start
> from scratch every time. If they use a SOAP
encoding,
> you get some of that. But there just is nothing
> simpler than saying "Here's the XML-RPC interface,
> and some sample code in a few of the popular
> scripting languages."
> 
> i see holes in just about every sentence of this but
> i wonder is it just me; i have nothing good to say
> about it so i'll shut up.

Vincent,

I think the above text you quote from Dave's Scripting
News is a classic example of the "Plain Folks"
technique of propaganda [1] used to persuade us to buy
into XML-RPC (and hopefully buy his company's
software).  I've noticed he uses an approach that
always smacks of, "...why don't you honest,
hard-working folks come down to the bingo hall, press
a simple link and kind of try out some plain old web
services."  I believe it's nothing more a way to cover
up the real issues with an RPC approach, and
specifically the problems with XML-RPC itself.

Politicians often use this technique to challenge the
cultural and economic elite, similar to the way it
seems that Dave is using it to challenge Microsoft and
other giants in the software industry.  

Philip

1. http://www.propagandacritic.com/articles/ct.sa.plain.html

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus � Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com






-----------------------------------------------------------------------------------
Post ID:2912
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-11-26 02:31:24
Subject:Another REST vs. SOAP article
Message:

http://www.eweek.com/article2/0,3959,720306,00.asp

This one is pretty funny, calling REST a "new development approach".
Most of it is typical FUD.


Toivo Lainevool 







-----------------------------------------------------------------------------------
Post ID:2913
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-26 04:20:12
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

I read the article - not bad for the media.
But, boy, DaveW's comments sure are stupid.
I really have to question his understanding of technology.
As CEO of a software company, you'd expect more intelligence with regard to
software and the people who build it.

Mike

----- Original Message -----
From: "Toivo "Deutsch" Lainevool" <tlainevool@...>
To: <rest-discuss@yahoogroups.com>
Sent: Monday, November 25, 2002 6:31 PM
Subject: [rest-discuss] Another REST vs. SOAP article


> http://www.eweek.com/article2/0,3959,720306,00.asp
>
> This one is pretty funny, calling REST a "new development approach".
> Most of it is typical FUD.
>
>
> Toivo Lainevool
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>






-----------------------------------------------------------------------------------
Post ID:2914
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-26 06:58:21
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

S. Mike Dierken wrote:

> I read the article - not bad for the media.
> But, boy, DaveW's comments sure are stupid.
> I really have to question his understanding of technology.
> As CEO of a software company, you'd expect more intelligence with 
> regard to
> software and the people who build it.

A year ago, Dave Winer said REST wasn't important because the only 
people who had heard about it were a few people on FoRK and a couple in 
the O'Reilly clan. Now he's being asked about it on EWeek and not 
laughing it off, but attacking it. I've never so clearly seen the steps of:

http://www.brainyquote.com/quotes/quotes/m/q103630.html

It is too bad that the issues are not reducible to sound bites because 
we're going to have to withstand more media misunderstanding. In fact, 
years from now when developers just use hyperlinks, generic interfaces, 
URIs stateless messaging, and so forth instinctively, the media people 
will ask: "remember back when it seemed like SOAP was going to be really 
big and important and there was some other thing? What was that other 
thing again? I never understood it and now nobody talks about it 
anymore. I guess it died." If there isn't a working group with a spec 
and somebody working oa For Dummies book, it will never have an 
existence these guys can understand.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2915
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-11-26 16:27:38
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

You know, the great thing about all of this is...  it just doesn't 
matter.  It's like that old saying:  the great thing about facts is 
that it doesn't matter if anybody believes them.  It doesn't matter if 
99.9999% of the industry fails to understand REST (today);  it doesn't 
matter if Dave Winer ever gets a clue, or if the press fans this 
"debate" into such a hypestorm that everybody gets sick of it.

REST is hype-proof.  It's idiot-proof.  It's debate-free.  REST is 
about the things that made the Web successful;  loose coupling, naming, 
generic interfaces, etc.  You can't argue with the Web!  If you do, you 
just end up sounding stupid, like our buddy Dave.

You can't treat the Internet like a LAN.  You can't pretend open worlds 
are like closed worlds.  Tight coupling isn't the same as loose 
coupling.  Coordination and composition doesn't work the same way in 
the wild.  That beautiful hothouse flower is gonna get clobbered by the 
kudzu if you plant it out in the yard.

Our industry has made several runs at this wall, and failed to get over 
it every time;  eventually, people will get it --- the key to learning 
is repetition.  Until then, those who didn't learn any any of the past 
{ ONC RPC, DCE, CORBA, DCOM, RMI } attempts will just keep repeating 
history...

The only net effect of this is that eventually, when people finally 
*get* this thing, some of us will be justified in feeling, maybe just a 
little bit, smug. :-)

jb







-----------------------------------------------------------------------------------
Post ID:2916
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-11-26 17:23:34
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

On Tuesday, November 26, 2002, at 11:11  AM, Dave Winer wrote:

> You guys should read this:
>
> http://www.decafbad.com/news_archives/000332.phtml
>
> And get off your butts and make some toolkits and until you do shut up
> because you're not making any sense.

Two bits, Dave:  first, just because something doesn't make sense to 
you does *not* mean that it doesn't make sense.

Second:  the fallacy of this "SOAP / XML-RPC vs. REST" debate is that 
it's apples and oranges;  REST is an architectural style, not a 
particular integration technology.  As such, it's not necessarily the 
case that it needs a toolkit.  Certainly, it would be nice if tools 
mapped better to the model, but make no mistake:  every non-SOAP / 
non-XMLRPC Web App out there is an existance proof (to a greater or 
lesser extent) of REST.  You guys are in the minority today.

jb



>
> Dave
>
>
> ----- Original Message -----
> From: "Jeff Bone" <jbone@...>
> To: "S. Mike Dierken" <mdierken@...>
> Cc: <rest-discuss@yahoogroups.com>; <dave@...>
> Sent: Tuesday, November 26, 2002 8:27 AM
> Subject: Re: [rest-discuss] Another REST vs. SOAP article
>
>
>>
>> You know, the great thing about all of this is...  it just doesn't
>> matter.  It's like that old saying:  the great thing about facts is
>> that it doesn't matter if anybody believes them.  It doesn't matter if
>> 99.9999% of the industry fails to understand REST (today);  it doesn't
>> matter if Dave Winer ever gets a clue, or if the press fans this
>> "debate" into such a hypestorm that everybody gets sick of it.
>>
>> REST is hype-proof.  It's idiot-proof.  It's debate-free.  REST is
>> about the things that made the Web successful;  loose coupling, 
>> naming,
>> generic interfaces, etc.  You can't argue with the Web!  If you do, 
>> you
>> just end up sounding stupid, like our buddy Dave.
>>
>> You can't treat the Internet like a LAN.  You can't pretend open 
>> worlds
>> are like closed worlds.  Tight coupling isn't the same as loose
>> coupling.  Coordination and composition doesn't work the same way in
>> the wild.  That beautiful hothouse flower is gonna get clobbered by 
>> the
>> kudzu if you plant it out in the yard.
>>
>> Our industry has made several runs at this wall, and failed to get 
>> over
>> it every time;  eventually, people will get it --- the key to learning
>> is repetition.  Until then, those who didn't learn any any of the past
>> { ONC RPC, DCE, CORBA, DCOM, RMI } attempts will just keep repeating
>> history...
>>
>> The only net effect of this is that eventually, when people finally
>> *get* this thing, some of us will be justified in feeling, maybe just 
>> a
>> little bit, smug. :-)
>>
>> jb
>>







-----------------------------------------------------------------------------------
Post ID:2917
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-26 18:12:15
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

----- Original Message -----
From: "Dave Winer" <dave@...>
>
> 2. That's news to me. Ever since Mark and Paul started promoting this
thing
> it's always been presented as a reason for not doing XML-RPC and SOAP.
Until
> you manage to convince others to stop spinning it that way (assuming
you're
> not) you gotta live with it.
Well, I think MarkB and PaulP have spent a bunch of time and effort on
educating and steering web service standards toward a pattern of use that
follows the principals that many people feel made the Web successful. For
example, kicking off discussion of using GET in conjunction with WSDL, etc.
So from what I've seen, it's about how to use SOAP /better/, not about a
replacement.

> Sorry, I didn't make it so.
No need to apologize, you didn't do anything wrong.







-----------------------------------------------------------------------------------
Post ID:2918
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-11-26 18:19:46
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

On Tuesday, November 26, 2002, at 12:16  PM, Dave Winer wrote:

> Let's end the whining now.

Okay, please do. ;-)

> I don't really care about REST.

You don't really understand REST, Dave. ;-)  You just said "I don't 
really care about the Web."

jb







-----------------------------------------------------------------------------------
Post ID:2919
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-26 18:33:49
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

----- Original Message -----
From: "Dave Winer" <dave@...>


> Yeah, but the link I sent wasn't about SOAP -- it was about XML-RPC.
Would you like us to take a look at XML-RPC & make suggestions for
improvements?

>
> Let's end the whining now.
Sorry - didn't mean to sound whining.

> I don't really care about REST. Some PC WEEK reporter wanted some
soundbites.
Hmm. If somebody asks again, could you refer them to this discussion group,
or to PaulP or MarkB? We do care & it'll get the reporters off your back in
the future.








-----------------------------------------------------------------------------------
Post ID:2920
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-11-27 01:31:11
Subject:RE: [rest-discuss] Another REST vs. SOAP article
Message:

To compare apples to apples I think we should be comparing REST and SOA
(Service Oriented Architecture).  REST is typified by HTTP/URI and SOA
is typified by UDDI/WSDL/SOAP.  I'm not exactly sure where XML-RPC fits
in to this mix, probably in place of SOAP in the SOA stack.

I think this would be a useful comparison to make.  I've tried to broach
this subject on the rest-discuss list before, but got slammed pretty
hard because of the understandably REST-oriented view of the list.  Can
anyone suggest an appropriate forum for such a discussion?  Is there
some mailing list where people would be willing to discuss the merits
and shortcomings of both REST and SOA?  I don't want to get into a war
about this on the rest-discuss list because things would be pretty
lopsided.  Maybe it would be worthwhile to start some kind of
"Machine-to-Machine Architectures for the Internet" group on Yahoo to
discuss this?  Topics like REST, SOA and Grid Computing could be
discussed, with proponents of each approach and neutral people (like me)
discussing the issues involved.  Or is this just too much of a religious
issue for everyone?

Toivo Lainevool


> -----Original Message-----
> From: Jeff Bone [mailto:jbone@...]
> Sent: Tuesday, November 26, 2002 9:24 AM
> 
> Second:  the fallacy of this "SOAP / XML-RPC vs. REST" debate is that
> it's apples and oranges;  REST is an architectural style, not a
> particular integration technology.  As such, it's not necessarily the
> case that it needs a toolkit.  Certainly, it would be nice if tools
> mapped better to the model, but make no mistake:  every non-SOAP /
> non-XMLRPC Web App out there is an existance proof (to a greater or
> lesser extent) of REST.  You guys are in the minority today.
> 







-----------------------------------------------------------------------------------
Post ID:2921
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-27 01:53:47
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

Jeff Bone wrote:

>
>
> Two bits, Dave:  first, just because something doesn't make sense to
> you does *not* mean that it doesn't make sense.

Jeff, Dave is a lost cause. He's a classic dug-in vested interest. I'm 
struggling to keep this from getting any more personal than Dave has 
already made it. I don't believe that's how technical discussions should 
be conducted.

XML-RPC will probably continue to be a success for small, simple apps 
until the next wave of RPC-reinvented overtakes it: SVG-RPC? RDF-RPC? 
YAML-RPC? In the meantime, I don't think we should begrudge XML-RPC any 
success in those domains. It works for what it works for and does not 
work for what it doesn't work for and the market would figure that out 
without any effort from us.

Over the last year, we've seen REST has substantial momentum and a 
variety of successful applications. Everywhere I go, people come up to 
me and thank me for articulating what, to them, was always common sense.

REST is still the leading way to publish and update complicated datasets 
using XML or HTML. In that vein, I've finally started a long delayed 
project, which is to start listing the public REST apps people tell me 
about when I meet them. I've surely forgotten most of them because I'm 
just cobbling together the list from memory.

http://www.prescod.net/rest/apps

As far as REST toolkits: Roy Fielding (a classic example of someone who 
spends all day talking rather than doing) codified REST and built 
several "toolkits" around it. One is called Apache. Others that I have 
experimented with are Quixote, Zope and Microsoft .NET.

And as long as we're throwing around case studies:

http://effbot.org/zone/rest-vs-rpc.htm

He mentions that there were two "aha" moments that lead him from XML-RPC 
to REST -- before he even knew that the latter has a name:

  1. He learned more about XML and how to work with it.

  2. He needed to work with binary data and realized that URIs and HTTP 
were excellent for that.

It is my strong sense that the more popular XML becomes the less 
frightened people will be of using REST. It won't be possible to scare 
them away by saying: "you might have to parse XML!"

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2922
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-27 02:05:09
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

----- Original Message -----
From: "Toivo "Deutsch" Lainevool" <tlainevool@...>


> To compare apples to apples I think we should be comparing REST and SOA
> (Service Oriented Architecture).  REST is typified by HTTP/URI and SOA
> is typified by UDDI/WSDL/SOAP.  I'm not exactly sure where XML-RPC fits
> in to this mix, probably in place of SOAP in the SOA stack.
>
> I think this would be a useful comparison to make.  I've tried to broach
> this subject on the rest-discuss list before, but got slammed pretty
> hard because of the understandably REST-oriented view of the list.
I'm sorry you got slammed - that really isn't appropriate for a discussion
group like rest-discuss.
Are you willing to try again? I'll review the old posts & see what the
attitude was like - but for me, I would appreciate comparisons between REST
and other architectural styles.






-----------------------------------------------------------------------------------
Post ID:2923
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-11-27 02:55:27
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

On Tuesday, November 26, 2002, at 07:53  PM, Paul Prescod wrote:

> Jeff Bone wrote:
>
>> Two bits, Dave:  first, just because something doesn't make sense to
>> you does *not* mean that it doesn't make sense.
>
> Jeff, Dave is a lost cause. He's a classic dug-in vested interest. I'm 
> struggling to keep this from getting any more personal than Dave has 
> already made it. I don't believe that's how technical discussions 
> should be conducted.

Personal is often Dave's style.

I've faced the wrath of Dave before, Paul.  Apparently, around '97 or 
so, I was "interfering" with the fate of Apple Computer --- and Dave 
gave me what-for about it. And frankly, he was at least partially 
right:  Apple wasn't dead despite how much I or anybody else thought 
otherwise.

I keep hoping to bring him around on this one, because IME he's 
brilliant...  just under- or mis-informed.  (And like, ahem, "certain 
other people" ;-) he can be quite vocal about it, and doesn't like 
being told he's under- or mis-informed. ;-)  And I figure if a hard 
case like me deserved enough attention and education from e.g. Mark and 
Roy back when to bring me around, then Dave deserves at least as much.

I just wish Dave would take some of his own medicine.  Every time this 
comes up, he seems to forget that he's asked me the same question, and 
got the same answer:  yes, I've not only looked at XML-RPC, I've used 
it, on more than one occasion and with more than one language binding.  
I just wish he'd apply the same diligence to trying to understand the 
point of REST that the rest of us have, and that he would himself do 
re: REST the same thing that he encourages in others -wrt- 
understanding XML-RPC, etc.

jb







-----------------------------------------------------------------------------------
Post ID:2924
Sender:Yannick Loiseau <yloiseau@...>
Post Date/Time:2002-11-27 10:29:55
Subject:Rest compliant protocols
Message:


I've asked few weeks ago about using Jabber as a protocol for a rest-
architectural system. I haven't well understood the answer, which was a link 
to the wikki FAQ. Here are my thoughts about jabber (mainly from "Programming 
Jabber" Ed. O'Reilly) and /reasons/ why it cool be suitable for rest.
	- Jabber is resources oriented: you can specify a resources for any 
kind of "things" in the jabber world. For "human users", it could be the 
client on desktop at work, the client on laptop, the bot logging conference 
rooms, and so on. For a server agent, it could be any thing you want, e.g. a 
channel feeding rss, a room for conference transport, etc.
	- Jabber is full XML, in the protocol, the communications and the 
data. Even the storage is XML (it could be also a DB or an other kind of 
persistence system). Moreover, it rely on name spaces. Therefore it is fully 
extensible.
	- Resource management is based on few methods, such as "get" and "set"
	- All resources are "browsable", that is you can "query" a resource to 
know some kind of metadata about it. For a service for example, it return the 
fields to fill to subscribe. It could be parameters required to submit a 
query, or whatever. In many clients, forms are dynamically built according to 
this feature.
	- The connection can be server initiated (i.e. push) which can't be 
done with http. This can be useful in many context, specially in asynchronous 
systems.
	- Use management and subscription (and authentication) is built-in. 
Authentication is included in HTTP, but the subscription stage left to the 
implementation.
	- As in http, communication can be secured with ssl
Reading jabber stuff, I thought about other suitable things, but i can't 
remember them right now.
It seems to me that all HTTP feature can be managed with jabber, but with 
other built-in cool added possibilities.

Another approach... Does anyone here has implemented (or tested, or at least 
thought about) a rest architecture above Gnutella? I've recently learned that 
Gnutella is actually extended Http. It could solve the "push" problem, and 
other aspect that I wanted delegate to Jabber :)
I know that HTTP is one of the foundations of Rest, but take the time to think 
about these ideas. I hope I'm not too presumptuous, and I certainly miss 
something. So please explain...  :)
Thanks in advance

-------------------------------
  Yannick Loiseau
 mailto:yloiseau@...
-------------------------------






-----------------------------------------------------------------------------------
Post ID:2925
Sender:Piers Harding <piers@...>
Post Date/Time:2002-11-27 14:37:48
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

Hi Yannick - I'd certainly like to get the lists opinion on this too.  I
have ( as have others in the Jabber community ) wondered about Jabbers'
place in the REST world.  

Jabber appears to have some of the key components for REST with URIs and
 a few of the RESTian verbs.

Is it actually necessary for a toolset to implement all features of
REST, or would the REST community be willing to endorse toolsets to a
level of REST support?

all food for thought IMHO.

Cheers.


On Wed, Nov 27, 2002 at 11:29:55AM +0100, Yannick Loiseau wrote:
> 
> 
> I've asked few weeks ago about using Jabber as a protocol for a rest-
> architectural system. I haven't well understood the answer, which was a link 
> to the wikki FAQ. Here are my thoughts about jabber (mainly from "Programming 
> Jabber" Ed. O'Reilly) and /reasons/ why it cool be suitable for rest.
> 	- Jabber is resources oriented: you can specify a resources for any 
> kind of "things" in the jabber world. For "human users", it could be the 
> client on desktop at work, the client on laptop, the bot logging conference 
> rooms, and so on. For a server agent, it could be any thing you want, e.g. a 
> channel feeding rss, a room for conference transport, etc.
> 	- Jabber is full XML, in the protocol, the communications and the 
> data. Even the storage is XML (it could be also a DB or an other kind of 
> persistence system). Moreover, it rely on name spaces. Therefore it is fully 
> extensible.
> 	- Resource management is based on few methods, such as "get" and "set"
> 	- All resources are "browsable", that is you can "query" a resource to 
> know some kind of metadata about it. For a service for example, it return the 
> fields to fill to subscribe. It could be parameters required to submit a 
> query, or whatever. In many clients, forms are dynamically built according to 
> this feature.
> 	- The connection can be server initiated (i.e. push) which can't be 
> done with http. This can be useful in many context, specially in asynchronous 
> systems.
> 	- Use management and subscription (and authentication) is built-in. 
> Authentication is included in HTTP, but the subscription stage left to the 
> implementation.
> 	- As in http, communication can be secured with ssl
> Reading jabber stuff, I thought about other suitable things, but i can't 
> remember them right now.
> It seems to me that all HTTP feature can be managed with jabber, but with 
> other built-in cool added possibilities.
> 
> Another approach... Does anyone here has implemented (or tested, or at least 
> thought about) a rest architecture above Gnutella? I've recently learned that 
> Gnutella is actually extended Http. It could solve the "push" problem, and 
> other aspect that I wanted delegate to Jabber :)
> I know that HTTP is one of the foundations of Rest, but take the time to think 
> about these ideas. I hope I'm not too presumptuous, and I certainly miss 
> something. So please explain...  :)
> Thanks in advance
> 
> -------------------------------
>   Yannick Loiseau
>  mailto:yloiseau@...
> -------------------------------
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 







-----------------------------------------------------------------------------------
Post ID:2926
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-27 17:04:26
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

----- Original Message -----
From: "Yannick Loiseau" <yloiseau@...>


>
>
> I've asked few weeks ago about using Jabber as a protocol for a rest-
> architectural system. I haven't well understood the answer, which was a
link
> to the wikki FAQ.
I'd like to see some more discussion comparing features of Jabber with
aspects of REST also.

> Here are my thoughts about jabber (mainly from "Programming
> Jabber" Ed. O'Reilly) and /reasons/ why it cool be suitable for rest.

> - Jabber is resources oriented: you can specify a resources for any
> kind of "things" in the jabber world. For "human users", it could be the
> client on desktop at work, the client on laptop, the bot logging
conference
> rooms, and so on. For a server agent, it could be any thing you want, e.g.
a
> channel feeding rss, a room for conference transport, etc.
Can you access all of those 'things' with common operations?
Is it possible to write a Jabber Spider that cruises all the information and
learns something about each?

> - Jabber is full XML, in the protocol, the communications and the
> data. Even the storage is XML (it could be also a DB or an other kind of
> persistence system).
If Jabber is a protocol, what does it need to define storage for? Maybe
certain apps on top of Jabber use XML storage?

> Moreover, it rely on name spaces. Therefore it is fully extensible.
Not necessarily. Namespaces provide one kind of capability, but there are a
lot of really smart people that think namespaces don't do anything to solve
other integration and extensibility problems. (Don't have links handy right
now...)

> - Resource management is based on few methods, such as "get" and "set"

> - All resources are "browsable", that is you can "query" a resource to
> know some kind of metadata about it. For a service for example, it return
the
> fields to fill to subscribe. It could be parameters required to submit a
> query, or whatever. In many clients, forms are dynamically built according
to
> this feature.

> - The connection can be server initiated (i.e. push) which can't be
> done with http. This can be useful in many context, specially in
asynchronous
> systems.
How does a server initiate a connection to a node that is behind a firewall?
Whatever is used can also be used to initiate a connection that then
transitions to plain HTTP with the firewalled node becoming the logical
'server'.


> - Use management and subscription (and authentication) is built-in.
What kind of user management is built-in? I'll look for this...

> Authentication is included in HTTP, but the subscription stage left to the
> implementation.

> - As in http, communication can be secured with ssl

> Reading jabber stuff, I thought about other suitable things, but i can't
> remember them right now.
> It seems to me that all HTTP feature can be managed with jabber, but with
> other built-in cool added possibilities.
>

> Another approach... Does anyone here has implemented (or tested, or at
least
> thought about) a rest architecture above Gnutella?
Not that I know of, but it sure sounds interesting.

> I've recently learned that Gnutella is actually extended Http.
Interesting. I wonder how much is extended according to 'extension'
specifications - and how much of the 'extensions' were actually necessary
(often people don't think HTTP can do some things and so assume they need to
invent a new way of doing it.)

> It could solve the "push" problem, and other aspect that I wanted delegate
to Jabber :)
It won't solve the push problem. The 'push' problem can be solved with any
TCP/IP protocol by having the server initiate a persistent connection to a
routing/dispatching proxy. That is basically how many systems do it. Nobody
has yet shipped a reference implementation that is as 'pure http' as
possible yet. But that might change soon.

> I know that HTTP is one of the foundations of Rest, but take the time to
think
> about these ideas. I hope I'm not too presumptuous, and I certainly miss
> something. So please explain...  :)
Keep up the good questions.






-----------------------------------------------------------------------------------
Post ID:2927
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-27 17:07:08
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

On Wed, Nov 27, 2002 at 02:37:48PM +0000, Piers Harding wrote:
> Hi Yannick - I'd certainly like to get the lists opinion on this too.  I
> have ( as have others in the Jabber community ) wondered about Jabbers'
> place in the REST world.  
> 
> Jabber appears to have some of the key components for REST with URIs and
>  a few of the RESTian verbs.

I haven't looked at the Jabber protocol in any detail in quite some
time, but REST is an architectural style that is extremely constraining.
A system doesn't "conform" to REST's constraints by accident, it has to
be intentionally designed to do so.

Jabber, like pretty much every other system out there, can be engulfed
by the Web, in the same way that FTP and email/SMTP were absorbed; by
constraining interactions with that system to uniform interface
semantics, and mapping the space of identifiable things in that system
into URI space (often requiring a new URI scheme).

> Is it actually necessary for a toolset to implement all features of
> REST, or would the REST community be willing to endorse toolsets to a
> level of REST support?

I'm not sure what that means ("level of REST support").  Do you have an
example?

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2928
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-27 17:36:43
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

----- Original Message -----
From: "Piers Harding" <piers@...>

> Is it actually necessary for a toolset to implement all features of
> REST, or would the REST community be willing to endorse toolsets to a
> level of REST support?
I think the current REST community is an education-oriented group & the
members aren't really 'endorsing' things. There are a lot of people that are
more than willing to look at designs, tools, and technology & make
suggestions for improvements based on aspects of REST, and often based on
HTTP implementation details.

So it's more of a "We're here to help." rather than "You're not a member of
the club" type of thing.
Endorsement comes from the community using the tools and from the tools
following community developed specifications (like HTTP, SMTP, DNS, etc).






-----------------------------------------------------------------------------------
Post ID:2929
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-27 17:48:25
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

Toivo "Deutsch" Lainevool wrote:

> To compare apples to apples I think we should be comparing REST and 
> SOA (Service Oriented Architecture).  REST is typified by HTTP/URI and 
> SOA is typified by UDDI/WSDL/SOAP.  I'm not exactly sure where XML-RPC 
> fits in to this mix, probably in place of SOAP in the SOA stack.

Except that XML-RPC is hardly ever used with UDDI or WSDL.

> I think this would be a useful comparison to make.  I've tried to 
> broach this subject on the rest-discuss list before, but got slammed 
> pretty hard because of the understandably REST-oriented view of the 
> list.  Cananyone suggest an appropriate forum for such a discussion? 
> Is there some mailing list where people would be willing to discuss 
> the merits and shortcomings of both REST and SOA?  

You could try "distributed objects".

> I don't want to get into a war
> about this on the rest-discuss list because things would be pretty
> lopsided.  Maybe it would be worthwhile to start some kind of
> "Machine-to-Machine Architectures for the Internet" group on Yahoo to
> discuss this?  Topics like REST, SOA and Grid Computing could be
> discussed, with proponents of each approach and neutral people (like 
> me) discussing the issues involved.  Or is this just too much of a 
> religious issue for everyone?

I would not be surprised if it continually degraded into flame wars but 
you could give it a try.

I'll start the flaming by saying that I have never understood, from even 
before I had heard of REST, why it makes sense to distinguish some 
resources as "services" and treat them differently than other resources. 
  Most of the justifications here:

  http://www.developer.com/db/article.php/1010451

seem illogical to me.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2930
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-27 17:57:16
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

----- Original Message -----
From: "S. Mike Dierken" <mdierken@...>

>
> > Another approach... Does anyone here has implemented (or tested, or at
> least
> > thought about) a rest architecture above Gnutella?
> Not that I know of, but it sure sounds interesting.
>
> > I've recently learned that Gnutella is actually extended Http.
> Interesting. I wonder how much is extended according to 'extension'
> specifications - and how much of the 'extensions' were actually necessary
> (often people don't think HTTP can do some things and so assume they need
to
> invent a new way of doing it.)
It looks like the 'query' aspect is the non-HTTP part, file retrieval is
pure HTTP GET.
The information space will be (poorly) organized based on each region's
interpretation of a query.
Some machines will treat ".mp3" differently than others. A single query will
return qualitatively different results.
This is also true of pure HTTP, but the addition of <FORM> helped create
richer queries (names and values).
For example, if today's Gnutella queries look like ".mp3", changing this to
"name=*.mp3" may help servers return more relevant results.

>
> > It could solve the "push" problem, and other aspect that I wanted
delegate
> to Jabber :)
> It won't solve the push problem. The 'push' problem can be solved with any
> TCP/IP protocol by having the server initiate a persistent connection to a
> routing/dispatching proxy. That is basically how many systems do it.
Nobody
> has yet shipped a reference implementation that is as 'pure http' as
> possible yet. But that might change soon.
This is interesting - a Gnutella node behind a firewall can't respond to
GET, but it can respond to a request to 'push the content' to you.
If a node can respond to /anything/ at all, then you can do a GET via a
proxy, but HTTP has problems with this since it is connection oriented.
More thought needed.


Regarding Gnutella - here is an excellent introduction:
http://www.rixsoft.com/Knowbuddy/gnutellafaq.html#overview

Relevant paragraphs:
===
Searching
Searching works similarly to connecting: you send out a search request, it
is propagated through the network, and each servent that has matching terms
passes back its result set. Each servent handles the search query in its own
way. The simple query ".mp3" could be handled in different ways by different
servents: one servent might take it literally, matching anything with ".mp3"
in it, while another might interpret it as a regular expression and match
any character followed by "mp3". To save on bandwidth, a servent does not
have to respond to a query if it has no matching items. The servent also has
the option of returning only a limited result set, so that it doesn't have
to return 5000 matches when someone searches for "mp3".

Since all of the searches are to the local servent's database, the servent
sees what everyone else is searching for. Using this, most clients have a
Search Monitor that allows the user to see, in real time, the searches that
their servent is responding to.

Downloading
For file sharing, each servent acts as a miniature HTTP web server. Since
the HTTP protocol is well established, existing code libraries can be used.
When you find a search result that you want to download, you just connect to
the servent in the same way your web browser would connect to a web server,
and you are good to go. Of course, the servent has this built-in, so your
normal web browser never has to enter the picture.

Servents are also smart enough to compensate for firewalls. If you are
behind a firewall that can only connect to the outside world on certain
ports (80, for instance) you will just need to find a servent running on
port 80. Since the servents can serve on any port, you are likely going to
find one that is serving on a firewall-friendly port. Also, if you are
trying to download a file from a servent that is behind a firewall, you can
ask the firewalled servent to push the file to you since you will not be
able to connect to it directly. The only thing the protocol cannot
compensate for is file transfers between two servents behind two different
firewalls. In such a case, there really isn't anything that can be done.
===








-----------------------------------------------------------------------------------
Post ID:2931
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-11-27 20:10:00
Subject:RE: [rest-discuss] Another REST vs. SOAP article
Message:

> I'll start the flaming by saying that I have never understood, from
even
> before I had heard of REST, why it makes sense to distinguish some
> resources as "services" and treat them differently than other
resources.
>   Most of the justifications here:
> 
>   http://www.developer.com/db/article.php/1010451
> 
> seem illogical to me.
> 
>   Paul Prescod

I don't think the article made a good case for the difference between a
service and a resource either, so I'll take a stab at it.

One of the major differences between SOA and REST is that SOA systems
are Distributed System and REST systems are Network-Based System. (See
http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_
2_1_1 for the distinction). 

So a "service" is something that SOA toolkits hide behind a local proxy,
trying to shield as much as possible the fact that a message is going
out over the network.  This is why an SOA based system needs to include
a interface definition language like WSDL.  This allows services to be
defined in a way that, for example, allows a Java based SOAP middleware
product to present the service to the end user as a Java interface. 

This isn't necessarily the case when using REST.  Of course you can
always wrap something around a RESTful network message to make it
transparent to the end user, but this isn't something that the
architecture itself tries to impose.    The interface to a resource is
baked into the system itself (e.g. HTTP's Get, Put, Post, Delete).

To summarize, one of the big differences is that a resource has an
interface that is defined by the architecture itself, while a service
has a user definable interface.

Toivo Lainevool








-----------------------------------------------------------------------------------
Post ID:2932
Sender:Piers Harding <piers@...>
Post Date/Time:2002-11-27 20:31:23
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

Well, as Yannick has allready stated - the Jabber protocol supports some
verbs with the IQ element ( a conversation fragment ) and there are
fragment types of get, set, result, and error.  The 'to' attribute 
specifies a URI that can be directed to a specific presence ( or 
unspecific ) of a client ( typically an IM user, but certainly doesnt
 have to be ), or a component with or without a resource specification ( a
 component can be local or remote - it doesn't matter ) eg.
    somebody@.../work-desk-5 ( client ) or 
    some.host/browse-component/whateverIcaretoputhere.
Within the IQ (info-query) element the payload definition, and behaviour
can be specified - by behaviour I mean type of query being undertaken,
eg. jabber:iq:browse states that the payload is a browse request to a
given jid ( to address ) to discover information about/from that
end-point.

The point of this all being, that there are some obvious parts to this
protocol that could lend itself to facilitating some passable (portion)
of a REST implementation ( or so it seems to me ).

It would help if people in general debated the merits of this ( at least
for me ), to help clear up whether or not there is some merit in using
some or all of what Jabber has to offer in a REST based architecture.

Cheers.

On Wed, Nov 27, 2002 at 12:07:08PM -0500, Mark Baker wrote:
> On Wed, Nov 27, 2002 at 02:37:48PM +0000, Piers Harding wrote:
> > Hi Yannick - I'd certainly like to get the lists opinion on this too.  I
> > have ( as have others in the Jabber community ) wondered about Jabbers'
> > place in the REST world.  
> > 
> > Jabber appears to have some of the key components for REST with URIs and
> >  a few of the RESTian verbs.
> 
> I haven't looked at the Jabber protocol in any detail in quite some
> time, but REST is an architectural style that is extremely constraining.
> A system doesn't "conform" to REST's constraints by accident, it has to
> be intentionally designed to do so.
> 
> Jabber, like pretty much every other system out there, can be engulfed
> by the Web, in the same way that FTP and email/SMTP were absorbed; by
> constraining interactions with that system to uniform interface
> semantics, and mapping the space of identifiable things in that system
> into URI space (often requiring a new URI scheme).
> 
> > Is it actually necessary for a toolset to implement all features of
> > REST, or would the REST community be willing to endorse toolsets to a
> > level of REST support?
> 
> I'm not sure what that means ("level of REST support").  Do you have an
> example?
> 
> MB
> -- 
> Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca
> 
>    Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2933
Sender:Piers Harding <piers@...>
Post Date/Time:2002-11-27 20:36:43
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

Sorry - that certainly wasn't my meaning - by endorsing I guess it was
more along the lines of "actively thinking/investigating/colaborating
with the Jabber community, to determine what each has to offer the
other, if the technology is found to be appropriate" - endorse just
 seemed a lot shorter ;-) .  One of my favourite catch phrases is that
Jabber isn't just IM - it has a whole lot more to offer a lot of varied
groups/requirements - I believe that this is one of those areas (REST)
that should be looked at to see if there is some kind of "fit".

Cheers.


On Wed, Nov 27, 2002 at 09:36:43AM -0800, S. Mike Dierken wrote:
> 
> ----- Original Message -----
> From: "Piers Harding" <piers@...>
> 
> > Is it actually necessary for a toolset to implement all features of
> > REST, or would the REST community be willing to endorse toolsets to a
> > level of REST support?
> I think the current REST community is an education-oriented group & the
> members aren't really 'endorsing' things. There are a lot of people that are
> more than willing to look at designs, tools, and technology & make
> suggestions for improvements based on aspects of REST, and often based on
> HTTP implementation details.
> 
> So it's more of a "We're here to help." rather than "You're not a member of
> the club" type of thing.
> Endorsement comes from the community using the tools and from the tools
> following community developed specifications (like HTTP, SMTP, DNS, etc).
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 






-----------------------------------------------------------------------------------
Post ID:2934
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-27 22:22:09
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

Piers Harding wrote:

> Hi Yannick - I'd certainly like to get the lists opinion on this too. 
>  I have ( as have others in the Jabber community ) wondered about 
> Jabbers' place in the REST world.  

I'm sure you've heard that the hard-line REST point of view is that IM 
functionality should be rolled into HTTP (or HTTP-NG or Waka) or built 
on top of HTTP (or ...). That sounds very intolerant even to me but 
there are important principles that we're trying to encourage. A major 
one is that there should be a single address space for objects so that 
any component can talk to any other component in a unified way. By the 
way, this means that I would only support Waka if I were convinced that 
it could completely replace HTTP or work beside it so seamlessly that it 
didn't fragment the network.

I'm probably not going to convince you that most existing protocols can 
and should be collapsed into one address space and protocol and you 
aren't going to convince me that the price is acceptable for the 
advantages that the Jabber protocol (as opposed to the Jabber 
architecture and implementation).

But there are certainly productives avenue of cooperation. Jabber is 
designed to go through firewalls bidirectionally and asynchronously. I 
could imagine a gateway that would allow me to access an asynch P2P 
REST-based service running on  my laptop by contacting me through a 
HTTP->Jabber->HTTP proxy.

Until we've got the pieces in place to do easy bidirectional, 
cross-firewall asynch in a designed-for-REST protocol, I'm certainly not 
going to say anything against Jabber. If people are building and 
installing bidirectional asynch services I think that's a good thing.

Probably HTTP could help Jabber in similar ways. Obviously there are 
already some HTTP->Jabber bridges if only for tunnelling out through 
firewalls, but I'm not sure how sophisticated they are. Does anyone run 
a service that allows Jabber URIs to embed HTTP URIs so that a "get" on 
the URI?

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2935
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-27 23:48:17
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>


> Piers Harding wrote:
>
> > Hi Yannick - I'd certainly like to get the lists opinion on this too.
> >  I have ( as have others in the Jabber community ) wondered about
> > Jabbers' place in the REST world.
>
> I'm sure you've heard that the hard-line REST point of view is that IM
> functionality should be rolled into HTTP (or HTTP-NG or Waka) or built
> on top of HTTP (or ...).
The discussions on this forum have shown that it is doable and existing
approaches by IM clients to work through firewalls can be applied to work
with HTTP as well - I think we ended up with using the 'Upgrade' header or
something.

The KnowNow technology does something a lot like this, but not as clean as I
can imagine. I even once wrote an AIM clone with just HTML and JavaScript
(buddy lists, messages, chat, invites, etc.) The neat thing about it was
that it was HTML & javascript - /anybody/ could modify & extend it, not just
the propeller heads.
KnowNow recently put some technology out as open source on sourceforge
(mod_pubsub) & I'm thinking about re-writing the KnowBuddy app (unless I can
get KN to opensource that too)








-----------------------------------------------------------------------------------
Post ID:2936
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-28 00:19:08
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

Toivo "Deutsch" Lainevool wrote:

> To summarize, one of the big differences is that a resource has an
> interface that is defined by the architecture itself, while a service
> has a user definable interface.

I agree that this is a difference between REST and a traditional 
distributed objects system but I think that a service oriented 
architecture tends to be special in that many objects are encapsulated 
into a single service. And you do discovery on the service, not the objects.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2937
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-28 03:49:15
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

On Wed, Nov 27, 2002 at 04:19:08PM -0800, Paul Prescod wrote:
> I agree that this is a difference between REST and a traditional 
> distributed objects system but I think that a service oriented 
> architecture tends to be special in that many objects are encapsulated 
> into a single service. And you do discovery on the service, not the objects.

Yep, I think that's the key difference.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2938
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-11-28 03:59:05
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

On Wed, Nov 27, 2002 at 08:31:23PM +0000, Piers Harding wrote:
> The point of this all being, that there are some obvious parts to this
> protocol that could lend itself to facilitating some passable (portion)
> of a REST implementation ( or so it seems to me ).
> 
> It would help if people in general debated the merits of this ( at least
> for me ), to help clear up whether or not there is some merit in using
> some or all of what Jabber has to offer in a REST based architecture.

Oh ok, I wasn't aware that you were looking at it that way.  My personal
opinion is, no, I'm not aware of any part of Jabber that has anything to
offer REST.  That's not a shot at Jabber, just an observation; I think
Jabber is quite cool, and we use it at work, and even integrated it into
Idokorro's HTTP routing platform and product suite.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2939
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-11-28 07:06:06
Subject:RE: [rest-discuss] Another REST vs. SOAP article
Message:

> -----Original Message-----
> From: Mark Baker, Wednesday, November 27, 2002 7:49 PM
> 
> On Wed, Nov 27, 2002 at 04:19:08PM -0800, Paul Prescod wrote:
> > I agree that this is a difference between REST and a traditional
> > distributed objects system but I think that a service oriented
> > architecture tends to be special in that many objects are
encapsulated
> > into a single service. And you do discovery on the service, not the
> objects.
> 
> Yep, I think that's the key difference.
> 

Hmmmm....

I'm not really sure I see what you mean by this. In regular usage of a
Java SOA toolkit you would take one object and create a WSDL doc from
it.  The WSDL doc is a single service.  I would say that means one
service represents one object.

Toivo Lainevool










-----------------------------------------------------------------------------------
Post ID:2940
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-28 08:08:56
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

----- Original Message -----
From: "Toivo "Deutsch" Lainevool" <tlainevool@...>


> I'm not really sure I see what you mean by this. In regular usage of a
> Java SOA toolkit you would take one object and create a WSDL doc from
> it.  The WSDL doc is a single service.  I would say that means one
> service represents one object.

Perhaps we should clarify whether we are talking 'object', 'class' or what.
When you use the term 'object' when talking about Java, I think of it as an
instance.
So "...many objects are encapsulated into a single service. And you do
discovery on the service, not the objects." probably uses the term 'object'
to mean 'instance'.
I hope this clarifies things.

As a note, this discussion is interesting because I see REST as being an
'instance' heavy approach, whereas many OO languages have 'class' and
'instance' as primary concepts.







-----------------------------------------------------------------------------------
Post ID:2941
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-11-28 09:50:11
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

Paul Prescod wrote:

> Until we've got the pieces in place to do easy bidirectional,
> cross-firewall asynch in a designed-for-REST protocol, I'm certainly
> not going to say anything against Jabber.

i think one of the pieces might be a BEEP-based protocol, with a profile
for GET, POST, PUT, DELETE, etc.  i said this before on rest-discuss but
the idea has stewed in my mind a little since so i'll offer it once
again in its regurgitated form.

one of the objections to BEEP is that it multiplexes TCP, which itself
multiplexes IP.  two of the attractions are that it has a TUNNEL profile
which allows it to cross firewall boundaries in a controlled manner, and
its very extensible; need a new method, e.g. an enchanced GET for
advanced queries (like GetData in TAPache)?  just define a new profile.
 of course it shouldn't be *too* easy to define a new method, as we know
so well.  :)

however, even if a BEEP-based REST application protocol were ready to be
deployed, the erosion of end-to-end connectivity on the contemporary
Internet (thru NAT etc.) would thwart efforts to do completely
asynchronous messages.  that said, BEEP enables the server to become the
client and vice versa very very easily so asynch would probably be
doable during the same session.

i don't know whether you could bootstrap a BEEP-based protocol off the
HTTP Upgrade header.  i also don't know whether it adheres to KISS, and
whether its part of the protocol stack can be implemented by Mere Mortals.

http://www.beepcore.org/







-----------------------------------------------------------------------------------
Post ID:2942
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-28 13:52:04
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

Toivo "Deutsch" Lainevool wrote:

> Hmmmm....
>
> I'm not really sure I see what you mean by this. In regular usage of a
> Java SOA toolkit you would take one object and create a WSDL doc from
> it. 

You take an object with static method and expose the static methods. 
You can't take a family of objects with instance methods and expose the 
instances.

>  The WSDL doc is a single service.  I would say that means one
> service represents one object.

Now go the other way. I have a hundred instances being created an 
destroyed at runtime. Whta does the WSDL for that look like?

  http://www.blogstream.com/pauls/1032521623/index_html

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2943
Sender:Piers Harding <piers@...>
Post Date/Time:2002-11-28 14:27:51
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

Hmmm.  Not exactly the response I was hoping for, but not a complete
wash out :-)

Possibly the greatest virtue of the Jabber protocol is that it
implements the truest form of "push technology" (that I know of) to
date.  One aspect of this is (and arguably its most powerful use) is
presence management - just simply being able to subscribe to a service,
and know when it is available (without polling) is a very valuable thing
(for example - I could subscribe to several similar services, but know
which ones are available right now, when I want to choosing one to use).

The Jabber community is allready looking at the use of http for file
related transfer "out of band", where by a URL is transmitted and the
client chooses when and how to access the data.  This lends itself very
nicely to event notification for things like business workflow.
Also, the resource part of a jid can be anything, so it is a prime
target for embedding http style uri's if you so desired.

So where does this leave us?  Not much further along, but perhaps I can
convince one or two people to have a closer look at Jabber, and I think
we could concentrate on how to do the bridging between XMPP (the JSF
name of the Jabber Protocol), and the HTTP requirements of REST?

Cheers.



On Wed, Nov 27, 2002 at 02:22:09PM -0800, Paul Prescod wrote:
> Piers Harding wrote:
> 
> > Hi Yannick - I'd certainly like to get the lists opinion on this too. 
> >  I have ( as have others in the Jabber community ) wondered about 
> > Jabbers' place in the REST world.  
> 
> I'm sure you've heard that the hard-line REST point of view is that IM 
> functionality should be rolled into HTTP (or HTTP-NG or Waka) or built 
> on top of HTTP (or ...). That sounds very intolerant even to me but 
> there are important principles that we're trying to encourage. A major 
> one is that there should be a single address space for objects so that 
> any component can talk to any other component in a unified way. By the 
> way, this means that I would only support Waka if I were convinced that 
> it could completely replace HTTP or work beside it so seamlessly that it 
> didn't fragment the network.
> 
> I'm probably not going to convince you that most existing protocols can 
> and should be collapsed into one address space and protocol and you 
> aren't going to convince me that the price is acceptable for the 
> advantages that the Jabber protocol (as opposed to the Jabber 
> architecture and implementation).
> 
> But there are certainly productives avenue of cooperation. Jabber is 
> designed to go through firewalls bidirectionally and asynchronously. I 
> could imagine a gateway that would allow me to access an asynch P2P 
> REST-based service running on  my laptop by contacting me through a 
> HTTP->Jabber->HTTP proxy.
> 
> Until we've got the pieces in place to do easy bidirectional, 
> cross-firewall asynch in a designed-for-REST protocol, I'm certainly not 
> going to say anything against Jabber. If people are building and 
> installing bidirectional asynch services I think that's a good thing.
> 
> Probably HTTP could help Jabber in similar ways. Obviously there are 
> already some HTTP->Jabber bridges if only for tunnelling out through 
> firewalls, but I'm not sure how sophisticated they are. Does anyone run 
> a service that allows Jabber URIs to embed HTTP URIs so that a "get" on 
> the URI?
> 
>   Paul Prescod






-----------------------------------------------------------------------------------
Post ID:2944
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-11-28 19:04:48
Subject:RE: [rest-discuss] Another REST vs. SOAP article
Message:

OK, I see what you mean now, and agree completely.  There is no way in a
typical SOA system to pass references to objects around, while REST is
all about passing around individual instances of resources via URI.
That is a big difference.

Toivo Lainevool

> 
> >  The WSDL doc is a single service.  I would say that means one
> > service represents one object.
> 
> Now go the other way. I have a hundred instances being created an
> destroyed at runtime. Whta does the WSDL for that look like?
> 
>   http://www.blogstream.com/pauls/1032521623/index_html
> 
>   Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2945
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-28 19:59:47
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

Toivo "Deutsch" Lainevool wrote:

> OK, I see what you mean now, and agree completely.  There is no way in 
> a typical SOA system to pass references to objects around, while REST 
> is all about passing around individual instances of resources via URI.
> That is a big difference.

I claim this is a big deal because where a service-oriented interface 
tends to combine a bunch of separate things into one interface, REST 
tends to push towards very componentized resources.

This helps interoperability because it means that if you and I can agree 
on the syntax for a purchase order across two domains we don't ALSO have 
to agree on (for example) the API for querying purchase orders (which 
might be different because different people have different querying 
needs), or even fetching purchase orders (because it is hard coded to be 
GET).

I predict that there will be a movement against monolithic interfaces in 
a few years, REST or not. It is very reminicent of the Windows 3.1 API, 
where the first function parameter is a handle for the thing you're 
supposed to work on. Only problem is...there is no way to pass a handle 
to data+methods which is the essence of OOP.

Is anyone brave enough to stand up for monolithic services? ;) Even as a 
devil's advocate?

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2946
Sender:Deepak Sharma <deepmon@...>
Post Date/Time:2002-11-28 20:08:50
Subject:RSS as a web service
Message:

Hi,

I recently read an article by Timothy
Appnel(http://www.oreillynet.com/pub/wlg/2360). Here
he mentioned RSS as a web service and since RSS
follows RESTian approach, I am wondering if RSS is
really a web service or not. Please let me know if I
am getting it right or not?

Thanks,
Deepak
http://www.webjives.com







-----------------------------------------------------------------------------------
Post ID:2947
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-28 20:47:07
Subject:Re: [rest-discuss] RSS as a web service
Message:

Deepak Sharma wrote:

> Hi,
>
> I recently read an article by Timothy
> Appnel(http://www.oreillynet.com/pub/wlg/2360). Here
> he mentioned RSS as a web service and since RSS
> follows RESTian approach, I am wondering if RSS is
> really a web service or not. Please let me know if I
> am getting it right or not?

The term web service has no widely agreed definition. I think that 
Timothy's description is good:

"    * Any site with information and news lacking RSS support. Whether 
it is just assumed or simply overlooked, RSS is the most widely deployed 
Web service across the Internet. Granted, most RSS feeds have very 
simple interfaces with almost as simple backends that are unlike the Web 
services that usually come to mind. (Who says Web services need to be 
complex or sophisticated anyhow?) Under the principles of the REST 
architectural style that the Web was built on, RSS feeds do qualify. 
Consider that any site search engine becomes a Web service if it could 
emit results in RSS and the format's potential in the realm of Web 
services becomes more apparent."

He's right, RSS has not yet been fully exploited and it is likely to be 
the "killer app" for the integration of XML and REST until another XML 
vocabulary becomes big.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2948
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-28 22:01:23
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

----- Original Message -----
From: "Piers Harding" <piers@...>


>
> Possibly the greatest virtue of the Jabber protocol is that it
> implements the truest form of "push technology" (that I know of) to
> date.  One aspect of this is (and arguably its most powerful use) is
> presence management - just simply being able to subscribe to a service,
> and know when it is available (without polling) is a very valuable thing
> (for example - I could subscribe to several similar services, but know
> which ones are available right now, when I want to choosing one to use).
Whenever a piece of software receives an unsolicited message it's 'push'.
Which means that Web servers that receive unsolicited POST messages are
being 'pushed' the data.
Put a Web server on every desktop & you've got a 'push based Web'. (This is
where my phrase 'The Web works both ways' comes from)
If you can't open a connection to the desktop - and Jabber I'm assuming
doesn't do this either - then have the desktop open a connection to the
server (or Jabber server, or HTTP proxy, or whatever) and then wait for
incoming messaging.
The use of HTTP after the socket is opened provides for clear, simplified
and rich application semantics that work with many many tools. I'm spending
some time thinking about the details of a client add-on & server add-on to
do this extra socket connection handoff stuff. I call it Appster & my first
experiment will be to do similar things as the Gnutella protocol does, but
with pure HTTP for discovery and queries.

>
> So where does this leave us?  Not much further along, but perhaps I can
> convince one or two people to have a closer look at Jabber, and I think
> we could concentrate on how to do the bridging between XMPP (the JSF
> name of the Jabber Protocol), and the HTTP requirements of REST?
Okay, somebody should look into that. But I'm going to look at providing
HTTP/URI/XML access everywhere & then move on to Web native pub/sub.

Mike






-----------------------------------------------------------------------------------
Post ID:2949
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-11-28 22:31:16
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

S. Mike Dierken wrote:

> Whenever a piece of software receives an unsolicited message it's 
> 'push'. Which means that Web servers that receive unsolicited POST 
> messages are being 'pushed' the data.
> Put a Web server on every desktop & you've got a 'push based Web'. 
> (This is where my phrase 'The Web works both ways' comes from)

Yes, but don't forget the other half. With Jabber and most other P2P 
systems, I can "log on" as me anywhere in the world and messages are 
forwarded to me. That's because there is an always-on intermediary that 
stands in for me. The lack of these intermediaries is a big problem for 
HTTP-based P2P and is the second major reason (beyond firewalls) that 
HTTP is not seen as much of a P2P solution.

 > If you can't open a connection to the desktop - and Jabber
 > I'm assuming doesn't do this either - then have the desktop open a
 > connection to the server (or Jabber server, or HTTP proxy, or
 > whatever) and then wait for

> incoming messaging.

Well it probably doesn't make that much sense to connect to a true "data 
server" and wait for it to send you messages. I'm not going to open a 
connection to Google and Slashdot and a dozen Weblogs and just sit 
there. More likely I have a single trusted intermediary with a single 
socket open for me. It either polls those other sites or accepts 
notifications for me.

It needs to do the message redirecting for me and it might as well have 
store and forward and presence capabilities at the same time.

Getting the trusted intermediaries out there and available involves a 
little bit of a bootstrapping problem.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2950
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-11-29 03:43:18
Subject:Server push and REST
Message:

Recalling Fielding's dissertation, he specifically says that REST is based
on the client-server model.  He also makes a quick point that you could
acheive P2P by having both a client and a server on both ends.  However, I
have seen several discussions here in which people are talking about the
server pushing to the client.  It even seems that Fielding's own Waka
contains features like this.

Wouldn't such an approach be non-RESTful?

---
Seairth Jacobs
seairth@...

p.s.  Happy Thanksgiving for those who celebrate it (and a happy Thursday
for those who don't).







-----------------------------------------------------------------------------------
Post ID:2951
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-11-29 04:02:49
Subject:Re: [rest-discuss] Server push and REST
Message:

> Recalling Fielding's dissertation, he specifically says that REST is based
> on the client-server model.  He also makes a quick point that you could
> acheive P2P by having both a client and a server on both ends.  However, I
> have seen several discussions here in which people are talking about the
> server pushing to the client.  It even seems that Fielding's own Waka
> contains features like this.

Is there a difference between "having both a client and a server on both
ends", and "the server pushing to the client"?

Does the server pushing to the client constitute messages following a 
request which are not direct responses to that request?

Michael







-----------------------------------------------------------------------------------
Post ID:2952
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-29 08:15:29
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

> Yes, but don't forget the other half. With Jabber and most other P2P
> systems, I can "log on" as me anywhere in the world and messages are
> forwarded to me. That's because there is an always-on intermediary that
> stands in for me. The lack of these intermediaries is a big problem for
> HTTP-based P2P and is the second major reason (beyond firewalls) that
> HTTP is not seen as much of a P2P solution.
Then we will build them.

>
> Well it probably doesn't make that much sense to connect to a true "data
> server" and wait for it to send you messages. I'm not going to open a
> connection to Google and Slashdot and a dozen Weblogs and just sit
> there.
Never said it would.

> More likely I have a single trusted intermediary with a single
> socket open for me.
Eventually, you could choose from many, and with dynamic DNS have your URI's
mapped back to whatever IP and device you are using. But initially, a single
one is fine. Like the way Hotmail is a single trusted intermediary.

> It either polls those other sites or accepts notifications for me.
It won't poll those other sites or accept notifications. It accepts
requests, and the client provides responses. Just like every other part of
the Web. If the request is a POST that is a notification, sure.

>
> It needs to do the message redirecting for me and it might as well have
> store and forward and presence capabilities at the same time.
You are correct sir.

>
> Getting the trusted intermediaries out there and available involves a
> little bit of a bootstrapping problem.
Yep.







-----------------------------------------------------------------------------------
Post ID:2953
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-11-29 08:18:50
Subject:Re: [rest-discuss] Server push and REST
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>


> I have seen several discussions here in which people are talking about the
> server pushing to the client.
It depends on what is being pushed. If it is a request, then the pusher is a
'client'. If it is a response, then you are doing request/response outside a
single TCP/IP connection - which is fine but I haven't seen anybody do it
yet (you'll need correlation ids in messages, etc).

Push is a really bad term. Trust me.






-----------------------------------------------------------------------------------
Post ID:2954
Sender:"Yannick Loiseau" <yloiseau@...>
Post Date/Time:2002-11-29 09:58:33
Subject:Re: [rest-discuss] Rest compliant protocols
Message:

From: "Paul Prescod" <paul@...>
>  The lack of these intermediaries is a big problem for
> HTTP-based P2P and is the second major reason (beyond firewalls) that
> HTTP is not seen as much of a P2P solution.
>

A simple solution could just be a directory server (ldap) in wich the
mapping user/ip is done, juste like isp servers for NetMeeting (which are
actually ldap), or DynDNS-like services.








-----------------------------------------------------------------------------------
Post ID:2955
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-12-01 00:37:30
Subject:RE: [rest-discuss] Another REST vs. SOAP article
Message:

> -----Original Message-----
> From: Paul Prescod, Sent: Thursday, November 28, 2002 12:00 PM
> 
> Toivo "Deutsch" Lainevool wrote:
> 
> > OK, I see what you mean now, and agree completely.  There is no way
in
> > a typical SOA system to pass references to objects around, while
REST
> > is all about passing around individual instances of resources via
URI.
> > That is a big difference.
> 
> I claim this is a big deal because where a service-oriented interface
> tends to combine a bunch of separate things into one interface, REST
> tends to push towards very componentized resources.
> 
> Is anyone brave enough to stand up for monolithic services? ;) Even as
a
> devil's advocate?
> 
>   Paul Prescod

I wouldn't stand up for monolithic services, but I will try to defend
the SOA approach a little.  (Keep in mind that I'm not arguing that one
of the approaches is "better", I think both have their appropriate uses.
To me there is no clear winner.  When deciding which is better to use in
a particular system you have a lot of context to keep in mind.  I'm just
trying to get a better handle on some criteria to help me make this
decision.)

One of the hardest things to do when designing networked systems is
choosing the right abstractions (e.g. resources or services) at the
right level of granularity.  Systems that have abstractions that are too
coarse grained end up pushing around a lot of unneeded data across the
wire.  If the granularity is too fine, too many messages go back and
forth across the network.

I don't think service interfaces need to be "monolithic".  This just
seems like an issue of picking the right abstractions and granularity.
To me it seems like picking the right abstractions and granularity would
be more difficult with REST that with services.  This is because
resources are restricted to the HTTP verbs for interacting with the
outside world, where with the service interface you are free to make up
any verbs you want.  So if you had a bank account that you were
modeling, with a service interface you could do something like:

Service: Account
	Has operation: deposit( account_number, amount )
	Has operation: withdrawal( account_number, amount )
	Has operation: calculateInterest( account_number )

I wouldn't call this "combining a bunch of separate things".  I would
say this is grouping a set of related operation together in a cohesive
unit. How would model these same behaviors in a REST system?  Can you
have one cohesive unit that model all these behaviors in a way that
would be obvious to a user?

It's probably because I've been using OO for a long time now, and
haven't had nearly as much experience with REST, but it seems easier and
more natural to do this the service oriented way.

Toivo Lainevool
(ducking in anticipation of the flames)








-----------------------------------------------------------------------------------
Post ID:2956
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-01 00:52:48
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

----- Original Message ----- 
From: "Toivo "Deutsch" Lainevool" <tlainevool@...>

> 
> Service: Account
> Has operation: deposit( account_number, amount )
> Has operation: withdrawal( account_number, amount )
> Has operation: calculateInterest( account_number )

> How would model these same behaviors in a REST system?  
Here's one approach using verbs from HTTP:

 server.post("accounts/account_number/credits",amount);
 server.post("accounts/account_number/debits",amount);
 server.get("accounts/account_number/interest");








-----------------------------------------------------------------------------------
Post ID:2957
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-12-01 01:33:54
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

S. Mike Dierken wrote:
> Here's one approach using verbs from HTTP:
> 
>  server.post("accounts/account_number/credits",amount);
>  server.post("accounts/account_number/debits",amount);
>  server.get("accounts/account_number/interest");

yep, but (nit-picking) your POST URLs could just as easily be:

accounts/account_number/deposits
accounts/account_number/withdrawals

or whatever you want for that matter.

for the POSTs, i also use a /credits/transaction_id (or equivalent) URL
which gets returned in a "201 Created" response.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2

i call these resources 'sub-resources' because they're only relevant in
the context of one particular account.  they're also containers because
they are basically the subset of all credits/debits/whatever associated
with a particular account.  this makes the semantics for POSTing to them
crystal clear IMHO.  compare/contrast with POSTing to
account/account_number and trying to distinguish whether it is a credit
or a debit that is being POSTed.  it seems to me that this is the part
of resource modelling that corresponds to one-to-many relationships in
ER/database modelling.







-----------------------------------------------------------------------------------
Post ID:2958
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-12-01 01:49:37
Subject:POST/PUT to the same URI?
Message:

Can anyone think of a reason (and possibly example) why you would use PUT
and POST on the same URI?  Does such a thing even make sense?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:2959
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-01 01:56:42
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

Toivo "Deutsch" Lainevool wrote:

> I wouldn't stand up for monolithic services, but I will try to defend
> the SOA approach a little.  (Keep in mind that I'm not arguing that one
> of the approaches is "better", I think both have their appropriate uses.
> To me there is no clear winner.  When deciding which is better to use in
> a particular system you have a lot of context to keep in mind.  I'm just
> trying to get a better handle on some criteria to help me make this
> decision.)

I think I could be convinced that a "generic objects" model has some 
advantages over a REST model in some circumstances but I really cannot 
see _any_ virtue in the service oriented model over the generic objects 
model. It seems to me to be just a "dumbed down" version of OOP (where 
objects have a uniform addressing scheme and can be created and 
destroyed at runtime). Perhaps that dumbing down has useful sociological 
effects. Clearly SOAP and XML-RPC seem not to have suffered in 
popularity for leaving out the concept of "dynamic objects" but it seems 
a serious omission to me.

> One of the hardest things to do when designing networked systems is
> choosing the right abstractions (e.g. resources or services) at the
> right level of granularity.  Systems that have abstractions that are 
> too coarse grained end up pushing around a lot of unneeded data across 
> the wire.  If the granularity is too fine, too many messages go back 
> and forth across the network.

I'm not convinced that there is a correspondance between granularity of 
addressing and granularity of messaging. One message could influence 
thousands of addressable objects or thousands of messages could have 
only a small effect on a single object.

> I don't think service interfaces need to be "monolithic".  This just
> seems like an issue of picking the right abstractions and granularity.
> To me it seems like picking the right abstractions and granularity 
> would be more difficult with REST that with services.  This is because
> resources are restricted to the HTTP verbs for interacting with the
> outside world, where with the service interface you are free to make 
> up any verbs you want.  So if you had a bank account that you were
> modeling, with a service interface you could do something like:

Despite what I said above, I can see how REST makes it harder to have 
precise control over the granularity of messaging. You can't reasonably 
have a method called "UpdateNThings" in REST, though you could emulate 
it by POSTing an "UpdateNThingsRequest" resource. I would actually 
rather compare SOA to "traditional, arbitrary methods OOP" because the 
delta between that and SOA is smaller.

> Service: Account
> 	Has operation: deposit( account_number, amount )
> 	Has operation: withdrawal( account_number, amount )
> 	Has operation: calculateInterest( account_number )
>
> I wouldn't call this "combining a bunch of separate things".  I would
> say this is grouping a set of related operation together in a cohesive
> unit.

You call the service Account but it is really AccountManager in that it 
does not represent any particular account. That is nothing like OOP. In 
OOP it would be:

Service: AccountManager
	Has operation: listAccounts() -> Account
	Has operation: findAccount(account_number) -> Account
	Has operation: findAccount(branch, customer_id) -> Account
	Has operation: findAccounts(customer_name) -> Account[]
	Has operation: createAccount(account_number, AccountData) -> Account
	Has operation: destroyAccount(account_number)

Service: Account
	Has operation: deposit(amount)
	Has operation: withdraw(amount)
	Has operation: calculateInterest()

This is a proper separation of concerns. Now we do not even have to 
agree upon an account query model to share accounts. Similarly in a Java 
program, you don't have to know how I created an InputStream to use it 
as an InputStream. One library doesn't need to know the full details of 
another library's interface to share objects. It only needs to know the 
interfaces _of the objects_.

The mapping to REST is basically:

  listAccounts -> GET /accounts
  findAccount(s) -> GET /accounts?customer_name=...
  createAccount -> POST /accounts returns /accounts/some_account
  destroyAccount -> DELETE /accounts/some_account
  deposit -> POST /accounts/credits (as per Dierkin)
  withdraw -> POST (arguably those could be the same method)
  calculateInterest -> (should this be a client service or embedded in 
the server business logic???)

> It's probably because I've been using OO for a long time now, and
> haven't had nearly as much experience with REST, but it seems easier 
> and more natural to do this the service oriented way.

If you're used to OO then I would expect the service oriented way to 
feel odd to you. A 1970s Lisp or COBOL would totally understand the 
service oriented interface as a functional interface. The key to OO is 
integrating the data and the methods into separably addressable objects 
with polymorphism. REST has that and more traditional web services 
techniques do not.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2960
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-12-01 12:19:59
Subject:Re: [rest-discuss] POST/PUT to the same URI?
Message:

Seairth Jacobs wrote:
> Can anyone think of a reason (and possibly example) why you would use PUT
> and POST on the same URI?  Does such a thing even make sense?

i haven't found a situation where it has made sense so far.  it's a
phenomenon i have observed in practice; i've been meaning to ask
rest-discuss but hadn't got around to it.

i think this is because most of the time when you would want to POST to
a resource that you can already PUT to (e.g. /accounts/[id]), you are
probably better off POSTing to a 'sub-resource' which is a collection
instead (e.g. /accounts/[id]/withdrawals).  (cf. my post from yesterday.)

i have used this fact to implement a browser workaround or hack.
Because browsers can't send PUT, e.g. as the method of a form submit, I
'pre-process' the request at the server so that the POST is changed to a
PUT.  i then continue with processing as normal.  this means I can use
the same code for browsers and machine clients (modulo differences
between representations, but i'm working on seperating that concern
cleanly as well, and joe gregorio has already done a nice job with
RESTlog).  it also means that i can support PUT operations using HTML
forms, which is important for my app.

when i saw REST first i wondered, "but how the hell can REST work when
browsers don't send PUT"?  (using client-side XMLHttpRequest-ish objects
doesn't count, IMO.)  but it seems to be mostly a non-issue because you
can effectively overload the semantics of POST to include PUT for broken
user agents, depending on the URI in question.







-----------------------------------------------------------------------------------
Post ID:2961
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-01 14:48:22
Subject:Re: [rest-discuss] POST/PUT to the same URI?
Message:

Seairth Jacobs wrote:

> Can anyone think of a reason (and possibly example) why you would use PUT
> and POST on the same URI?  Does such a thing even make sense?

Let's say a URI represents a log for a chat session. PUT would overwrite 
the log and start again. POST would add some text to the bottom.

  Paul Prescod









-----------------------------------------------------------------------------------
Post ID:2962
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-12-01 14:49:52
Subject:RE: [rest-discuss] POST/PUT to the same URI?
Message:

> From: Seairth Jacobs [mailto:seairth@...]
> Sent: Sunday, December 01, 2002 2:50 AM
> To: rest-discuss
> Subject: [rest-discuss] POST/PUT to the same URI?
>
>
> Can anyone think of a reason (and possibly example) why you would use PUT
> and POST on the same URI?  Does such a thing even make sense?

I can image an authorable server that lets you create
POST-accepting-resources using PUT (for instance, followed by a PROPPATCH
setting some server-internal live properties that make the already existing
"plain" resource an acceptor for POSTs).

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760







-----------------------------------------------------------------------------------
Post ID:2963
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-12-01 16:12:07
Subject:RE: [rest-discuss] Another REST vs. SOAP article
Message:

> -----Original Message-----
> From: Paul Prescod, Sent: Saturday, November 30, 2002 5:57 PM
> 
> I think I could be convinced that a "generic objects" model has some
> advantages over a REST model in some circumstances but I really cannot
> see _any_ virtue in the service oriented model over the generic
objects
> model. It seems to me to be just a "dumbed down" version of OOP (where
> objects have a uniform addressing scheme and can be created and
> destroyed at runtime). Perhaps that dumbing down has useful
sociological
> effects. Clearly SOAP and XML-RPC seem not to have suffered in
> popularity for leaving out the concept of "dynamic objects" but it
seems
> a serious omission to me.

I think one advantage the "generic object" approach has over REST is
that it can still be modeled with standard OO notation, and it can
easily be mapped to OO programming languages via toolkits.  Ease of use
is an important architectural aspect to consider.  There is dissonance
that developers feel when switching between OO and REST.  In other words
switching between OO and REST is a major paradigm shift.  Switching
between "dynamic objects" and "generic objects" is not that big a deal.

> 
> 
> I'm not convinced that there is a correspondance between granularity
of
> addressing and granularity of messaging. One message could influence
> thousands of addressable objects or thousands of messages could have
> only a small effect on a single object.
> 
> Despite what I said above, I can see how REST makes it harder to have
> precise control over the granularity of messaging. You can't
reasonably
> have a method called "UpdateNThings" in REST, though you could emulate
> it by POSTing an "UpdateNThingsRequest" resource. I would actually
> rather compare SOA to "traditional, arbitrary methods OOP" because the
> delta between that and SOA is smaller.

Makes sense.

> 
> 
> You call the service Account but it is really AccountManager in that
it
> does not represent any particular account. That is nothing like OOP.
In
> OOP it would be:
> 
> Service: AccountManager
> 	Has operation: listAccounts() -> Account
> 	Has operation: findAccount(account_number) -> Account
> 	Has operation: findAccount(branch, customer_id) -> Account
> 	Has operation: findAccounts(customer_name) -> Account[]
> 	Has operation: createAccount(account_number, AccountData) ->
Account
> 	Has operation: destroyAccount(account_number)
> 
> Service: Account
> 	Has operation: deposit(amount)
> 	Has operation: withdraw(amount)
> 	Has operation: calculateInterest()
> 
> This is a proper separation of concerns. Now we do not even have to
> agree upon an account query model to share accounts. Similarly in a
Java
> program, you don't have to know how I created an InputStream to use it
> as an InputStream. One library doesn't need to know the full details
of
> another library's interface to share objects. It only needs to know
the
> interfaces _of the objects_.


In a service oriented system this can be modeled as:

Service: Accounts
	Has operation: listAccounts() -> Account
	Has operation: findAccount(account_number) -> Account
	Has operation: findAccount(branch, customer_id) -> Account
	Has operation: findAccounts(customer_name) -> Account[]
	Has operation: createAccount(account_number, AccountData) ->
Account
	Has operation: destroyAccount(account_number)

Service: IndividualAccount
	Has operation: deposit(account_number, amount)
	Has operation: withdraw(account_number, amount)
	Has operation: calculateInterest(account_number)

This still has all the goodness of separation of concerns and fully
defined query model.  Sure it's not full blown "dynamic objects", but it
looks familiar to anyone who knows OO.

> 
> The mapping to REST is basically:
> 
>   listAccounts -> GET /accounts
>   findAccount(s) -> GET /accounts?customer_name=...
>   createAccount -> POST /accounts returns /accounts/some_account
>   destroyAccount -> DELETE /accounts/some_account
>   deposit -> POST /accounts/credits (as per Dierkin)
>   withdraw -> POST (arguably those could be the same method)
>   calculateInterest -> (should this be a client service or embedded in
> the server business logic???)
> 

This model seems to introduce some incidental complexity (see
http://www.computer.org/proceedings/icre/0565/05650130abs.htm).  Instead
of just representing an account as a single abstraction, we now have an
account resource, an account-credit abstraction and an account-debit
abstraction.

This is getting interesting.  Its making me think that if there were a
good Object->REST mapping language we could have the best of both
worlds: a fully "dynamic object" model (that allows OO notation and easy
mapping to OOPLs) with a REST based messaging taking caring of the
networking aspects.  I might noodle on this for a bit and see if I can
come up with something.


Toivo Lainevool







-----------------------------------------------------------------------------------
Post ID:2964
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-01 17:23:48
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

----- Original Message -----
From: "Toivo "Deutsch" Lainevool" <tlainevool@...>

>
> This model seems to introduce some incidental complexity (see
> http://www.computer.org/proceedings/icre/0565/05650130abs.htm).  Instead
> of just representing an account as a single abstraction, we now have an
> account resource, an account-credit abstraction and an account-debit
> abstraction.
Would you consider that the account-credit abstraction is just transfering
complexity of the 'deposit()' concept to a different place in the design? So
it's not so much an addition as a transfer?







-----------------------------------------------------------------------------------
Post ID:2965
Sender:"Toivo \"Deutsch\" Lainevool" <tlainevool@...>
Post Date/Time:2002-12-01 17:33:29
Subject:RE: [rest-discuss] Another REST vs. SOAP article
Message:

> -----Original Message-----
> From: S. Mike Dierken > 
> >
> > This model seems to introduce some incidental complexity (see
> > http://www.computer.org/proceedings/icre/0565/05650130abs.htm).
Instead
> > of just representing an account as a single abstraction, we now have
an
> > account resource, an account-credit abstraction and an account-debit
> > abstraction.
> Would you consider that the account-credit abstraction is just
transfering
> complexity of the 'deposit()' concept to a different place in the
design?
> So it's not so much an addition as a transfer?

I think it does add complexity, though.  With a new resource you have a
new URI to keep track of, and you have to know which methods are valid
for it (what happens if I "get" from this resource?), the parameters it
accepts, what each of the methods returns, etc.  That's not a whole lot
of extra over a method name, parameter list and return type; but in a
large system those little things add up.

Toivo Lainevool








-----------------------------------------------------------------------------------
Post ID:2966
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-12-01 20:34:06
Subject:Re: Another REST vs. SOAP article
Message:

"Toivo \"Deutsch\" Lainevool" wrote:
> 
> > -----Original Message-----
> > From: S. Mike Dierken > 
> > >
> > > This model seems to introduce some incidental complexity (see
> > > http://www.computer.org/proceedings/icre/0565/05650130abs.htm).
> Instead
> > > of just representing an account as a single abstraction, we now 
have
> an
> > > account resource, an account-credit abstraction and an account-
debit
> > > abstraction.
> > Would you consider that the account-credit abstraction is just
> transfering
> > complexity of the 'deposit()' concept to a different place in the
> design?
> > So it's not so much an addition as a transfer?
> 
> I think it does add complexity, though.  With a new resource you 
have a
> new URI to keep track of, and you have to know which methods are 
valid
> for it (what happens if I "get" from this resource?), the 
parameters it
> accepts, what each of the methods returns, etc.  

I intend to revert to the human-understandable version here, that is, 
deposits and withdrawals.  (Debit and credit require me to buy into 
accounting jargon.)

I want each of my deposits and withdrawals to have its own identity.
If I am working with my account (like balancing my checkbook), I want 
to be able to work with each item individually.

I think it is the same with any other composite object model:  each 
of the sub-objects in the composite has its own identity. 

For example, in orders, I want to be able to work with each line item 
independently sometimes.  Likewise each delivery and payment.  

Whether modeled as resources or objects or database tables, each 
element will have its own identity as well as being represented in 
representations of "the whole", e.g. the state of the account or 
order.

I can't think of any business object models I've worked with, where 
the sub-objects were not also first-class objects with their own 
identity.

And with objects, using the Composite pattern, every object in the 
composite has the same set of methods.


In other words, I don't see such a great divide between objects and 
REST resources.  I see a much bigger divide between REST and RPC-
style SOAP, which reminds me more of C.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2967
Sender:alexi <groups@...>
Post Date/Time:2002-11-30 23:41:30
Subject:REST based WS implementations
Message:

Hi all,

I have recently discovered REST for myself and I glad
I did.  For quite sometime I thought that WebServices
should be more URI based, so I was glad to find that
there is the whole theory behind that :). While I am
trying to catch up with the REST literature I have a
question of a more practicle  nature. I am wondering
if there is an outgoing Open Source effort(s) which
have a goal to build a web services infrustucture
around REST principles.

Thanks Alexi.







-----------------------------------------------------------------------------------
Post ID:2968
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-01 21:24:20
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

Toivo "Deutsch" Lainevool wrote:

> In a service oriented system this can be modeled as:
>
> Service: Accounts
> 	Has operation: listAccounts() -> Account
> 	Has operation: findAccount(account_number) -> Account
> 	Has operation: findAccount(branch, customer_id) -> Account
> 	Has operation: findAccounts(customer_name) -> Account[]
> 	Has operation: createAccount(account_number, AccountData) ->
> Account
> 	Has operation: destroyAccount(account_number)
>
> Service: IndividualAccount
> 	Has operation: deposit(account_number, amount)
> 	Has operation: withdraw(account_number, amount)
> 	Has operation: calculateInterest(account_number)

Yes but WHY???? Why introduce an extra layer of "pass the object 
identifer as the first parameter"? Do you realize that this means that 
rahter than passing around opaque pointers to account objects (URIs in 
the Web, 32-bit numbers in C++) I now have to pass around a URI to the 
IndividualAccount service AND an account number. Logic would dictate 
that your life would be simpler if you put them together into an opaque 
tuple:

(http://machine/Account, 234324)

Logically that would be encoded as:

http://machine/Account/234324

Somebody please tell me what the advantage of the service-oriented 
version is! I don't understand why our industry would move in that 
direction after ten years of OOP.

> This model seems to introduce some incidental complexity (see
> http://www.computer.org/proceedings/icre/0565/05650130abs.htm).  Instead
> of just representing an account as a single abstraction, we now have an
> account resource, an account-credit abstraction and an account-debit
> abstraction.

Arguably you could combine them. A domain expert would probably have to 
say.

But anyhow, in a real banking app, every credit or debit is a unique, 
persistent object that can be referenced. It should be possible to list 
all credits for a particular day, etc.

> This is getting interesting.  Its making me think that if there were a
> good Object->REST mapping language we could have the best of both
> worlds: a fully "dynamic object" model (that allows OO notation and easy
> mapping to OOPLs) with a REST based messaging taking caring of the
> networking aspects.  I might noodle on this for a bit and see if I can
> come up with something.

I started something like that with WRDL but I hold out hope that WSDL 
can be reformed to work.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2969
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-01 21:31:50
Subject:Re: [rest-discuss] REST based WS implementations
Message:

alexi wrote:

> Hi all,
>
> I have recently discovered REST for myself and I glad
> I did.  For quite sometime I thought that WebServices
> should be more URI based, so I was glad to find that
> there is the whole theory behind that :). While I am
> trying to catch up with the REST literature I have a
> question of a more practicle  nature. I am wondering
> if there is an outgoing Open Source effort(s) which
> have a goal to build a web services infrustucture
> around REST principles.

REST web services are the natural intersection of HTTP and perhaps its 
successor protocol and various data encoding strategies like RSS, the 
semantic web, SVG and XML in general. Any toolkit that combines the most 
appropriate data encoding for your problem domain with HTTP 
functionality is an open source REST tool. Examples include Zope, 
Quixote, Redfoot, Mason and the various J2EE tools.

I'm not saying that there is no room for new toolkits but my personal 
opinion is that if you combine a perfect toolkit for your data format 
(e.g. an RSS parser or RDF engine) with the perfect HTTP platform for 
your language, you get a REST toolkit out of the combination "for free." 
And further, it is somewhat dangerous (not entirely wrong, but somewhat 
dangerous) to try to tie the encoding and architecture/protocol more 
closely.

http://www.prescod.net/rest/encoding

Perhaps an XML+HTTP+URIs package would be a good idea regardless. But it 
wouldn't be a REST toolkit unless it also supported totally unstructured 
data.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2970
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-02 05:47:31
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

On Sun, Dec 01, 2002 at 08:12:07AM -0800, Toivo Deutsch Lainevool wrote:
> I think one advantage the "generic object" approach has over REST is
> that it can still be modeled with standard OO notation, and it can
> easily be mapped to OO programming languages via toolkits.  Ease of use
> is an important architectural aspect to consider.  There is dissonance
> that developers feel when switching between OO and REST.  In other words
> switching between OO and REST is a major paradigm shift.  Switching
> between "dynamic objects" and "generic objects" is not that big a deal.

My experience is exactly the opposite.  I was never comfortable with the
CORBA style SOA based architecture.  Whenever I did any substantial
work in it, I always found so many integration problems due to the
different assumptions about each object's internal exposed through its
interface; failure model, concurrency, etc..  When I realized what the
Web was, and that "all" I was doing was ensuring that each object had
the same interface, I immediately "got it" because I realized just how
easy it was going to make my job as developer of distributed objects.

IMO, REST is more "OO" (whatever exactly that means - things with
behaviour, state, identity, I say) than SOAs.

MB
-- 
Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca

   Will distribute objects for food






-----------------------------------------------------------------------------------
Post ID:2971
Sender:=?ISO-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-12-02 09:45:07
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

Paul Prescod wrote:
> Toivo "Deutsch" Lainevool wrote:

>>In a service oriented system this can be modeled as:
>>
>>Service: Accounts
>>	Has operation: listAccounts() -> Account
>>	Has operation: findAccount(account_number) -> Account
>>	Has operation: findAccount(branch, customer_id) -> Account
>>	Has operation: findAccounts(customer_name) -> Account[]
>>	Has operation: createAccount(account_number, AccountData) ->
>>Account
>>	Has operation: destroyAccount(account_number)
>>
>>Service: IndividualAccount
>>	Has operation: deposit(account_number, amount)
>>	Has operation: withdraw(account_number, amount)
>>	Has operation: calculateInterest(account_number)
> 
> [...]
> Somebody please tell me what the advantage of the service-oriented 
> version is! I don't understand why our industry would move in that 
> direction after ten years of OOP.

I don't understand the terminology in this thread at all. To me, OOP 
is about managing dependencies in sofware by using jumptables.  I 
don't see how the service oriented example above is not OOP. Whether 
it's a well conceived solution to a particular problem is another 
matter.

Bill de h�ra







-----------------------------------------------------------------------------------
Post ID:2972
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-12-02 15:24:36
Subject:RE: [rest-discuss] Another REST vs. SOAP article
Message:

> Is anyone brave enough to stand up for monolithic services? 
> ;) Even as a 
> devil's advocate?
> 
>   Paul Prescod

Not sure what you mean by 'monolithic' in this setting.  I usually
think of it as meaning indivisible.  Is there such a thing as a
monolithic interface?  I'm afraid I'm not visualizing this very
well.

Walden






-----------------------------------------------------------------------------------
Post ID:2973
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-12-02 15:34:34
Subject:RE: [rest-discuss] Server push and REST
Message:


> -----Original Message-----
> From: S. Mike Dierken [mailto:mdierken@...]
> Sent: Friday, November 29, 2002 3:19 AM
> To: rest-discuss
> Subject: Re: [rest-discuss] Server push and REST
> 
> 
> 
> ----- Original Message -----
> From: "Seairth Jacobs" <seairth@...>
> 
> 
> > I have seen several discussions here in which people are 
> talking about the
> > server pushing to the client.
> It depends on what is being pushed. If it is a request, then 
> the pusher is a
> 'client'. If it is a response, then you are doing 
> request/response outside a
> single TCP/IP connection - which is fine but I haven't seen 
> anybody do it
> yet (you'll need correlation ids in messages, etc).
> 
> Push is a really bad term. Trust me.

I do.

Implicit Request and Persistent Request are better terms.  Implicit
request means that as long as you're there and I'm here and you have
class X of data, I want it.  Persistent Request means I want each
and every piece of it, without having to ask for each and every
piece.  Of course, you can elaborate on those themes.

Most of my career I've worked on "push" based market data systems.
It's an optimization of the more familiar client-server model in
which requests are explicit.

Walden


> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 







-----------------------------------------------------------------------------------
Post ID:2974
Sender:Philip Eskelin <philip_eskelin@...>
Post Date/Time:2002-12-02 16:51:45
Subject:Re: [rest-discuss] POST/PUT to the same URI?
Message:

Paul Prescod wrote:
> Seairth Jacobs wrote:
> 
> > Can anyone think of a reason (and possibly
> > example) why you would use PUT and POST on the
> > same URI?  Does such a thing even make sense?
> 
> Let's say a URI represents a log for a chat session.
> PUT would overwrite the log and start again. POST 
> would add some text to the bottom.

Here is another example: one user POSTs a
representation of an empty container resource named
'b' to the container resource at /a, then POSTs
representations of new resources named 'c' and 'd' to
/a/b.
  1. POST to /a representation of b
  2. POST to /a/b representation of c
  3. POST to /a/b representation of d

Another user might take care of the whole thing in one
PUT request by sending a representation of a container
resource named b, with its subordinates c and d
already POSTed to it, into the container resource at
/a.
  1. POST to b representation of c
  2. POST to b representation of d
  3. PUT to /a/b representation of b

This shows that POST and PUT can happen to the same
URI.  The first user POSTed representations of c and d
to /a/b.  Yet in the second case b was PUT to /a/b
with c and d already POSTed to it.  In both cases new
resources will exist at /a/b, /a/b/c and /a/b/d.

Philip

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com






-----------------------------------------------------------------------------------
Post ID:2975
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-12-02 17:01:49
Subject:RE: [rest-discuss] POST/PUT to the same URI?
Message:

> This shows that POST and PUT can happen to the same
> URI.  The first user POSTed representations of c and d
> to /a/b.  Yet in the second case b was PUT to /a/b
> with c and d already POSTed to it.  In both cases new
> resources will exist at /a/b, /a/b/c and /a/b/d.
> 
> Philip
> 

There's something a little strange going on here.  How can
the 'b' of the PUT (a representation) have had things POSTed
to it?  POST is defined as a resource method, not a way to
compose representations.  Do I miss the boat?

Walden






-----------------------------------------------------------------------------------
Post ID:2976
Sender:"Donald Ball" <dball@...>
Post Date/Time:2002-12-02 17:56:26
Subject:Re: [rest-discuss] REST based WS implementations
Message:

On 11/30/2002 at 3:41 PM alexi wrote:

>Hi all,
>
>I have recently discovered REST for myself and I glad
>I did.  For quite sometime I thought that WebServices
>should be more URI based, so I was glad to find that
>there is the whole theory behind that :). While I am
>trying to catch up with the REST literature I have a
>question of a more practicle  nature. I am wondering
>if there is an outgoing Open Source effort(s) which
>have a goal to build a web services infrustucture
>around REST principles.

Not as such, at least as far as I am aware, but there are webapp
infrastructures that are better or worse suited for REST development. For
example, Apache Jakarta Struts, while being a very popular and robust MVC
infrastructure, is completely ill-suited for REST since the URL and actual
contents of a resource may have no relation to one another (struts overuses
the servlet RequestDispatcher API). Apache Cocoon, for another example, is
reasonably useful for REST - it uses a sitemap to map urls to pipelines of
processing components. On the other hand, it's aimed more at web sites than
webapps, thus may not be suitable as a "web services" infrastructure.

What other webapp infrastructures have people used for REST projects that
turned out well or poorly?

- donald







-----------------------------------------------------------------------------------
Post ID:2977
Sender:Sam Hunting <shunting@...>
Post Date/Time:2002-12-02 18:31:45
Subject:Re: [rest-discuss] REST based WS implementations
Message:

> 
> What other webapp infrastructures have people used for REST projects that
> turned out well or poorly?

In particular, Zope?

Sam Hunting
eTopicality, Inc.


---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.gooseworks.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------







-----------------------------------------------------------------------------------
Post ID:2978
Sender:Philip Eskelin <philip_eskelin@...>
Post Date/Time:2002-12-02 18:46:15
Subject:RE: [rest-discuss] POST/PUT to the same URI?
Message:

Walden Mathews wrote:
> > This shows that POST and PUT can happen to the
> > same URI.  The first user POSTed representations
> > of c and d to /a/b.  Yet in the second case b was
> > PUT to /a/b with c and d already POSTed to it.
> > In both cases new resources will exist at
> > /a/b, /a/b/c and /a/b/d.
>
> There's something a little strange going on here. 
> How can the 'b' of the PUT (a representation) have 
> had things POSTed to it?  POST is defined as a 
> resource method, not a way to compose
> representations.  Do I miss the boat?

Thanks for the question.  For the second example
you're asking about, I assumed the requestor created a
resource with subordinates c and d, then a
representation of the whole thing was transferred to
/a/b via PUT.  But there's nothing stopping you from
only constructing representations of b containing
representations of c and d on the fly and transferring
that instead.

The difference between the two approaches is that you
can either transfer representations taken from
existing resources, or construct and transfer your own
representations (e.g., telnet to the node and
literally type out the PUT request and its XML)
without relying on an existing (non-vacuous) resource.

I've coded my toolkit project under this philosophy. 
Please let me know if there is a flaw in my thinking.

Thanks,
Philip

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com






-----------------------------------------------------------------------------------
Post ID:2979
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-02 19:27:44
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

Bill de h�ra wrote:

> I don't understand the terminology in this thread at all. To me, OOP
> is about managing dependencies in sofware by using jumptables.  

 > I don't see how the service oriented example above is not OOP.

To me, OOP is about objects, and objects are things with identity, state 
and behaviour. If we put aside static type checking for a second, any 
object in an OOPL may refer to any other object in a consistent way 
(void *x, Object x, etc).

When you use the "handle as first parameter hack", you now have to have 
two addresses for each object. The address of the service (usually an 
HTTP URI) and the "handle" which is really just another address. In my 
opinion, this is not proper OOP programming. It would be very rare to 
see a Java interface like:

class IndividualAccount{
     function debit(accountNumber, val);
     function credit(accountNumber, val);
}

Because this makes it _impossible_ to pass a reference to an account as 
a standard Java object reference. Instead, you would much more often do:

class AccountManager{
     function getAccount(number);
}

class Account{
     function debit(val);
     function credit(val);
}

Now the account is a first-class object which can be passed around 
without reference to the query interface. i.e. it has identity, state 
and behaviour. As an example of how its identity might be important, you 
might have different access controls on different accounts. This could 
be done in a language or system with per-object access controls. Even in 
such a system, it is not straightforward if you've hacked static methods 
to _emulate_ instance objects in a manner that is opaque to your 
infrastructure.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2980
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-12-02 20:09:06
Subject:RE: [rest-discuss] Another REST vs. SOAP article
Message:

Terminology strikes again.  Object models and object oriented
programming have separate lives, according to what I read.  Bill
is talking about polymorphic method resolution, which is one
feature of OO (the programming thing), while Paul's description
of "identity, state and behavior" is the /sine qua non/ of the
object model.

That's my take...

Walden


> -----Original Message-----
> From: Paul Prescod [mailto:paul@...]
> Sent: Monday, December 02, 2002 2:28 PM
> To: Bill de hra
> Cc: Toivo "Deutsch" Lainevool; rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Another REST vs. SOAP article
> 
> 
> Bill de hra wrote:
> 
> > I don't understand the terminology in this thread at all. To me, OOP
> > is about managing dependencies in sofware by using jumptables.  
> 
>  > I don't see how the service oriented example above is not OOP.
> 
> To me, OOP is about objects, and objects are things with 
> identity, state 
> and behaviour. If we put aside static type checking for a second, any 
> object in an OOPL may refer to any other object in a consistent way 
> (void *x, Object x, etc).
> 
> When you use the "handle as first parameter hack", you now 
> have to have 
> two addresses for each object. The address of the service (usually an 
> HTTP URI) and the "handle" which is really just another 
> address. In my 
> opinion, this is not proper OOP programming. It would be very rare to 
> see a Java interface like:
> 
> class IndividualAccount{
>      function debit(accountNumber, val);
>      function credit(accountNumber, val);
> }
> 
> Because this makes it _impossible_ to pass a reference to an 
> account as 
> a standard Java object reference. Instead, you would much 
> more often do:
> 
> class AccountManager{
>      function getAccount(number);
> }
> 
> class Account{
>      function debit(val);
>      function credit(val);
> }
> 
> Now the account is a first-class object which can be passed around 
> without reference to the query interface. i.e. it has identity, state 
> and behaviour. As an example of how its identity might be 
> important, you 
> might have different access controls on different accounts. 
> This could 
> be done in a language or system with per-object access 
> controls. Even in 
> such a system, it is not straightforward if you've hacked 
> static methods 
> to _emulate_ instance objects in a manner that is opaque to your 
> infrastructure.
> 
>   Paul Prescod
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
> 






-----------------------------------------------------------------------------------
Post ID:2981
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-03 17:42:41
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

Mathews, Walden wrote:

> >Is anyone brave enough to stand up for monolithic services?
> >;) Even as a
> >devil's advocate?
> >
> >  Paul Prescod
>
>
> Not sure what you mean by 'monolithic' in this setting.  I usually
> think of it as meaning indivisible.  Is there such a thing as a
> monolithic interface?  I'm afraid I'm not visualizing this very
> well.

I think of "atomic" as individible. Monolithic means "not divided when 
it should be." dictionary.com says: "Constituting or acting as a single, 
often rigid, uniform whole"

To me, a "monolithic interface" is a network-addressable object that 
contains many "logical" objects which are not directly addressable 
themselves. e.g. purchase orders that do not have URIs themselves, but 
instead have purchase order numbers that must be submitted to the 
monolitic service in order to manipulate the acutal purchase order. A 
properly factored service would give each logical object a first-class 
URI address.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2982
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-12-03 18:28:09
Subject:Re: Another REST vs. SOAP article
Message:

Paul Prescod wrote:
> > >Is anyone brave enough to stand up for monolithic services?
> > >;) Even as a devil's advocate?
> Monolithic means "not divided when 
> it should be." dictionary.com says: 
> "Constituting or acting as a single, 
> often rigid, uniform whole"
> 
> To me, a "monolithic interface" is a network-addressable object 
> that contains many "logical" objects which are not 
> directly addressable themselves. 
> e.g. purchase orders that do not have URIs themselves, 
> but instead have purchase order numbers that must be 
> submitted to the monolitic service in order to 
> manipulate the acutal purchase order. 
> A properly factored service would give each logical object 
> a first-class URI address.

Ok, I will attempt a very limited defense of the bad monolithic 
design from the viewpoints of:
(a) incremental evolution and
(b) paranoia.

Note:  this is a very limited defense of EDI-mailbox-style
SOAP, not RPC-style SOAP.

(a) Incremental evolution:  we already have everything in place to do 
EDI-mailbox-style interactions, in fact, we do EDI.
So now we will do Web-EDI using pretty much all the same internal 
mechanisms, including the exact same integration with our internal 
business apps.

(b) Paranoia:  You want me to do what? 
Give Web URIs to all my valuable business deal info?
Are you out of your mind?
Did you see (latest cracker scare story...)?

(Remember that I am personally trying to evolve from EDI-mailbox-
style ebXML to REST...)

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2983
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-12-03 18:54:45
Subject:RE: [rest-discuss] Another REST vs. SOAP article
Message:


> -----Original Message-----
> From: Paul Prescod [mailto:paul@...]
> Sent: Tuesday, December 03, 2002 12:43 PM
> To: Mathews, Walden
> Cc: Toivo "Deutsch" Lainevool; rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Another REST vs. SOAP article
> 
> 
> Mathews, Walden wrote:
> 
> > >Is anyone brave enough to stand up for monolithic services?
> > >;) Even as a
> > >devil's advocate?
> > >
> > >  Paul Prescod
> >
> >
> > Not sure what you mean by 'monolithic' in this setting.  I usually
> > think of it as meaning indivisible.  Is there such a thing as a
> > monolithic interface?  I'm afraid I'm not visualizing this very
> > well.
> 
> I think of "atomic" as individible. Monolithic means "not 
> divided when 
> it should be." dictionary.com says: "Constituting or acting 
> as a single, 
> often rigid, uniform whole"
> 
> To me, a "monolithic interface" is a network-addressable object that 
> contains many "logical" objects which are not directly addressable 
> themselves. e.g. purchase orders that do not have URIs 
> themselves, but 
> instead have purchase order numbers that must be submitted to the 
> monolitic service in order to manipulate the acutal purchase order. A 
> properly factored service would give each logical object a 
> first-class 
> URI address.
> 
>   Paul Prescod

Okay, in that case I'm not going to stand up for monolithic interfaces,
even as devil's advocate, but it's not a bravery issue.  Clean delegation
is a key design concept.  Now if only my boss understood that...

Walden
> 






-----------------------------------------------------------------------------------
Post ID:2984
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-03 21:21:01
Subject:Security vs. URIs
Message:

bhaugen32 wrote:

> (b) Paranoia:  You want me to do what?
> Give Web URIs to all my valuable business deal info?
> Are you out of your mind?
> Did you see (latest cracker scare story...)?
>
> (Remember that I am personally trying to evolve from EDI-mailbox-
> style ebXML to REST...)

I've heard that reaction many times, but it seems to me to reflect a 
misunderstanding. Data is either on the Internet or it isn't. If there 
is some configuration of message bits that will get the data, then you 
need to make sure your cracker can't send you those bits (i.e. use 
passwords). What does it matter whether you use a standardized 
addressing mechanism (URIs) versus a non-standard one? I've argued in 
the past (and would rather not do it again) that using a standarized 
mechanism is actually better because your infrastructure understands 
what is going on better and can provide more support (e.g. ACLs on 
resource types).

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:2985
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-03 22:28:39
Subject:Re: [rest-discuss] Security vs. URIs
Message:

----- Original Message -----
From: "Paul Prescod" <paul@...>

>
> > (b) Paranoia:  You want me to do what?
> > Give Web URIs to all my valuable business deal info?
> > Are you out of your mind?
> > Did you see (latest cracker scare story...)?
> >
> > (Remember that I am personally trying to evolve from EDI-mailbox-
> > style ebXML to REST...)
>
> I've heard that reaction many times, but it seems to me to reflect a
> misunderstanding. Data is either on the Internet or it isn't.

Security through obscurity is an illogical, but comfortable, reaction by
many people. And yes, it does stem from misunderstanding the issues. If
/they/ can't see how to get the information out (i.e. it needs programming),
then probably it can't get out. Wrongheaded, but nobody said people are
logical.






-----------------------------------------------------------------------------------
Post ID:2986
Sender:"bhaugen32" <bhaugen32@...>
Post Date/Time:2002-12-03 23:26:45
Subject:Re: Security vs. URIs
Message:

Paul Prescod wrote:
> bhaugen32 wrote:
> 
> > (b) Paranoia:  You want me to do what?
> > Give Web URIs to all my valuable business deal info?
> > Are you out of your mind?
> > Did you see (latest cracker scare story...)?
> >
> > (Remember that I am personally trying to evolve from EDI-mailbox-
> > style ebXML to REST...)
> 
> I've heard that reaction many times, but it seems to me 
> to reflect a misunderstanding. 

I agree.  I hope it's clear that I am relating defenses I hear, from 
an evolutionary-next-step viewpoint. I am not arguing for their 
engineering validity.

But I think those are two reasons why people who now do EDI (or think 
in terms of EDI) find EDI-mailbox-style Soap a more-convenient 
evolutionary next step than REST.  REST may seem like a scarey leap 
into the unknown.

> Data is either on the Internet or it isn't. If there 
> is some configuration of message bits that will get the data, then 
you 
> need to make sure your cracker can't send you those bits (i.e. use 
> passwords). What does it matter whether you use a standardized 
> addressing mechanism (URIs) versus a non-standard one? I've argued 
in 
> the past (and would rather not do it again) that using a 
standarized 
> mechanism is actually better because your infrastructure 
understands 
> what is going on better and can provide more support (e.g. ACLs on 
> resource types).

I agree.  But again, somebody who is now doing EDI will already have 
control mechanisms in place for EDI-style interaction, and so will 
feel like they are covered.  (Regardless of the actual strength of 
their coverage.)  And the standardized mechanisms for protecting Web 
resources may be new to them.

It's the best I could do to respond to your challenge.

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:2987
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-04 10:39:50
Subject:Re: [rest-discuss] Re: Security vs. URIs
Message:

bhaugen32 wrote:

> I agree.  I hope it's clear that I am relating defenses I hear, from
> an evolutionary-next-step viewpoint. I am not arguing for their
> engineering validity.

Yep, that's cler.

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2988
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-04 19:20:08
Subject:Re: [rest-discuss] REST based WS implementations
Message:

Donald Ball wrote:

> What other webapp infrastructures have people used for REST projects that
> turned out well or poorly?

I've used Quixote. It is quite REST-ful. You can have container objects 
that dispatch to other objects etc. I've also used .NET, which has very 
convenient XML parsing code (for XML with a schema).

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2989
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-05 01:43:51
Subject:OOP and object models
Message:

Mathews, Walden wrote:

> Terminology strikes again.  Object models and object oriented
> programming have separate lives, according to what I read.  Bill
> is talking about polymorphic method resolution, which is one
> feature of OO (the programming thing), while Paul's description
> of "identity, state and behavior" is the /sine qua non/ of the
> object model.


I've always seen polymorphism as being the core feature of the 
"behaviour" part of Identity, State, Behaviour. Objects carry around 
their behaviour. Structs, XML documents, RDF graphs and other "pure data 
structures" do not.

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:2990
Sender:"Mathews, Walden" <walden.mathews@...>
Post Date/Time:2002-12-05 02:35:19
Subject:RE: OOP and object models
Message:

 

-----Original Message-----
From: Paul Prescod
To: Mathews, Walden
Cc: Bill de hra; Toivo "Deutsch" Lainevool; rest-discuss@yahoogroups.com
Sent: 12/4/2002 8:43 PM
Subject: OOP and object models

Mathews, Walden wrote:

>> Terminology strikes again.  Object models and object oriented
> programming have separate lives, according to what I read.  Bill
> is talking about polymorphic method resolution, which is one
> feature of OO (the programming thing), while Paul's description
> of "identity, state and behavior" is the /sine qua non/ of the
> object model.


>I've always seen polymorphism as being the core feature of the 
"behaviour" part of Identity, State, Behaviour. Objects carry around 
their behaviour. Structs, XML documents, RDF graphs and other "pure data

structures" do not.

  Paul Prescod


Yes, I shouldn't have said "polymorphic", strictly speaking.  Jump
tables are about dispatching to some method in a code inheritance
hierarchy, and it's something we can ignore if we're mainly interested
in runtime behaviors and properties, a la software architectures.

Certainly the idea of different "shapes" lurking behind a single
abstract interface is a 'behavioral' concept, not a code reuse one.

Walden






-----------------------------------------------------------------------------------
Post ID:2991
Sender:=?ISO-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-12-05 18:47:57
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

Paul Prescod wrote:

Hi Paul,


 > When you use the "handle as first parameter hack", you now have 
to have
 > two addresses for each object. The address of the service 
(usually an
 > HTTP URI) and the "handle" which is really just another address. 
In my
 > opinion, this is not proper OOP programming.

You see, I don't think your opinion holds for all cases, only for
the web case.

Arguably hiding things can be 'proper' OOP, depending on whether we
want to use encapsulation to simplify an interface: see Hide
Delgate, Remove Middle Man [1], and Facade [2].

It's very probably the the case that common encapsulation patterns
and idioms used in OOP are inappropriate for Web programming (I have
no end of bother with the Front Controller, a Facade variant that is
popular for designing websites). But that's not what I'm hearing
from you.


 >It would be very rare to
 > see a Java interface like:
 >
 > class IndividualAccount{
 >     function debit(accountNumber, val);
 >     function credit(accountNumber, val);
 > }
 >
 > Because this makes it _impossible_ to pass a reference to an 
account as
 > a standard Java object reference.

If I can pass accountNumber as a value to a method, I must have got
it from somwhere, so I can make an Object for it:

     Integer accno = new Integer(accountNumber);
     ...

not impossible then, but pretty useless.

 >
 > class AccountManager{
 >     function getAccount(number);
 > }
 >
 > class Account{
 >     function debit(val);
 >     function credit(val);
 > }

But don't stop there! In REST it's much more like:

class AccountManager:
   def post(uri): ...
   def get(uri): ...

class Account:
   def post(uri): ...
   def get(uri): ..


Any number of OO folks will tell you they don't like coarse 
grained/uniform interfaces (or where method names are passed around 
as keys). The reasons I've been given are:

   1) it skirts around/tunnels through, the type system of the language.

   2) it makes the the resulting code unclear.

(note that these are to do with code comprehension and maintainance, 
rather than some technical bound on uniform interfaces).

The OO world values having non-standard interfaces. Then again, much 
OOP is done for the local (machine or administrative) case, where 
this view might make sense. It pays to remember that for many J2EE 
and .NET developers it will not always be clear that what works well 
for the local case won't work so well over the network - fine 
grained data transfer and latent returns being obvious examples.

So I'm very wary of saying without qualification that the REST style 
is *more* or *proper* OOP with respect to the services style (if 
indeed there is such a thing as the services style).

I suspect that the problem you have with the services style is that 
it constitutes a collection of antipatterns for distributed OOP. If 
so, let's document what the risks of that style are. Communicating 
to the OOP world through patterns/antipatterns is a great way to 
make the case for the REST style - with the added bonus the claims 
for REST will seem less grand.


 > Now the account is a first-class object which can be passed around
 > without reference to the query interface. i.e. it has identity, 
state
 > and behaviour.

I don't dispute this is important, but a large part of what is
supposed to be valuable about OO is encapsulation (particulary of
state that would otherwise be global). Not all objects want to be
exposed. Agian, why this needs to rethought for the web needs 
explaining.


 > This could
 > be done in a language or system with per-object access controls. 
Even in
 > such a system, it is not straightforward if you've hacked static 
methods
 > to _emulate_ instance objects in a manner that is opaque to your
 > infrastructure.

I didn't understand this bit. I think you're saying using globals to
manage state is a bad idea; if so I agree with you.


Bill de h�ra

[1] Refactoring, Martin Fowler
[2] Design Patterns, Gamma et al











-----------------------------------------------------------------------------------
Post ID:2992
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-06 01:21:04
Subject:REST article
Message:

I have a new article I wrote for Linux magazine designed for people who 
have never heard of REST. It shows the migration of a simple XML-RPC 
service to REST, demonstrating both the costs and benefits of the 
conversion.

  Paul







-----------------------------------------------------------------------------------
Post ID:2993
Sender:Jason Diamond <jason@...>
Post Date/Time:2002-12-06 02:50:55
Subject:Re: [rest-discuss] REST article
Message:

On Thu, 2002-12-05 at 17:21, Paul Prescod wrote:
> I have a new article I wrote for Linux magazine designed for people
> who 
> have never heard of REST. It shows the migration of a simple XML-RPC 
> service to REST, demonstrating both the costs and benefits of the 
> conversion.

Does the article have a URI?

Jason








-----------------------------------------------------------------------------------
Post ID:2994
Sender:"Roy T. Fielding" <fielding@...>
Post Date/Time:2002-12-06 02:12:35
Subject:Re: [rest-discuss] Another REST vs. SOAP article
Message:

> I suspect that the problem you have with the services style is that
> it constitutes a collection of antipatterns for distributed OOP. If
> so, let's document what the risks of that style are.

Ick, terminology is being misused.  OOP is a programming structure
paradigm dependent on such things as classes and inheritance.  There
is no such thing as distributed OOP.  Object-based systems is what you
get when you take OOD and distribute the objects.  It is called
object-based (instead of object-oriented) because we are talking
about architecture, rather than source code structure, and architecture
doesn't have classes and inheritance.

> Communicating
> to the OOP world through patterns/antipatterns is a great way to
> make the case for the REST style - with the added bonus the claims
> for REST will seem less grand.

That is difficult to do.  The OOPSLA community took the architectural
concept of patterns and expanded it into anything with a recipe for
implementation.  I use the original notion of patterns, which came
from Alexander watching human behavior as people live/work/move within
a space.  The closest analogy in computing is how data moves within an
architecture.  In other words, I do explain REST as a pattern, but
what people call patterns now is tuned more for programming idioms
rather than understanding system behavior.

Architectural styles and architectural patterns are fairly consistent,
but as you noted the purpose of REST is to force the developer into a
less object-specific architecture, which is contrary to most of the
OOD patterns.  Whether that is good or bad depends on what is
being implemented.


Cheers,

Roy T. Fielding, Chief Scientist, Day Software
                  2 Corporate Plaza, Suite 150
                  Newport Beach, CA 92660-7929   fax:+1.949.644.5064
                  (roy.fielding@...) <http://www.day.com/>

                  Co-founder, The Apache Software Foundation
                  (fielding@...)  <http://www.apache.org/>








-----------------------------------------------------------------------------------
Post ID:2995
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-06 17:19:33
Subject:Re: [rest-discuss] REST article
Message:

Sorry. I meant to add: "email me to get it". I've done that a few times 
before on the list so it is implied for some old-timers.


Jason Diamond wrote:

> On Thu, 2002-12-05 at 17:21, Paul Prescod wrote:
>
> >I have a new article I wrote for Linux magazine designed for people
> >who
> >have never heard of REST. It shows the migration of a simple XML-RPC
> >service to REST, demonstrating both the costs and benefits of the
> >conversion.
>
>
> Does the article have a URI?
>
> Jason
>
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>








-----------------------------------------------------------------------------------
Post ID:2996
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-12-10 04:33:57
Subject:POST Intent
Message:

Hi,

How to specify the intent of a POST? I believe Mark Baker has covered this
topic in the past, but what was the conclusion?

Michael







-----------------------------------------------------------------------------------
Post ID:2997
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-10 13:24:48
Subject:Re: [rest-discuss] POST Intent
Message:

On Tue, Dec 10, 2002 at 03:33:57PM +1100, Michael Day wrote:
> 
> Hi,
> 
> How to specify the intent of a POST? I believe Mark Baker has covered this
> topic in the past, but what was the conclusion?

The only attempts I know of anybody trying to standardize on this, are
with the "PEP" header in PEP, the SOAPAction header in SOAP 1.1, and the
"action" media type attribute in SOAP 1.2.

It pretty much needs a mandatory extension framework, which is why you
can't just run out and define an HTTP header to do this.  You could use
RFC 2774 I suppose, but nobody implements that AFAIK.

It's a shame that the only practical way to do this today is with SOAP,
which brings in a lot of other baggage, doesn't have a PUT binding,
etc..

I assume Waka will handle this no problem.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:2998
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-10 20:46:42
Subject:An interview with .. me!
Message:

I didn't realize I was going to be quoted verbatim (well, until
later in the process), but here ya go;

http://webservices.devchannel.org/article.pl?sid=02/12/10/1849249

Though not a very good way to win friends and influence people, I
especially like my description of how we got to where we are today;

  So in a "if you pat my back, I'll pat yours" self-congratulatory
  frenzy, we arrived where we are today; lots of agreement on the core
  specs, yet very few services on the Internet."

8-)

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:2999
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-12-10 22:27:49
Subject:Off-topic: MySQL or PostgreSQL?
Message:

Given the broad experience around these parts, any thoughts?

jb







-----------------------------------------------------------------------------------
Post ID:3000
Sender:"Yannick Loiseau" <yloiseau@...>
Post Date/Time:2002-12-11 07:23:23
Subject:dynamic forms
Message:

Hi all,
Here is a little (may be stupid) question:
I've got a uri to a container.
a GET return the contain of the container, and a POST (in a form-encoded
format) add an element to the container.
I'd like to generate a "dynamic form" to POST data, in a Jabber-query like
maner. Indeed, in the jabber framework, an empty query return a description
of the fields to feel to submit the query, allowing clients to create
submission forms without knowing anything about the ressource.
In a Rest env, does it make sens to answer to an empty post in such a maner,
e.g. with an XForm doc, or is it better to use an other uri, to which POST
add element and GET return the XForm ?
I think the first solution is the most suitable, but in this case, which
status/header should be return ?
is 400 Bad Request  ok ?







-----------------------------------------------------------------------------------
Post ID:3001
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-12-11 10:01:32
Subject:Re: [rest-discuss] Off-topic: MySQL or PostgreSQL?
Message:

Jeff Bone wrote:
> Given the broad experience around these parts, any thoughts?

i suggest that you read the recent (nov. 30) slashdot thread arising
from the release of postgresql 7.3.  it has lots of postgresql vs mysql
threads, and some of them have interesting observations.

http://slashdot.org/article.pl?sid=02/11/30/1815200

from my POV postgresql is the more capable database, but IMO its website
and online documentation is really really bad (vis-a-vis mysql's, that
is).  i've never before seen such a great product with such a terrible
online 'image'.  the mailing lists aren't archived that well either.  i
should probably do something about these points rather than whine about
them, but i have seen these points voiced elsewhere, and this is what i
believe to be the current situation.

HTH,
-vincent







-----------------------------------------------------------------------------------
Post ID:3002
Sender:DJ Adams <dj.adams@...>
Post Date/Time:2002-12-11 11:47:45
Subject:Re: [rest-discuss] An interview with .. me!
Message:

On Tue, Dec 10, 2002 at 03:46:42PM -0500, Mark Baker wrote:
> I didn't realize I was going to be quoted verbatim (well, until
> later in the process), but here ya go;
> 
> http://webservices.devchannel.org/article.pl?sid=02/12/10/1849249

qq{
"Decentralization" is actually the opposite side of the same coin as "low coordination costs." The need for registries with Web Services is a sure sign that you're not decentralized.
}

I'm curious about this. Registries are not required for Web Services but are
useful. But the same could surely be said for RESTian services too?

Am I misunderstanding something?

dj
http://www.pipetree.com/qmacro






-----------------------------------------------------------------------------------
Post ID:3003
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-11 10:50:39
Subject:Re: [rest-discuss] An interview with .. me!
Message:

What does this mean:

"Web Services don't scale past *one* trust boundary, for the same reason 
above, visibility; they're an Intranet-only solution."

Do you dispute the existence of the Google, Amazon and Blogger RPC APIs? 
I am totally in your corner that Web services don't scale in the sense 
that the web does (they are a collection of disjoint information 
systems, rather than a single information system) but it seems to me 
that you are overstating the case.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:3004
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-11 10:51:40
Subject:REST tidbits from XML 2002
Message:

  1. Tim Bray gave a very positive Plenary talk on REST and Web 
Architecture. He didn't slam RPC-based Web Services (as he did when he 
spoke to our more intimate group in Vancouver) but nevertheless he was 
clearly pro-REST. His only references to other ways of doing things were 
oblique: "Some people do not give things URIs. This means that those 
things are not on the Web. That should be self-evidently a bad thing."

  2. I spoke with Jeff Barr from Amazon. He says their REST interface is 
  popular (no numbers) and some people have found ways to do things with 
it that are literally not possible with the SOAP interface. You can make 
an HTTP hyperlink to an Amazon XML page parameterized with an XSLT 
stylesheet. Amazon runs the stylesheet on the server side. This means 
that with nothing more than an HTML document and a stylesheet on 
geocities (no CGI!), you can generate a pretty sophisticated web storefront.

People who think that REST and other ways of doing things are mostly the 
same because you can make them look the same with glue code totally miss 
the fact that there environments where there is _nowhere to put the glue 
code_. The continued rise of XML and XSLT makes REST more and more of a 
"no-brainer" and vice versa.

That was also a theme of Tim's talk...that XML was the cure for many of 
the Web's weak points (machine to machine communication, 
internationalization, metadata, ...)

Considering where we were a year ago, REST's current status is actually 
amazing considering the subtlety of the ideas.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:3005
Sender:=?ISO-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-12-11 10:51:59
Subject:Re: [rest-discuss] Off-topic: MySQL or PostgreSQL?
Message:

Jeff Bone wrote:
> Given the broad experience around these parts, any thoughts?

Whay Vincent said, also it depends out what you're doing. If you're 
just serving up content, or basically looking for a file system + 
indexing you can speak SQL with,  mySQL is probably a good bet - and 
it's fast. PostgresSQL comes into its own when you need transactions 
or ACID capabilities.

Bill de h�ra







-----------------------------------------------------------------------------------
Post ID:3006
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-12-11 11:36:52
Subject:Re: [rest-discuss] REST tidbits from XML 2002
Message:

Paul Prescod wrote,
> People who think that REST and other ways of doing things are mostly
> the same because you can make them look the same with glue code
> totally miss the fact that there environments where there is _nowhere
> to put the glue code_.

Umm ... well, XSLT is code and it's executed at the client (presumably 
Amazon don't apply the stylesheet serverside).

I'm not sure I can see what's new here (not that being new matters all 
that much).

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:3007
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-11 11:53:30
Subject:Scaling and trust boundaries
Message:

On Wed, Dec 11, 2002 at 05:50:39AM -0500, Paul Prescod wrote:
> What does this mean:
> 
> "Web Services don't scale past *one* trust boundary, for the same reason 
> above, visibility; they're an Intranet-only solution."
> 
> Do you dispute the existence of the Google, Amazon and Blogger RPC APIs? 
> I am totally in your corner that Web services don't scale in the sense 
> that the web does (they are a collection of disjoint information 
> systems, rather than a single information system) but it seems to me 
> that you are overstating the case.

That RPC based services like Google exist, doesn't mean they scale.
HTTP gets past firewalls because it's trusted and visible; its "API" was
rigorously reviewed in the IETF process.  Google's API wasn't, and isn't
known to be secure, so other organizations exposing or using search
services will be wary of using/reusing that API.

The scaling problem is that it's prohibitively expensive to review every
single API that might be created.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3008
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-11 12:51:59
Subject:Re: [rest-discuss] An interview with .. me!
Message:

On Wed, Dec 11, 2002 at 11:47:45AM +0000, DJ Adams wrote:
> qq{
> "Decentralization" is actually the opposite side of the same coin as "low coordination costs." The need for registries with Web Services is a sure sign that you're not decentralized.
> }
> 
> I'm curious about this. Registries are not required for Web Services but are
> useful. But the same could surely be said for RESTian services too?
> 
> Am I misunderstanding something?

Well, there's registries, and then there's registries.  Unfortunately
I was asked to be brief, so I couldn't elaborate much in the interview.

I'm referring to the "link database" form of registry, where to even
create a service requires registration, rather than registries for
things like media types which are just trusted identifiers published by
an authority to demonstrate that it meets some minimum level of quality
(e.g. text/html vs. text/x-foofoo).

FWIW, the prevalence of WSDL-over-GET, despite the push for UDDI, shows
how strong the forces of decentralization can be.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3009
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-11 15:27:46
Subject:Re: Scaling and trust boundaries
Message:

Mark Baker wrote:

> That RPC based services like Google exist, doesn't mean they scale.
> HTTP gets past firewalls because it's trusted and visible; its "API" was
> rigorously reviewed in the IETF process.  Google's API wasn't, and isn't
> known to be secure, so other organizations exposing or using search
> services will be wary of using/reusing that API.
>
> The scaling problem is that it's prohibitively expensive to review every
> single API that might be created.

The Web Services industry _is_ amazingly poor at reusing service 
interfaces. It is even worse than the XML industry (which tends to have 
five schemas for every problem). I'm not sure I completely buy your 
argument about the source of the problem but I do observe the problem..

BTW, my last message probably came across the wrong way. I had one nit 
(or probably misunderstanding) but overall I loved the article!

  Paul







-----------------------------------------------------------------------------------
Post ID:3010
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-11 15:29:08
Subject:Re: [rest-discuss] REST tidbits from XML 2002
Message:

Miles Sabin wrote:

> Paul Prescod wrote,
>
> >People who think that REST and other ways of doing things are mostly
> >the same because you can make them look the same with glue code
> >totally miss the fact that there environments where there is _nowhere
> >to put the glue code_.
>
>
> Umm ... well, XSLT is code and it's executed at the client (presumably
> Amazon don't apply the stylesheet serverside).
>
> I'm not sure I can see what's new here (not that being new matters all
> that much).

Yes, Amazon does apply the stylesheet on the server side. I was 
surprised that they would commit those computational resources but it 
seems to work.

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:3011
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-12-11 15:37:43
Subject:Re: [rest-discuss] REST tidbits from XML 2002
Message:

Paul Prescod wrote,
> Yes, Amazon does apply the stylesheet on the server side. I was
> surprised that they would commit those computational resources but it
> seems to work.

Wow! That's brave ...

Still, that doesn't affect my point, such as it was: there's code, and 
there's somewhere for it to go.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:3012
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-12-11 17:21:15
Subject:WSDL and REST
Message:

How well suited is WSDL in it's current form for describing REST-style
services?

Is it necessary at all, or could the OPTION method be used to return a valid
schema describing the data that could be accepted at that URI?










-----------------------------------------------------------------------------------
Post ID:3013
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-11 17:29:22
Subject:Re: [rest-discuss] dynamic forms
Message:

On Wed, Dec 11, 2002 at 08:23:23AM +0100, Yannick Loiseau wrote:
> Hi all,
> Here is a little (may be stupid) question:
> I've got a uri to a container.
> a GET return the contain of the container, and a POST (in a form-encoded

Presumably you mean "contents of the container"?

> format) add an element to the container.
> I'd like to generate a "dynamic form" to POST data, in a Jabber-query like
> maner.

You could put it in the list of things that are returned, or perhaps
link to a form from what's returned on a GET to the container.

> Indeed, in the jabber framework, an empty query return a description
> of the fields to feel to submit the query, allowing clients to create
> submission forms without knowing anything about the ressource.
> In a Rest env, does it make sens to answer to an empty post in such a maner,
> e.g. with an XForm doc, or is it better to use an other uri, to which POST
> add element and GET return the XForm ?

I'd say the latter.  The former is a private agreement between client
and server, plus it seems a safe operation to me so should use GET
anyhow.

... if I understood you correctly.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3014
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-12-11 18:57:46
Subject:Re: [rest-discuss] dynamic forms
Message:

Yannick Loiseau wrote:
> I'd like to generate a "dynamic form" to POST data, in a Jabber-query like
> maner. Indeed, in the jabber framework, an empty query return a description
> of the fields to feel to submit the query, allowing clients to create
> submission forms without knowing anything about the ressource.

i don't know much about jabber, but maybe this will be of some use to
you anyway.

i have a URI for the form.  if we were talking about bank accounts, the
URI would be
/accounts/form/

to get the form i do a GET on this URI.  the target of the returned form
representation is the container URI.

i also have people editing a single resource which is not a container
using something that looks like
/accounts/1234/form/

you could say these forms are 'sub-resources' of the 'accounts' or
'account' resource.  i don't know whether that makes much sense; this
was just a good (enough) way for me to load already-populated forms.

> I think the first solution is the most suitable, but in this case, which
> status/header should be return ?
> is 400 Bad Request  ok ?

i'm not sure what case you're referring to here so i'll try cover every
angle i am aware of.

in my system the POST response would be a "201 Created", the GET is just
a normal "200 OK".  as for input which is lexically or semantically
invalid, i just use "400 Bad Request", but only because i'm not sure
whether there is something more specific i should be using.  i wonder
whether it should be 4xx Bad *Representation* (because it's not like
there's something wrong with the HTTP headers or anything) but i digress.

HTH,
-vincent







-----------------------------------------------------------------------------------
Post ID:3015
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-11 17:19:54
Subject:Re: [rest-discuss] REST tidbits from XML 2002
Message:

----- Original Message -----
From: "Miles Sabin" <miles@...>
>
> Umm ... well, XSLT is code and it's executed at the client (presumably
> Amazon don't apply the stylesheet serverside).
>
Actually, I'm pretty sure they do apply it on Amazon's servers. I wonder if
they allow extension functions...






-----------------------------------------------------------------------------------
Post ID:3016
Sender:"Yannick Loiseau" <yloiseau@...>
Post Date/Time:2002-12-11 19:47:36
Subject:Re: [rest-discuss] dynamic forms
Message:

> > a GET return the contain of the container, and a POST (in a form-encoded
> Presumably you mean "contents of the container"?

yes... sorry for my english

> You could put it in the list of things that are returned, or perhaps
> link to a form from what's returned on a GET to the container.
[...]
> it seems a safe operation to me so should use GET
> anyhow.

but the GET is supposed to return the contents, and not the form, and using
an other uri to GET the form or POST the data to is less meaningful than
posting to the container uri (if I have well understood the semantic of
POST)...








-----------------------------------------------------------------------------------
Post ID:3017
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-11 20:16:23
Subject:Re: [rest-discuss] dynamic forms
Message:

----- Original Message -----
From: "Yannick Loiseau" <yloiseau@...>

> > You could put it in the list of things that are returned, or perhaps
> > link to a form from what's returned on a GET to the container.
> [...]
> > it seems a safe operation to me so should use GET
> > anyhow.
>
> but the GET is supposed to return the contents, and not the form, and
using
> an other uri to GET the form or POST the data to is less meaningful than
> posting to the container uri (if I have well understood the semantic of
> POST)...

With HTTP, you either provide a blended view of data and acceptable
operations (the form) or you have different resources for the data and the
form. The form can still reference the container as the target of the POST
though.
You could also use different content-type representations of the container
resource (the client uses the Accept header) one for the data and one for
the description of how to interact with it.

If the form is retrievable separately from the data, there are different
ways to reference between the two:
 - a response header that identifies the resource that describes the
acceptable interactions for that resource
 - a separate resource that identifies the data resource and the
input/schema resources, there may be more than one acceptable input to the
same resource. For example:

<manufacturer>
 <products>
  <product type='shoes'
    resource-location='http://shoesRus.com/shoes/'
    service-description='http://shoesRus.com/shoes/services''>
 </products>
</manufacturer>

I like the approach of mixing the data and the accepatable interactions -
kind of how HTML did it.






-----------------------------------------------------------------------------------
Post ID:3018
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-11 20:59:32
Subject:Re: [rest-discuss] dynamic forms
Message:

On Wed, Dec 11, 2002 at 08:47:36PM +0100, Yannick Loiseau wrote:
> but the GET is supposed to return the contents, and not the form,

Well, if your data format supports it, you could do both.  If you're
defining the format, you should consider including a "meta", "header",
or similar section where stuff like this can be communicated.

> and using
> an other uri to GET the form or POST the data to is less meaningful than
> posting to the container uri (if I have well understood the semantic of
> POST)...

Ideally, sure, but it's not etched in stone.  It depends on the flow of
your application.  Most web apps don't support GET on the resource they
POST to, but the application steered the client to that first URI, so all
is well.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3019
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-12 08:16:04
Subject:REST makes a Press Release...
Message:

I hadn't seen this before - kudos to Alex Klevitsky.

===
http://www.e-servicescorp.com/html/REST_Technology_PR.html

MIB Deploys REST Technology for XML Web Service

(WESTWOOD, MA. October 17, 2002) - MIB Group, Inc. announced today the
availability of a set of Web services that extend in-house IT business
solutions to clients by providing software functionality directly via the
Web versus a standalone application.  Included are MIB's Security Alert
Entity Look-up Utility and Security Alert ID Look-up Utility, both research
companions to MIB's Security Alert Services (SAS) compliance solution for
the USA PATRIOT Act (OFAC) and OSFI Canadian regulations.  These Web
services retrieve all available information on specific "denied parties"
directly from the OFAC or OSFI web sites, on a manual or fully integrated
basis.

MIB Web services use an architectural style called REST (Representational
State Transfer) that employs standard Internet technologies (XML, URI and
HTTP) to provide quick, simple integration with a customers' existing
business systems.  Accessing MIB's Web services is easy, and users have the
option of receiving formatted HTML or native XML.  The Web services also
ensures that users of MIB's Security Alert Services compliance reports are
seeing the most up-to-date information available from both OFAC and OSFI.

"We evaluated all available Web service architectural solutions and found
that URI-centric REST is simple, elegant and based entirely on HTTP. Our
customers will enjoy the ease of getting XML output from this service by
using conventional URLs and by sending HTTP requests to the specified MIB
Web address," states Alex Klevitsky, MIB's Enterprise Systems Architect.

"MIB Web services characterizes a company-wide effort towards a
service-oriented architecture, providing a universal integration platform
for MIB clientele. This is an important move forward in the next generation
Internet delivering tighter business relationships and more efficient
business processes," says Robert L. DiAngelo, MIB's Chief Information
Officer.

Both Klevitsky and DiAngelo see Web services based on REST, along with its
Simple Object Access Protocol (SOAP) counterpart, playing major roles as MIB
continues to reengineer core business systems and deploy new functionality
to clients.


 About MIB Group, Inc.

MIB Group, Inc., headquartered in Westwood, Massachusetts, is the premier
provider of Internet-based information and knowledge services to the global
risk management market space, and is a leading facilitator of electronic
insurance commerce via dedicated networks and Internet-based systems. MIB
member companies underwrite more than 95 percent of the premium dollars of
individual life insurance written in the United States and Canada. More
information about MIB Group, Inc. is available at  www.mib.com.








-----------------------------------------------------------------------------------
Post ID:3020
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-12 12:08:18
Subject:Re: [rest-discuss] REST tidbits from XML 2002
Message:

Miles Sabin wrote:

> Paul Prescod wrote,
>
> >Yes, Amazon does apply the stylesheet on the server side. I was
> >surprised that they would commit those computational resources but it
> >seems to work.
>
>
> Wow! That's brave ...
>
> Still, that doesn't affect my point, such as it was: there's code, and
> there's somewhere for it to go.

At some high enough level of abstraction that may be a meaningful thing 
to say, but at the coding level there is a big difference between XSLT 
and "ordinary code". For one thing, XSLT was designed specifically to 
work with XML input, output and the flat namespace model used in REST 
web services. No other language has that characteristic.

Let's turn the question around. If there is really no difference between 
their REST and SOAP versions of the Web Service then why do you think 
that the REST one has this feature while the SOAP one does not? How 
would you even propose to implement a similar feature for a SOAP RPC 
interface? "Upload Javascript using a SOAP library and we'll run it on 
our server?" That seems quite unlikely, inefficient, hard to secure and 
generally ugly.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:3021
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-12 12:42:49
Subject:Re: [rest-discuss] WSDL and REST
Message:

Jeffrey Winter wrote:

> How well suited is WSDL in it's current form for describing REST-style
> services?

Not very:

http://www.blogstream.com/pauls/1032521623/index_html
http://www.prescod.net/rest/wsdlhttp.html

> Is it necessary at all, or could the OPTION method be used to return a 
> valid schema describing the data that could be accepted at that URI?

Interesting idea...a HEAD-retrieved header could also be used.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:3022
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-12-12 12:57:33
Subject:Re: [rest-discuss] REST tidbits from XML 2002
Message:

Paul Prescod wrote,
> Let's turn the question around. If there is really no difference
> between their REST and SOAP versions of the Web Service

I didn't mean to imply that there was no difference between the two 
versions. I was merely commenting on your comment,

> People who think that REST and other ways of doing things are mostly
> the same because you can make them look the same with glue code
> totally miss the fact that there environments where there is _nowhere
> to put the glue code_.

which I read as a claim that REST could do exciting things without 
needing glue code or anywhere to put it. My quibble was that the XSLT 
was the code, and (as it turns out) Amazon provide an execution 
environment for it. As I said, not all that much of a quibble ... just 
a reminder that whatever the merits of REST, it can't do magic.

As it happens, with an "XSLT execution environment provider" you 
probably could do something very similar with the SOAP service without 
a great deal of difference in the complexity or overhead either on the 
client or the server. But that's a different can'o'worms.

Hmm ... mobile XSLT, the new Java? ;-)

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:3023
Sender:Duncan Cragg <rest@...>
Post Date/Time:2002-12-12 16:47:26
Subject:Waka
Message:

  Has anyone heard any more about Fielding's Waka?

I'd be interested in an up-to-date link, or anything comparing it to 
WebDAV and HTTPEvents.

RFC yet?


Duncan Cragg.









-----------------------------------------------------------------------------------
Post ID:3024
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-12 17:33:51
Subject:Re: [rest-discuss] Waka
Message:

The most up to date info Roy's presented is here;

http://www.apache.org/~fielding/waka/

The presentation there has a lot of good stuff in it.  Maybe at next
year's ApacheCon, he'll have a demo. 8-)

MB

On Thu, Dec 12, 2002 at 04:47:26PM +0000, Duncan Cragg wrote:
>   Has anyone heard any more about Fielding's Waka?
> 
> I'd be interested in an up-to-date link, or anything comparing it to 
> WebDAV and HTTPEvents.
> 
> RFC yet?
> 
> 
> Duncan Cragg.
> 
> 
> 
> 
> 
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3025
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-12-12 19:15:52
Subject:RE: [rest-discuss] REST tidbits from XML 2002
Message:

I talked to Amazon folks about this when they first came out with the
service. They support doing XSLT on the server (to my amazement -- it opens
up a whole can of worms I don't think they considered). No support for
installing extension functions on their servers, but with the document()
function, you can call external services via http requests.

I know, it's not the same, but then what do you want for free... (:-)

Ramin
  -----Original Message-----
  From: S. Mike Dierken [mailto:mdierken@...]
  Sent: Wednesday, December 11, 2002 9:20 AM
  To: rest-discuss
  Subject: Re: [rest-discuss] REST tidbits from XML 2002



  ----- Original Message -----
  From: "Miles Sabin" <miles@...>
  >
  > Umm ... well, XSLT is code and it's executed at the client (presumably
  > Amazon don't apply the stylesheet serverside).
  >
  Actually, I'm pretty sure they do apply it on Amazon's servers. I wonder
if
  they allow extension functions...

  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.






-----------------------------------------------------------------------------------
Post ID:3026
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-12-12 19:28:51
Subject:Re: [rest-discuss] REST tidbits from XML 2002
Message:

Ramin Firoozye wrote,
> I talked to Amazon folks about this when they first came out with the
> service. They support doing XSLT on the server (to my amazement -- it
> opens up a whole can of worms I don't think they considered). No
> support for installing extension functions on their servers, but with
> the document() function, you can call external services via http
> requests.

They allow arbitrary user-supplied stylesheets to make arbitrary 
outgoing HTTP requests from their servers???!!!!

Wow! That's an accident waiting to happen ... who needs a bunch of IRC 
zombies when you can hijack Amazons boxes for a DDoS.

Paul, I suggest that until they fix it you _don't_ flag it up as an 
exemplar. Do you have a contact at Amazon?

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:3027
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-12 19:40:51
Subject:Re: [rest-discuss] REST tidbits from XML 2002
Message:

----- Original Message -----
From: "Miles Sabin" <miles@...>

> They allow arbitrary user-supplied stylesheets to make arbitrary
> outgoing HTTP requests from their servers???!!!!
Only GETs, but that is sufficient to cause a lot of trouble.
I think you have to be an affiliate or some other semi-trusted entity to get
in though.






-----------------------------------------------------------------------------------
Post ID:3028
Sender:"Ramin Firoozye" <ramin@...>
Post Date/Time:2002-12-12 20:07:39
Subject:RE: [rest-discuss] REST tidbits from XML 2002
Message:

That's true. If you do a bunch of 100MB XML transfers via document(),
sooner or later I imagine they'll yank your associate ID.

Still, pretty gutsy of them to leave it open...

Ramin
  -----Original Message-----
  From: S. Mike Dierken [mailto:mdierken@...]
  Sent: Thursday, December 12, 2002 11:41 AM
  To: rest-discuss
  Subject: Re: [rest-discuss] REST tidbits from XML 2002



  ----- Original Message -----
  From: "Miles Sabin" <miles@...>

  > They allow arbitrary user-supplied stylesheets to make arbitrary
  > outgoing HTTP requests from their servers???!!!!
  Only GETs, but that is sufficient to cause a lot of trouble.
  I think you have to be an affiliate or some other semi-trusted entity to
get
  in though.

  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.






-----------------------------------------------------------------------------------
Post ID:3029
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-12-12 20:41:17
Subject:Re: [rest-discuss] Waka
Message:

Great to see the enthusiasm building around this; when I mentioned it
in this forum a few weeks ago, it got panned as "oh that; it's been
around for a while".  Is this a sign of something real, then?

Walden

PS - just to let you all know that I'm jobless since last Friday, and
employment leads are appreciated.


----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "Duncan Cragg" <rest@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Thursday, December 12, 2002 12:33 PM
Subject: Re: [rest-discuss] Waka


> The most up to date info Roy's presented is here;
>
> http://www.apache.org/~fielding/waka/
>
> The presentation there has a lot of good stuff in it.  Maybe at next
> year's ApacheCon, he'll have a demo. 8-)
>
> MB
>
> On Thu, Dec 12, 2002 at 04:47:26PM +0000, Duncan Cragg wrote:
> >   Has anyone heard any more about Fielding's Waka?
> >
> > I'd be interested in an up-to-date link, or anything comparing it to
> > WebDAV and HTTPEvents.
> >
> > RFC yet?
> >
> >
> > Duncan Cragg.
> >
> >
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
>
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>








-----------------------------------------------------------------------------------
Post ID:3030
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-12 20:58:37
Subject:Re: [rest-discuss] Waka
Message:

On Thu, Dec 12, 2002 at 03:41:17PM -0500, Walden Mathews wrote:
> Great to see the enthusiasm building around this; when I mentioned it
> in this forum a few weeks ago, it got panned as "oh that; it's been
> around for a while".  Is this a sign of something real, then?

Just because Roy's been talking about it for a while, doesn't mean I
wasn't excited about it.  He just hadn't said much about it until this
most recent ApacheCon.

Yah, I think it sounds really good.  The better self-describing nature
of the messages should make for interesting uses, especially in
routing, as it will be obvious what a representation on-the-wire
will be for.  Currently, the difference between a POST response and a
GET response requires context from the connection on which the request
was made.  Decoupling that further will be nice, though, like I said
before, implementation complexity could get nasty.

> Walden
> 
> PS - just to let you all know that I'm jobless since last Friday, and
> employment leads are appreciated.

Sorry to hear that, Walden. 8-(

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3031
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-12-12 22:51:06
Subject:Re: [rest-discuss] dynamic forms
Message:

> I like the approach of mixing the data and the accepatable interactions -
> kind of how HTML did it.

Me too.  I like implicit resources like "room schedule" from the little
conference room application I was prototyping with when the axe fell,
in which a GET on /rooms/demo/schedule defaults to the current week's
schedule in the demo room, but its representation includes links to the next
week's schedule, the previous week's schedule, and also includes a form
for sending up the date spec for the week(s) schedule you're actually after,
in case it's not proximal.  I think this is consisten with the idea of
"here's
some information now, and there's more available", i.e., the perceived
latency of the application is low as long as relevant info and links are
being sent back, and that info helps the client decide what to do next.

Comments?








-----------------------------------------------------------------------------------
Post ID:3032
Sender:"tappnel <app@...>" <app@...>
Post Date/Time:2002-12-13 01:38:00
Subject:Re: RESTLog
Message:

(decloaking)

With the recent unveiling of the Blogger 2 API there has been a great
deal of discussion regarding its shortcomings and best route going
forward. We're all aware of the issues of XML-RPC based interfaces --
it was just discussed a few weeks ago.

It seems if ever there was a tool/medium that needed a RESTful API
it's weblogging.

Joe Gregorio has been developing a prototype with such an API and made
this post for feedback. (My response never made it to the list however
I did make a weblog post.[1]) It's been nearly a month since this
post
was made and now seems like an appropriate time to raise it again.

Joe and I have been continuing to discuss the notion in private
emails. Rather then debate amongst ourselves, Joe and I opened a
mailing list for a community discussion of web service interfaces
using REST for enabling collaborative authoring and content tools
based. Some examples of existing initiatives that would be an
appropriate topic for discussion include (but are not limited to)
RESTLog, Extremely Simple Syndication (XSS) format and TrackBack. All
are welcome and encouraged to join the discussion.

http://groups.yahoo.com/group/ucapi-discuss/

<tim/>

[1] http://www.mplode.com/tima/archives/000153.html


--- In rest-discuss@yahoogroups.com, Joe Gregorio <joe@b...> wrote:
> I am working on a REST based weblog interface, described here:
> 
>     http://wellformedweb.org/RESTLog.cgi/5
> 
> the design of which is heavily influenced by:
> 
>     http://internet.conveyor.com/RESTwiki/moin.cgi/RestifyingBlogger
> 
> Before I get too far along I want to make 
> sure I haven't wandered off into the weeds.
> Any feedback would be greatly appreciated.
> 
> 	Thanks,
> 	-joe
> 
> -- 
> http://BitWorking.org
> http://WellFormedWeb.org







-----------------------------------------------------------------------------------
Post ID:3033
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-12 20:20:01
Subject:Re: [rest-discuss] REST tidbits from XML 2002
Message:

Miles Sabin wrote:

 >
 >
 > >People who think that REST and other ways of doing things are mostly
 > >the same because you can make them look the same with glue code
 > >totally miss the fact that there environments where there is _nowhere
 > >to put the glue code_.
 >
 >
 > which I read as a claim that REST could do exciting things without
 > needing glue code or anywhere to put it.

REST can do exciting things without needing glue code or anywhere to put
it. I can extract an integer data element out of an Amazon REST resource
without a single line of code (unless you count an XPointer as "code").

 > As it happens, with an "XSLT execution environment provider" you
 > probably could do something very similar with the SOAP service without
 > a great deal of difference in the complexity or overhead either on the
 > client or the server. But that's a different can'o'worms.

The client is a web browser. Heck, it could be Lynx or the command line 
browser. The complexity is in forcing the end-user to install a SOAP 
client. That's a great deal of difference.

   Paul Prescod









-----------------------------------------------------------------------------------
Post ID:3034
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-12-13 16:24:29
Subject:Re: [rest-discuss] REST tidbits from XML 2002
Message:

I would imagine they have customized whatever XSLT engine they are using on the server-side to lock down what document() is capable of.  Mozilla 1.x's XSLT engine for example does not allow cross-domain access at all so my Xoomle-Amazon demo can't work directly in that browser.

I've used a version of this at work to demonstrate the potential power of REST:

  http://www.xefer.com/demo.html

It's hardly earth-shattering, but it begins to prove a point.




----- Original Message ----- 
From: Ramin Firoozye 
To: rest-discuss 
Sent: Thursday, December 12, 2002 3:07 PM
Subject: RE: [rest-discuss] REST tidbits from XML 2002


That's true. If you do a bunch of 100MB XML transfers via document(),  sooner or later I imagine they'll yank your associate ID.

Still, pretty gutsy of them to leave it open...

Ramin
  -----Original Message-----
  From: S. Mike Dierken [mailto:mdierken@...]
  Sent: Thursday, December 12, 2002 11:41 AM
  To: rest-discuss
  Subject: Re: [rest-discuss] REST tidbits from XML 2002



  ----- Original Message -----
  From: "Miles Sabin" <miles@...>

  > They allow arbitrary user-supplied stylesheets to make arbitrary
  > outgoing HTTP requests from their servers???!!!!
  Only GETs, but that is sufficient to cause a lot of trouble.
  I think you have to be an affiliate or some other semi-trusted entity to get
  in though.

  To unsubscribe from this group, send an email to:
  rest-discuss-unsubscribe@yahoogroups.com



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 





-----------------------------------------------------------------------------------
Post ID:3035
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-14 02:19:20
Subject:Paul's Big Mistake
Message:

So I skipped a talk because the title did not strike my fancy: 
"Web-Services API for a Government Procurement Application". The hype 
around Web Services can get kind of nauseating and it doesn't comfort me 
that taxpayer money is used to fund development based on the standards 
relatively uncritically.

But it turned out that the talk was actually about a REST based system:

"Following the REST style, Procurement Desktop Defence entities such as 
purchase requests, awards and line items are, like Web pages, given 
URL�s. API clients will use HTTP methods to create, select, update and 
delete these entities, which are represented using an XML vocabulary 
based on the existing client/server PD� vocabulary, extended to 
incorporate PD  e   information and constructs described by this 
architecture and XML standards�XML Namespaces, XML Base, XLink, XPointer 
and XInclude. To interact with the Public API requires only a platform 
capable of TCP/IP communication (to send HTTP messages) and string 
processing (to process XML)."

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:3036
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-15 15:58:42
Subject:A little juvenile humour
Message:

http://www.googlefight.com/cgi-bin/compare.pl?q1=REST&q2=SOAP&B1=Make+a+fight%21&compare=1&langue=us
(short version: http://makeashorterlink.com/?W1B5517C2 )

===

Number of results on Google for the keywords REST and SOAP:

REST (26 100 000 results) versus SOAP (6 170 000 results)

The winner is:    REST

===

Disclaimer: SOAP and REST are not competing technologies. But if they 
were, REST would clearly be the most popular as you can see above.

Note how I used two interesting facets of Web architecture in this very 
message: query strings and redirects!

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:3037
Sender:Jan Algermissen <algermissen@...>
Post Date/Time:2002-12-15 18:34:28
Subject:Representation format as part of URIs?
Message:


Paul,

you wrote the following in your private mail, but my question might
be of interest for others, so I turn to the list.

[Paul Prescod:]
> [...] Let's say that there is a topic map for famous physicists.
> The publisher of that topic map could say: "Use this URI to browse our
> topic map in HTML for web browsrs and there is an XML version served
> from this other URI for machine processing and perhaps for newer
> XML-aware browsers."

Does that mean that I don't have to rely on content negotiation for
choosing the format of the response? So, it would be RESTful to have
those two URIs for example

http://www.physicists.org/html/list-of-physicists
http://www.physicists.org/xml/list-of-physicists

although the representations they return are
representations of the same resource (concept) and only differ
in the markup language used ?

Jan



-- 
Jan Algermissen
Consultant & Programmer

Tel:   ++49 (0)40 89 700 511
       ++49 (0)177 283 1440
Fax:   ++49 (0)40 89 700 841 
Email: algermissen@...
Web:   http://www.topicmapping.com






-----------------------------------------------------------------------------------
Post ID:3038
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-12-15 19:23:05
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

Jan Algermissen wrote:
> Does that mean that I don't have to rely on content negotiation for
> choosing the format of the response? So, it would be RESTful to have
> those two URIs for example
> 
> http://www.physicists.org/html/list-of-physicists
> http://www.physicists.org/xml/list-of-physicists
> 
> although the representations they return are
> representations of the same resource (concept) and only differ
> in the markup language used ?

the trouble (IMHO) with this is that you have different representations
of the same resource using different URIs.  i wouldn't say it's not
RESTful, but i do think it dilutes the RESTfulness.

because most UAs, be they RSS aggregators or web browsers, seem to be
brain-damaged when it comes to content negotiation, i believe the best
compromise is to use a query-string parameter to do the
content-negotiation instead.  i see that joe gregorio uses this
technique for RSS representations in RESTLog[0].  you can use
/RESTLog.cgi?rss for example.

i prefer to use a more explicit query-string, i.e. ?_type=xml.  the
underscore before type is to reduce the potential for a namespace
collision with a 'real' query parameter name.  the reason to use a
query-string name/value pair is to ease integration with URIs that have
'legitimate' query-strings.

for content-negotiation-capable UAs, you just leave that querystring
parameter out.  i think this is more RESTful than having a different URI
for every single representation.  i think it would be useful if people
building RESTful systems used a standard querystring parameter for this
purpose  (the same way google uses ?q=foo for a keyword search and
others have copied this) so content-negotiation capable UAs know they
can discard it, keeping a 'cleaner' URI.

-vincent

references:
0. http://wellformedweb.org/







-----------------------------------------------------------------------------------
Post ID:3039
Sender:Joe Gregorio <joe@...>
Post Date/Time:2002-12-15 19:33:53
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

Vincent D Murphy wrote:

>because most UAs, be they RSS aggregators or web browsers, seem to be
>brain-damaged when it comes to content negotiation, i believe the best
>compromise is to use a query-string parameter to do the
>content-negotiation instead.  i see that joe gregorio uses this
>technique for RSS representations in RESTLog[0].  you can use
>/RESTLog.cgi?rss for example.
>
A small point of clarification, RESTLog does conneg but also supplies
the query parameter for those situations where the client doesn't do conneg.

>
>i prefer to use a more explicit query-string, i.e. ?_type=xml.  the
>underscore before type is to reduce the potential for a namespace
>collision with a 'real' query parameter name.  the reason to use a
>query-string name/value pair is to ease integration with URIs that have
>'legitimate' query-strings.
>
I like that suggestion. I suppose I would have run into the problem when 
I added search to RESLog :)

    -joe

--
http://bitworking.org
http://wellformedweb.org









-----------------------------------------------------------------------------------
Post ID:3040
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-12-15 20:44:47
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

Joe Gregorio wrote:
> A small point of clarification, RESTLog does conneg but also supplies
> the query parameter for those situations where the client doesn't do
> conneg.

noted.  i left that out inadvertently; i actually see the query
parameter as a mechanism for 'overriding' conneg, therefore when the
parameter is left out, one falls back to normal conneg, or failing that,
default behaviour.

-vincent

PS conneg is a nice abbreviation, hadn't seen that before now.







-----------------------------------------------------------------------------------
Post ID:3041
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-15 22:15:17
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

Vincent D Murphy wrote:

> Joe Gregorio wrote:
>
> >A small point of clarification, RESTLog does conneg but also supplies
> >the query parameter for those situations where the client doesn't do
> >conneg.
>
>
> noted.  i left that out inadvertently; i actually see the query
> parameter as a mechanism for 'overriding' conneg, therefore when the
> parameter is left out, one falls back to normal conneg, or failing 
> that, default behaviour.

I think that your conventions are quite reasonable as a workaround for 
the current situation.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:3042
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-15 22:12:28
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

When Sam and I discussed this face-to-face, I told him that content 
negotiation is the correct way to do it in theory but in practice 
browsers and some HTTP libraries are not very intelligent about giving 
any control over content negotiation. So there is a purity/practicality 
trade-off there. You can actually do it both ways without hurting 
anything so that people who can't get their browser/library to do conneg 
can fall back to the URIs.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:3043
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-12-15 23:23:06
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

> for content-negotiation-capable UAs, you just leave that querystring
> parameter out.  i think this is more RESTful than having a different URI
> for every single representation.

This all sounds good, but pedantically aren't these *different* URIs:

	http://foo.com/bar
	http://foo.com/bar?abc=123

Michael







-----------------------------------------------------------------------------------
Post ID:3044
Sender:Andrew Tipton <atipton@...>
Post Date/Time:2002-12-15 23:34:53
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

> > for content-negotiation-capable UAs, you just leave that querystring
> > parameter out.  i think this is more RESTful than having a different URI
> > for every single representation.
>
> This all sounds good, but pedantically aren't these *different* URIs:
>
> 	http://foo.com/bar
> 	http://foo.com/bar?abc=123

The way I have been using query strings (which is not neccessarily the same 
view shared by the RFCs) is that "http://foo.com/bar" is the resource, and 
"?abc=123" is a filter on that resource.  For example:

http://foo.com/bar?_type=xml

Means the resource http://foo.com/bar filtered by "_type=xml" -- in other 
words, converted to an XML representation.  This world-view works very well 
for me in cases of querying a large resource:

http://foo.com/bars?style=blue

Returns a subset of http://foo.com/bars, that in which "style" is "blue".
(Whatever that may mean to the app)

-Andrew







-----------------------------------------------------------------------------------
Post ID:3045
Sender:Michael Day <mikeday@...>
Post Date/Time:2002-12-16 00:39:12
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

> The way I have been using query strings (which is not neccessarily the same 
> view shared by the RFCs) is that "http://foo.com/bar" is the resource, and 
> "?abc=123" is a filter on that resource.

It would be interesting to have more discussion on this point, as I have
been experimenting with various resource classifications and it makes a
big difference whether the query string is a filter or is a sub-resource
(for example, /foo or ?foo could each be used as a filter in an underlying
CGI application, but what implications does that have for what resources
are and what URIs identify?).

On the same topic, do the URIs _?a=b&b=c and _?b=c&a=b identify the same
resource, or different resources? (One of the issues with saying that
query strings identify sub-resources rather than filters...)

Michael







-----------------------------------------------------------------------------------
Post ID:3046
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-16 01:20:18
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

----- Original Message -----
From: "Vincent D Murphy" <vdm@...>

>
> i prefer to use a more explicit query-string, i.e. ?_type=xml.  the
> underscore before type is to reduce the potential for a namespace
> collision with a 'real' query parameter name.
I've done the same thing, but I've used the same names and values as from
the HTTP RFC, such as
http://www.example.com/topicmaps/?do:Accept=text/xml

So this uses "do:" as a qualifier (the ':' character might be a problem) and
the same names as the HTTP headers, in order to easily point developers to
an existing specification for details and documentation.






-----------------------------------------------------------------------------------
Post ID:3047
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-16 01:23:40
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

----- Original Message -----
From: "Andrew Tipton" <atipton@...>

> The way I have been using query strings (which is not neccessarily the
same
> view shared by the RFCs) is that "http://foo.com/bar" is the resource, and
> "?abc=123" is a filter on that resource.
That may be how your internal system views things, but from the URI & HTTP
specs, they are two separate resources and all external clients will/can
treat them as separate & you cannot requires agents to understand the
site-specific internal application use.
One of the tricks with REST is to have your internal implementation do cool
things with query terms, yet have all external agents treat them opaquely.






-----------------------------------------------------------------------------------
Post ID:3048
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-16 05:54:51
Subject:Re: [xml-dev] XML2002 Conference in Baltimore?
Message:

Tim Bray wrote:

>  Lots
> of: schema-languages, topic maps, databases, Web Services.  Not much of:
> graphics, RDF, publishing. -Tim

Actually, there was a lot of content management.

http://makeashorterlink.com/?F2E8218C2

  And electronic business  (UBL, ebXML, xBRL) as distinguished from web 
services.

The proceedings are available here:

  * http://www.idealliance.org/papers/xml02/dx_xml02/index.html

There is some good stuff in there. Worth browsing.

REST is also starting to get some representation. Tim talked about it 
somewhat in his plenary, and then there were these three regular talks:

  * 
http://www.idealliance.org/papers/xml02/dx_xml02/papers/03-02-03/03-02-03.html

  * 
http://www.idealliance.org/papers/xml02/dx_xml02/papers/06-00-13/06-00-13.html

  * http://makeashorterlink.com/?P3F8528C2

Considering that a year ago the number of people who had heard about 
REST could fit in a Mini, that's good progress. We're up to a couple of 
city buses.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:3049
Sender:=?ISO-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-12-16 08:44:51
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

Michael Day wrote:

> On the same topic, do the URIs _?a=b&b=c and _?b=c&a=b identify the same
> resource, or different resources? (One of the issues with saying that
> query strings identify sub-resources rather than filters...)


This question applies to any two URIs, that it, I wouldn't like to 
treat URIs with query strings as a special case. Given that many 
URIs can map to one resource, the answer seems to be possibly. But 
I'm not sure how you'd go about declaring that. This is also an 
(important) issue for RDF folks who want to merge two or more graphs.

Bill de h�ra








-----------------------------------------------------------------------------------
Post ID:3050
Sender:=?ISO-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-12-16 08:45:57
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

Michael Day wrote:

> This all sounds good, but pedantically aren't these *different* URIs:
> 
> 	http://foo.com/bar
> 	http://foo.com/bar?abc=123

Yes, but they may (or may not) denote the same resource.

Bill de h�ra







-----------------------------------------------------------------------------------
Post ID:3051
Sender:=?ISO-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-12-16 08:57:25
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

Jan Algermissen wrote:

> 
> Does that mean that I don't have to rely on content negotiation for
> choosing the format of the response? So, it would be RESTful to have
> those two URIs for example
> 
> http://www.physicists.org/html/list-of-physicists
> http://www.physicists.org/xml/list-of-physicists
> 
> although the representations they return are
> representations of the same resource (concept) and only differ
> in the markup language used ?

I think Mike's argument applies here. You can't assume that clients 
outside your system (ie most of them) will understand the processing 
assumptions built into your URIs; in the HTTP case, the protocol 
provides somewhat for obtaining representations based on a mimetype.

But it does once again highlight the difficulty of the URI opacity 
axiom (cue Jeff Bone), tho' I /think/ I saw TBL describe it as 
merely being a good practice recently; maybe it's been downgraded.

Bill de h�ra








-----------------------------------------------------------------------------------
Post ID:3052
Sender:Duncan Cragg <rest@...>
Post Date/Time:2002-12-16 10:02:29
Subject:Time axis in GET: P2P and Media
Message:

Is it RESTful (or even HTTP/1.1 compliant) to use GET with a 'time axis' 
(i.e., as opposed to getting /all/ the data back as /soon/ as it's 
requested)?


Example 1.  Using HTTP/1.1 as a P2P protocol - the search for the 
Resource could take some time, so either the Response takes a minute and 
keeps the Request open (risking proxy timeout), or the line is 'pinged' 
with void chunks while the peer is waiting. (GET 
http://p2psystem/britney32541)

Example 2.  Using HTTP/1.1 as a media streaming protocol: there is 
/never/ any content length - the channel just goes on and on, sending 
chunks... (GET http://britney-radio/)

Example 3.  The Resource being fetched is not a simple file, but comes 
from a user interface (GET 
http://turing-test/is-it-britney?favourite+colour)

Example 4.  The Resource is a user typing into a chat field at random 
times (GET http://britney-oracle/what-she-says-now)


I'm as interested in 'REST compliance' as HTTP/1.1 compliance in the above.


| Related issues in HTTP/1.1 context :
|
| (a) Was chunked transfer encoding designed for streaming media, or is 
that usage a hack?
| (b) Are proxies actually required to remove transfer encodings in 
HTTP/1.1?
| (c) What does HTTP/1.1 say about request-response timeouts?
| (d) What about inter-chunk timeouts?

(OK, you can redirect me to an HTTP list for these!!  I couldn't find 
anything about the above from scanning RFC2616.)


Hope this all makes sense and I'm not being too demanding with a big 
list of questions, coming up to holiday time... :-)


Duncan Cragg










-----------------------------------------------------------------------------------
Post ID:3053
Sender:Duncan Wilcox <duncan@...>
Post Date/Time:2002-12-16 10:03:15
Subject:PUT vs. POST (vs. SET?)
Message:

Hi there,

I'm trying to get a better feeling of the right way to RESTify an 
interface to a set of services, coming from existing SOAP and XML-RPC 
interfaces. I'm a newcomer to REST and I just discovered this list, 
please pardon me if I'm naive.

The documents I exchange with the REST interface are mainly server 
configuration, status and statistics, for multiple profiles.

A first issue is handling the collection of profiles, similar to how a 
REST style blogger interface would handle a collection of posts:

http://internet.conveyor.com/RESTwiki/moin.cgi/RestifyingBlogger

POSTing to the container might be a solution, which I first read in 
Philip Eskelin's mail:

http://groups.yahoo.com/group/rest-discuss/message/2974

This seems to be kind of bending the semantics of POST -- sort of 
assuming that the path is just a selector in a super document -- but 
works well as an alternative to having to GET the latest profile 
identifier and to PUT to the next profile ID (handling race conditions, 
overwriting existing profiles, etc).

Browsing around for inspiration, I stepped into Mark Baker's article on 
PUT vs. SET:

http://www.markbaker.ca/blog/2002/12/13#2002-12-soap-put

If I get this right, if PUTting a document has side effects, then PUT 
isn't the right method to use, you should be using a (to be proposed) 
SET method.

I'm currently updating profile cofniguration and status via PUT, would 
the use of SET be more appropriate? (the clients to this interface 
probably wouldn't be browsers)

I view POST as "PUT but in append", so for the creation of new profiles 
would there be a need for a "SET but in append" method?

Thanks,
Duncan

--
http://duncan.focuseek.com








-----------------------------------------------------------------------------------
Post ID:3054
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-16 15:10:31
Subject:Re: [rest-discuss] PUT vs. POST (vs. SET?)
Message:

On Mon, Dec 16, 2002 at 11:03:15AM +0100, Duncan Wilcox wrote:
> Browsing around for inspiration, I stepped into Mark Baker's article on 
> PUT vs. SET:
> 
> http://www.markbaker.ca/blog/2002/12/13#2002-12-soap-put
> 
> If I get this right, if PUTting a document has side effects, then PUT 
> isn't the right method to use, you should be using a (to be proposed) 
> SET method.
> 
> I'm currently updating profile cofniguration and status via PUT, would 
> the use of SET be more appropriate? (the clients to this interface 
> probably wouldn't be browsers)

SET is PUT plus a hook to a processing model.  The only reason I'm even
considering documenting it is for use with SOAP.  I don't think it's
useful to you here.

> I view POST as "PUT but in append", so for the creation of new profiles 
> would there be a need for a "SET but in append" method?

POST is just "hand over this data".  Unlike PUT/SET, you have no idea
what the state of the resource to which you're POSTing will be after
it's completed.  That's why the container abstraction represents POST so
well, I've found, since all you know when you're dealing with a
container is that the data was added/submitted to it.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3055
Sender:Duncan Wilcox <duncan@...>
Post Date/Time:2002-12-16 15:11:29
Subject:Re: [rest-discuss] PUT vs. POST (vs. SET?)
Message:

> SET is PUT plus a hook to a processing model.  The only reason I'm even
> considering documenting it is for use with SOAP.  I don't think it's
> useful to you here.

So would say that "side effects" in the server (e.g. a service starting or 
stopping) as a legitimate consequence of a PUT?

Thanks,
Duncan







-----------------------------------------------------------------------------------
Post ID:3056
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-16 15:30:24
Subject:Re: [rest-discuss] PUT vs. POST (vs. SET?)
Message:

On Mon, Dec 16, 2002 at 04:11:29PM +0100, Duncan Wilcox wrote:
> > SET is PUT plus a hook to a processing model.  The only reason I'm even
> > considering documenting it is for use with SOAP.  I don't think it's
> > useful to you here.
> 
> So would say that "side effects" in the server (e.g. a service starting or 
> stopping) as a legitimate consequence of a PUT?

Definitely, but I'd caution that it's best practice with PUT to restrict
the scope of the the side-effects to those specifically request by the
message.

i.e. to "start a service", use something like;

PUT "on" to /my-service/run-status

rather than having it be a "surprise" consequence of doing something
else with PUT, like;

PUT "My Service" to /my-service/name

IMO, it makes better use of the HTTP contract, so is more visible to
intermediaries.  But if doing doing it that way is too much of a pain,
no biggie; there's no rule saying PUT side effects have to be limited
to the resource being interacted with.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3057
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-12-16 15:42:41
Subject:Re: [rest-discuss] PUT vs. POST (vs. SET?)
Message:

> Mark Baker wrote:
>
> SET is PUT plus a hook to a processing model.  The only reason 
> I'm even considering documenting it is for use with SOAP.  

Could you explain why this would be so specific to SOAP?  My 
understanding was that "SET" would be a way of storing or updating 
a resource in a way that is not as document-centric as PUT.

This would be useful even in a pure XML/HTTP context and not just 
with SOAP.










-----------------------------------------------------------------------------------
Post ID:3058
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-12-16 17:44:42
Subject:Re: [rest-discuss] PUT vs. POST (vs. SET?)
Message:

Hmm... and I thought that SET was the ability to update a resource without
replacing the entire thing (as PUT does).  Of course, now that I think about
this some more, this would require some form of processing of the request to
determine how to update the resource... which sounds like POST processing.
I know differences between SET and PUT have been discussed, but what about
the differences between SET and POST?  The only thing I can think of is that
SET allows the direct creation of a resource at a given URI, while POST does
not.

And I suppose that SET could always be implemented via PUT by providing
sufficiently fine grained URIs to the sub-resource(s).  Okay... so maybe
there isn't a need for a SET after all.  Within SOAP and similar RPC specs,
use of a SET would make more sense since you would not have all of the URIs.

Or do I just have SET all wrong?

---
Seairth Jacobs
seairth@...


----- Original Message -----
From: "Jeffrey Winter" <j.winter@...>
To: "Duncan Wilcox" <duncan@...>; "Mark Baker" <distobj@...>
Cc: <rest-discuss@yahoogroups.com>
Sent: Monday, December 16, 2002 10:42 AM
Subject: Re: [rest-discuss] PUT vs. POST (vs. SET?)


> > Mark Baker wrote:
> >
> > SET is PUT plus a hook to a processing model.  The only reason
> > I'm even considering documenting it is for use with SOAP.
>
> Could you explain why this would be so specific to SOAP?  My
> understanding was that "SET" would be a way of storing or updating
> a resource in a way that is not as document-centric as PUT.
>
> This would be useful even in a pure XML/HTTP context and not just
> with SOAP.
>
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>







-----------------------------------------------------------------------------------
Post ID:3059
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-16 18:18:38
Subject:Re: [rest-discuss] Time axis in GET: P2P and Media
Message:

----- Original Message -----
From: "Duncan Cragg" <rest@...>
To: <rest-discuss@yahoogroups.com>
Sent: Monday, December 16, 2002 2:02 AM
Subject: [rest-discuss] Time axis in GET: P2P and Media


> Is it RESTful (or even HTTP/1.1 compliant) to use GET with a 'time axis'
> (i.e., as opposed to getting /all/ the data back as /soon/ as it's
> requested)?
Oh yes, definitely. This is what KnowNow does. In a somewhat proprietary way
(meaning it isn't an RFC or fully header based) their system lets you 'get'
past and future events for a resource via a query term 'do_max_age'. Larger
positive numbers indicate older events - farther into the past.

For example, I wrote a sample app that polls Amazon (via their XML over HTTP
interface) to get popular sales items and post events to a messaging server.
A simple client subscribes to this stream of events using a 'max_age' to
only get recent events. It's an IE5+ app, but its a 'live events in the
browser' thing...

http://www.topiczero.com:8000/kn_apps/amazonpop/



>
> Example 1.  Using HTTP/1.1 as a P2P protocol - the search for the
> Resource could take some time, so either the Response takes a minute and
> keeps the Request open (risking proxy timeout), or the line is 'pinged'
> with void chunks while the peer is waiting. (GET
> http://p2psystem/britney32541)
It doesn't keep the Request open, it keeps the connection open. If a
Response could be sent on a separate connection, then you wouldn't risk
proxy timeouts. Adding some way to correlate request message and response
message is an increase in complexity but it pays of in increased
functionality. This list discussed ways to do the correlation (and provide
callback location in the request, etc.) sometime in the past...

I'm interested in pursuing the p2p angle with pure http. I've looked at
Gnutella & I see some obvious ways to use GET for much of the node discovery
and searching aspects - but I'm not sure what aspects of the behavior of
Gnutella are important to preserve. I need to frame these questions & ask
LucasG/etc. on the decentralization list... sometime.

>
> Example 2.  Using HTTP/1.1 as a media streaming protocol: there is
> /never/ any content length - the channel just goes on and on, sending
> chunks... (GET http://britney-radio/)
>
Yes, that would work too.

> Example 3.  The Resource being fetched is not a simple file, but comes
> from a user interface (GET
> http://turing-test/is-it-britney?favourite+colour)
>
Huh?

> Example 4.  The Resource is a user typing into a chat field at random
> times (GET http://britney-oracle/what-she-says-now)
>
If the 'what-she-says-now' has state of what she said in the past N minutes,
then doing a GET for a snapshot would work. But if it is a buffer that gets
cleared out pretty fast, doing a GET would result in getting from an empty
buffer.
It's easy to model the chat session as a resource and get message. Once
again, see KnowNow's stuff.







-----------------------------------------------------------------------------------
Post ID:3060
Sender:Joe Gregorio <joe@...>
Post Date/Time:2002-12-16 15:53:40
Subject:Re: [rest-discuss] PUT vs. POST (vs. SET?)
Message:

Mark Baker wrote:
> On Mon, Dec 16, 2002 at 11:03:15AM +0100, Duncan Wilcox wrote:
> 
>>Browsing around for inspiration, I stepped into Mark Baker's article on 
>>PUT vs. SET:
>>
>>http://www.markbaker.ca/blog/2002/12/13#2002-12-soap-put
>>
>>If I get this right, if PUTting a document has side effects, then PUT 
>>isn't the right method to use, you should be using a (to be proposed) 
>>SET method.
>>
>>I'm currently updating profile cofniguration and status via PUT, would 
>>the use of SET be more appropriate? (the clients to this interface 
>>probably wouldn't be browsers)
> 
> 
> SET is PUT plus a hook to a processing model.  The only reason I'm even
> considering documenting it is for use with SOAP.  I don't think it's
> useful to you here.

Is there a reason not to just hook the processing off
of a PUT with content-type: application/soap+xml?

	-joe

-- 
http://BitWorking.org
http://WellFormedWeb.org








-----------------------------------------------------------------------------------
Post ID:3061
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-16 19:07:42
Subject:Re: [rest-discuss] PUT vs. POST (vs. SET?)
Message:

On Mon, Dec 16, 2002 at 10:42:41AM -0500, Jeffrey Winter wrote:
> > Mark Baker wrote:
> >
> > SET is PUT plus a hook to a processing model.  The only reason 
> > I'm even considering documenting it is for use with SOAP.  
> 
> Could you explain why this would be so specific to SOAP?  My 
> understanding was that "SET" would be a way of storing or updating 
> a resource in a way that is not as document-centric as PUT.

That's right.  I'm just saying that SOAP requires it, which provides
the impetus necessary for me to proceed with it.  For regular XML/HTTP
use, you can always manage to get by with just PUT.

> This would be useful even in a pure XML/HTTP context and not just 
> with SOAP.

Sure.

Joe asks;
> Is there a reason not to just hook the processing off
> of a PUT with content-type: application/soap+xml?

The media type is just opaque representation metadata that is also
just "stored", as far as PUT is concerned; it isn't used for dispatch
at all.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3062
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-16 19:14:05
Subject:Re: [rest-discuss] PUT vs. POST (vs. SET?)
Message:

On Mon, Dec 16, 2002 at 12:44:42PM -0500, Seairth Jacobs wrote:
> Or do I just have SET all wrong?

Yep. 8-)

SET is just PUT with the added capability of being able to process
the representation prior to the "store" happening.

i.e. you could do;

PUT "1" > http://example.org/foo1

then invoke GET and see;

"one"

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3063
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-12-16 19:33:55
Subject:Re: [rest-discuss] PUT vs. POST (vs. SET?)
Message:

From: "Mark Baker" <distobj@...>
>
> On Mon, Dec 16, 2002 at 12:44:42PM -0500, Seairth Jacobs wrote:
> > Or do I just have SET all wrong?
>
> Yep. 8-)
>
> SET is just PUT with the added capability of being able to process
> the representation prior to the "store" happening.
>
> i.e. you could do;
>
> PUT "1" > http://example.org/foo1
>
> then invoke GET and see;
>
> "one"

Other than the fact that PUT/SET can create a mapping between URI and
resource, why couldn't your example be done with a POST?

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:3064
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-16 19:59:23
Subject:Re: [rest-discuss] PUT vs. POST (vs. SET?)
Message:

On Mon, Dec 16, 2002 at 02:33:55PM -0500, Seairth Jacobs wrote:
> Other than the fact that PUT/SET can create a mapping between URI and
> resource, why couldn't your example be done with a POST?

Because a valid response from a GET after the POST could be "two",
"three", or "j234q;il2j4oj34dq;324dq234".  With POST, you *never* have
an expectation about the state of the resource after it's been invoked
(other than you should assume that it's changed).  With PUT/SET, you
*always* do.  That's the dividing line.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3065
Sender:"bhaugen32 <bhaugen32@...>" <bhaugen32@...>
Post Date/Time:2002-12-16 20:05:11
Subject:Re: [xml-dev] XML2002 Conference in Baltimore?
Message:

Paul Prescod wrote:
> electronic business  (UBL, ebXML, xBRL) as distinguished from web 
> services.

Speaking of ebXML, last week I attended a meeting of UN/CEFACT, one 
of the parent orgs.  They originally intended ebXML to be an 
implementation of their UN Modeling Methodology, which they intend to 
be a technology-neutral specification for electronic business 
collaborations.  (Needless to say, the reality deviated somewhat from 
the intent, but the family resemblence remains.)

Anyway, I mentioned that I wanted to develop a REST implementation.  
Last year, I got flamed as a traitor to ebXML for the same 
suggestion. This year, I got enthusiastic interest from people who 
knew what REST means.  

Now, I have no idea if and when I can afford the time to do it, but 
the different in attitude over a year was striking.

I attribute it to good propaganda work. 

P.S. Paul, I had a side conversation with Duane Nickull who is now 
the official UNCEFACT rep to the W3C ws-architecture project, who 
mentioned your name and that you both live in Vancouver...







-----------------------------------------------------------------------------------
Post ID:3066
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-17 21:24:23
Subject:Hypermedia workflow
Message:

I've written a bit on workflow and hypermedia systems, and used BPEL4WS
as my whipping boy. 8-)

I haven't finished the Pick section yet since I'm waiting on an answer to
a question about it, but the rest is mostly intact.

All feedback is appreciated;

http://www.markbaker.ca/2002/12/HypermediaWorkflow/

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3067
Sender:Duncan Cragg <rest@...>
Post Date/Time:2002-12-18 00:12:43
Subject:Re: [rest-discuss] Time axis in GET: P2P and Media
Message:


> > Is it RESTful (or even HTTP/1.1 compliant) to use GET with a 'time axis'
> > (i.e., as opposed to getting /all/ the data back as /soon/ as it's
> > requested)?

> A simple client subscribes to this stream of events using a 'max_age' to
> only get recent events. It's an IE5+ app, but its a 'live events in the
> browser' thing...

So new events update the browser?  Why don't all news services use it?  

Why, indeed, do we need the comparatively over-done and bloated 
HTTPEvents, even??!!

Surely the semantics of chunks like 'part 1 of 10, part 2 of 10, ...' 
versus 'all current state, update to current state, update to current 
state' are so different that no normal browser would know what to do? 
 There's nothing in the HTTP/1.1 spec that says what the semantics of 
chunking is, as far as I can see!



> > Example 1.  Using HTTP/1.1 as a P2P protocol - the search for the
> > Resource could take some time, so either the Response takes a minute and
> > keeps the Request open (risking proxy timeout), or the line is 'pinged'
> > with void chunks while the peer is waiting. (GET
> > http://p2psystem/britney32541) <http://p2psystem/britney32541%29>
> It doesn't keep the Request open, it keeps the connection open. If a
> Response could be sent on a separate connection, then you wouldn't risk
> proxy timeouts. Adding some way to correlate request message and response
> message is an increase in complexity but it pays of in increased
> functionality. This list discussed ways to do the correlation (and provide
> callback location in the request, etc.) sometime in the past...
>
> I'm interested in pursuing the p2p angle with pure http. I've looked at
> Gnutella & I see some obvious ways to use GET for much of the node 
> discovery
> and searching aspects - but I'm not sure what aspects of the behavior of
> Gnutella are important to preserve. I need to frame these questions & ask
> LucasG/etc. on the decentralization list... sometime.

OK


>
> >
> > Example 2.  Using HTTP/1.1 as a media streaming protocol: there is
> > /never/ any content length - the channel just goes on and on, sending
> > chunks... (GET http://britney-radio/) <http://britney-radio/%29>
> >
> Yes, that would work too.

OK


>
>
> > Example 3.  The Resource being fetched is not a simple file, but comes
> > from a user interface (GET
> > http://turing-test/is-it-britney?favourite+colour) 
> <http://turing-test/is-it-britney?favourite+colour%29>
> >
> Huh?

I mean that you GET on my machine here, and I see your request and type 
something in for you to render on your browser!!  There is a delay 
before I notice that you've requested my wisdom.  I was just using it as 
a rather odd example of time-dependency or time-axis-in-GET. Sorry. 
Should've explained better.


>
> > Example 4.  The Resource is a user typing into a chat field at random
> > times (GET http://britney-oracle/what-she-says-now) 
> <http://britney-oracle/what-she-says-now%29>
> >
> If the 'what-she-says-now' has state of what she said in the past N 
> minutes,
> then doing a GET for a snapshot would work. But if it is a buffer that 
> gets
> cleared out pretty fast, doing a GET would result in getting from an empty
> buffer.
> It's easy to model the chat session as a resource and get message. Once
> again, see KnowNow's stuff.
>

What I'm saying is, not the state in the past N minutes, but the state 
from the point the GET was received, onwards.  So it would indeed be 
nothing at the time, and would be an HTTP/1.1 chunk per pearl of wisdom 
from then on, as it was cast.

Would you be kind enough to elaborate a little on this (the what KnowNow 
does, chat part)?  

Again, chunking is just dividing up a single big data item, isn't it? 
Not for (a) 'time-staked' events or (b) updates to previously sent data. 
 After all, there's no standard page update syntax (chunk number 7: 
"this line, and this line only, has changed")


So, anyway, just 'cos KnowNow does it, doesn't mean it's pure as 
newly-laid snow to rest-discussers......  !!

The poor reaction to my email either indicates it's OK and REST-assured, 
or everyone is shaking their heads in dismay...  :-)



Finally, assuming we can OK it with HTTP HQ, is such use of chunking to 
update state also cool with REST Centraal Kontrol?? MarkB? PaulP?


Duncan Cragg








-----------------------------------------------------------------------------------
Post ID:3068
Sender:"Roy T. Fielding" <fielding@...>
Post Date/Time:2002-12-18 00:19:02
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

> Does that mean that I don't have to rely on content negotiation for
> choosing the format of the response? So, it would be RESTful to have
> those two URIs for example
>
> http://www.physicists.org/html/list-of-physicists
> http://www.physicists.org/xml/list-of-physicists
>
> although the representations they return are
> representations of the same resource (concept) and only differ
> in the markup language used ?

Those are two different resources.  If a person wishes to identify
the XML representation of a concept, an HTML response to that resource
would not be a valid representation even though it may have essentially
the same content.  If the resource is a concept independent of
representation format, then its URI must not have any aspect
that is specific to the representation format.  Having that aspect
in the URI (as interpreted by the origin server) implies that the
resource semantics includes the format.

BTW, for server-contructed URI, there is no effective difference
between query and path info -- both distinguish a resource.  It is
only when the URI is client-constructed (as in GET forms or ISINDEX
or the old server-side image maps) that the client has any way to
distinguish the non-query path as a resource, and even then the
various URI with the query info tagged-onto the end identify separate
resources.

A resource is defined not by its implementation, but by a user's
expectation of results from future actions on that resource.
If two URI are expected to respond to GET differently, then they
must identify different resources.

....Roy







-----------------------------------------------------------------------------------
Post ID:3069
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-18 00:26:19
Subject:Re: [rest-discuss] Time axis in GET: P2P and Media
Message:

----- Original Message -----
From: "Duncan Cragg" <rest@...>

> Surely the semantics of chunks like 'part 1 of 10, part 2 of 10, ...'
> versus 'all current state, update to current state, update to current
> state' are so different that no normal browser would know what to do?
>  There's nothing in the HTTP/1.1 spec that says what the semantics of
> chunking is, as far as I can see!
Chunking has no app-level semantic - it is purely for transport optimization
(streaming without knowing length in advance). The chunks could be
arbitrarily resized by intermediaries & it would 'still work'.






-----------------------------------------------------------------------------------
Post ID:3070
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-18 00:27:44
Subject:Re: [rest-discuss] Time axis in GET: P2P and Media
Message:

----- Original Message -----
From: "Duncan Cragg" <rest@...>

> So new events update the browser?  Why don't all news services use it?
Because uses don't sit in front of www.cnn.com and wait for news to happen.
The frequency of events is way too low to be captivating for a human
audience.
Automation apps (aggregators, agents, etc), however, don't care.






-----------------------------------------------------------------------------------
Post ID:3071
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-18 01:03:34
Subject:Re: [rest-discuss] Time axis in GET: P2P and Media
Message:

On Wed, Dec 18, 2002 at 12:12:43AM +0000, Duncan Cragg wrote:
> Finally, assuming we can OK it with HTTP HQ, is such use of chunking to 
> update state also cool with REST Centraal Kontrol?? MarkB? PaulP?

You may have noticed that Roy just subscribed, so we have actual
authority to appeal to now. 8-)

My view is that chunking is a transfer issue; it's just a means of,
well, chunking a stream into individual chunks.  But that said, it's a
good idea for the server to send chunks that are optimally sized for
incremental processing/rendering to reduce effective latency as seen by
the client application.

This is what KnowNow does, as I understand it, where each chunk is an
event notification.  I have no problem with it whatsoever, though from
an XML POV, it's slightly flawed because the composite stream (what you
get when you concatenate all the chunks) is not well-formed XML because
there's no "root container", like <event-stream> .. </event-stream>.
But I'm ok with that.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3072
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-18 01:13:28
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

Roy T. Fielding wrote:

>
> BTW, for server-contructed URI, there is no effective difference
> between query and path info -- both distinguish a resource.  It is

> only when the URI is client-constructed (as in GET forms or ISINDEX
> or the old server-side image maps) that the client has any way to
> distinguish the non-query path as a resource, and even then the
> various URI with the query info tagged-onto the end identify separate
> resources.

2396 is not clear about that. It says:

"3.4. Query Component

    The query component is a string of information to be interpreted by
    the resource."

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:3073
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-18 01:27:56
Subject:Re: [rest-discuss] Time axis in GET: P2P and Media
Message:

----- Original Message -----
From: "Mark Baker" <distobj@...>

> This is what KnowNow does, as I understand it, where each chunk is an
> event notification.  I have no problem with it whatsoever, though from
> an XML POV, it's slightly flawed because the composite stream (what you
> get when you concatenate all the chunks) is not well-formed XML because
> there's no "root container", like <event-stream> .. </event-stream>.
> But I'm ok with that.

Just grin & say they are 'xml fragments' and don't claim they are
'documents'.
(I think Jabber is exactly the same - a stream of fragments. I don't know if
they use a PI to separate the logical documents though)






-----------------------------------------------------------------------------------
Post ID:3074
Sender:"Roy T. Fielding" <fielding@...>
Post Date/Time:2002-12-18 01:20:04
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

> 2396 is not clear about that. It says:
>
> "3.4. Query Component
>
>    The query component is a string of information to be interpreted by
>    the resource."

Yes, but it doesn't say that the resource is identified by what comes
before the query component.

....Roy







-----------------------------------------------------------------------------------
Post ID:3075
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-18 01:36:24
Subject:Re: [rest-discuss] Time axis in GET: P2P and Media
Message:

----- Original Message -----
From: "Duncan Cragg" <rest@...>

>
> > > Example 4.  The Resource is a user typing into a chat field at random
> > > times (GET http://britney-oracle/what-she-says-now)
> > <http://britney-oracle/what-she-says-now%29>
> > >
> > If the 'what-she-says-now' has state of what she said in the past N
> > minutes,
> > then doing a GET for a snapshot would work. But if it is a buffer that
> > gets
> > cleared out pretty fast, doing a GET would result in getting from an
empty
> > buffer.
> > It's easy to model the chat session as a resource and get message. Once
> > again, see KnowNow's stuff.
> >
>
> What I'm saying is, not the state in the past N minutes, but the state
> from the point the GET was received, onwards.  So it would indeed be
> nothing at the time, and would be an HTTP/1.1 chunk per pearl of wisdom
> from then on, as it was cast.
>
> Would you be kind enough to elaborate a little on this (the what KnowNow
> does, chat part)?
What KN does is provide a resource that is a set of past and future events.
Using query terms the client can specify what range they would like -
including 'all future events'. I think of it as a GET on the future.
They have multiple types clients, including a JavaScript in the browser
client.
You can see a live example at
http://www.topiczero.com:8000/kn_apps/amazonpop/ - its an example I wrote
that monitors the top selling items on Amazon. The page listens to a
particular topic for incoming events.
There is an 'add comment' on the top right of the page & when a new comment
shows up, I put it on the screen using IE5 nifty node.innerHTML stuff.


>
> So, anyway, just 'cos KnowNow does it, doesn't mean it's pure as
> newly-laid snow to rest-discussers......  !!
What KN does isn't always very RESTful but it is very useful.








-----------------------------------------------------------------------------------
Post ID:3076
Sender:DJ Adams <dj.adams@...>
Post Date/Time:2002-12-18 08:15:15
Subject:Re: [rest-discuss] Time axis in GET: P2P and Media
Message:

On Tue, Dec 17, 2002 at 05:27:56PM -0800, S. Mike Dierken wrote:
> Just grin & say they are 'xml fragments' and don't claim they are
> 'documents'.
> (I think Jabber is exactly the same - a stream of fragments. I don't know if
> they use a PI to separate the logical documents though)

That's it, over the course of a single (e.g.) client-to-server connection,
two documents are exchanged over time, one sent fragment by fragment from
the client to the server, and the other the in the other direction. No PIs
are used for separation, but the chunking is at the 'whole element' level
rather than the potentially more random transport-level. One advantage of
a single document over time is that you're not instantiating a parser
every time you receive an element.

dj
http://www.pipetree.com/qmacro






-----------------------------------------------------------------------------------
Post ID:3077
Sender:Duncan Cragg <rest@...>
Post Date/Time:2002-12-18 09:54:01
Subject:Re: [rest-discuss] Time axis in GET: P2P and Media
Message:

Mark Baker wrote:

 >>Finally, assuming we can OK it with HTTP HQ, is such use of chunking to
 >>update state also cool with REST Centraal Kontrol?? MarkB? PaulP?
 >>
 >>
 >
 >You may have noticed that Roy just subscribed, so we have actual
 >authority to appeal to now. 8-)
 >
 >
Hi! Roy! Welcome to rest-discuss!

(I'm a newbie here, too (joined last week) so we can share
experiences... ;-)

So I suppose you actually just got tired of reading the list with
interleaved adverts on the website, huh?

Anyway, I hope you jump in and put us all straight from time to time....


 >My view is that chunking is a transfer issue; it's just a means of,
 >well, chunking a stream into individual chunks.  But that said, it's a
 >good idea for the server to send chunks that are optimally sized for
 >incremental processing/rendering to reduce effective latency as seen by
 >the client application.
 >
Right, that's how I read the HTTP RFC.


 >This is what KnowNow does, as I understand it, where each chunk is an
 >event notification.  I have no problem with it whatsoever, though from
 >an XML POV, it's slightly flawed because the composite stream (what you
 >get when you concatenate all the chunks) is not well-formed XML because
 >there's no "root container", like <event-stream> .. </event-stream>.
 >But I'm ok with that.
 >
Well that's OK: just open the wrapping <event-stream> tag and forget to
close it!  And use a stream parser.


Anyway - this gets to the core of the issue: that GET semantics are
different if you introduce the time-staking interpretation of chunks -
they cease to be just a transfer technology, and become timely events or
data updates.  It's the difference between:

     <Stuff>
         <Big-Pile-Of-CDATA length="10000">
            :
         </Big-Pile-Of-CDATA>
         <!-- end of chunk one-->
            :
         <Big-Pile-Of-CDATA length="10000">
            :
         </Big-Pile-Of-CDATA>
         <!-- end of chunk two-->
     </Stuff>
     <!--EOT-->


And:

     <event-stream>
         <All-The-Data-In-One>
            :
         </All-The-Data-In-One>
         <!-- end of chunk one-->
             :
         <!-- tum tee tum, twiddle fingers -->
             :
         <Update>
            <insert at-elem-number="12">
               <new-piece att="val">
            </insert>
        </Update>
         <!-- end of chunk two-->
            :
            :
     <!-- still no close event-stream tag... -->


As discussed before:

     http://groups.yahoo.com/group/rest-discuss/message/600
     http://groups.yahoo.com/group/rest-discuss/message/656


So if the latter, open-ended XML and the use of chunking
in this way is OK, then *great* - we can dispose of
MONITOR/HTTPEvents!!!  :-)

Did the list reach a consensus back then?  It seems,
judging by responses so far, that KnowNow and
open, dangling, time-chunk-semantics, 'subscriber'
GETs are OK.

But what about the cacheing issues? You need
intermediaries to understand the difference between
'this is /all/ the data, in chunks' and 'this /chunk/ is all
the data and subsequent chunks keep it up-to-date'.
Which requires a little too much understanding of
some random update syntax by dumb proxies... Not that
I object to intermediaries being replaced by first-class
peers: at least they'd be more use to us.

Roy?!!! :-)


Duncan Cragg














-----------------------------------------------------------------------------------
Post ID:3078
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-12-18 10:00:18
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

Roy T. Fielding wrote,
> > 2396 is not clear about that. It says:
> >
> > "3.4. Query Component
> >
> >    The query component is a string of information to be interpreted
> >    by the resource."
>
> Yes, but it doesn't say that the resource is identified by what comes
> before the query component.

True, but puzzling.

If the resource is identified by the whole URI then,

1. http://www.example.com/foo?bar

and,

2. http://www.example.com/foo?baz

identify two distinct resources R1 and R2, in which case there doesn't 
seem to be very much "interpretation" to be done: "?bar" is encoded 
into the identifier for R1 and "?baz" is encoded into the identifier 
for R2, so any further inspection of the query component by either 
resource would be redundant.

Whatever the currently preferred understanding of the relationship 
between URIs, resources and representations, 3.4 only really makes any 
sense if we treat the prefix,

   http://www.example.com/foo

as identifying a _process_ and the query component as specifying an 
argument to be provided to that process.

But that pretty clearly isn't your currently preferred understanding, 
which, even if it's not strictly speaking inconsistent with 3.4, 
certainly seems to be in tension with it. So maybe 3.4 needs tweaking?

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:3079
Sender:"bhaugen32 <bhaugen32@...>" <bhaugen32@...>
Post Date/Time:2002-12-18 15:58:33
Subject:Re: Hypermedia workflow
Message:

Mark Baker wrote:
> I've written a bit on workflow and hypermedia systems, and used 
BPEL4WS
> as my whipping boy. 8-)
> All feedback is appreciated;
> 
> http://www.markbaker.ca/2002/12/HypermediaWorkflow/

Mark, I really appreciate where you and Paul are going with all of 
these excursions into "hypermedia as the engine of application state".

I'll study your latest more deeply when I get time, but here are some 
immediate responses:

1. I really like this part:
"a critical point is that the choreography application model requires 
that implementation details (the business process rules) be exposed 
as part of the interface. This will make them very brittle should 
they need to change, as well as drastically increasing the 
coordination costs of implementing a multi-party process (since the 
more parties that are in the process, the more agreement that will 
need to be made). By keeping process implementation details hidden 
behind the interface, none of those problems exist."

Incidentally, in UN/CEFACT we have proposed as a hypothesis that all 
multi-party business scenarios can be decomposed into sets of two-
party interactions with all coordination activities being the 
*internal* responsibility of any party with dependent commitments 
with multiple other parties.

We have a set of test cases to explore:
(a) all-or-nothing orders with dependent requirements from multiple 
parties
(b) domestic and international shipping involving many parties
(c) distributed meeting-time negotiation.

(a) was completed at a meeting in Washington DC last week.
Documentation is in process.
(b) domestic shipping was sketched out informally at the same meeting.
(c) remains to be done.

Other test cases are welcome.

2. As a corollary, I am very skeptical of the examples that BPEL et 
al use for their multi-party business scenarios.  They seem to tailor 
them to demonstrate their multi-party choreography capabilities, 
rather than figuring out what is the best way to business.  As you 
write, the number of parties in the process, the more agreements need 
to be made, and lawyers will be involved in each agreement where 
money is riding on the wire.

3. I am very skeptical in general that the flavor of procedural 
workflow that is used for internal document-shuffling is suited to 
external business conversations.  RosettaNet tried it and abandoned 
it - exceptions got too tangled.  There is another style of workflow 
(conversational or action-workflow pioneered by Winograd et al) that 
is suitable for external conversations, but that's not the kind of 
software products that IBM et al want to repurpose.  Procedural 
workflow assumes command-and-control.  Wrong assumption.

4. I also like that you differentiate between internal implementation 
and external interface. BPEL says they handle both, and I haven't 
studied their stuff in enough detail yet, but they don't seem to 
differentiate clearly in their examples.

Thanks again for the stimulating article,
Bob Haugen







-----------------------------------------------------------------------------------
Post ID:3080
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-12-18 16:02:54
Subject:Re: [rest-discuss] Hypermedia workflow
Message:

Mark,

Interesting read.

I have a comment about the section on "Flow":

Is there really any need at all to declare that two services 
can be called in parallel, even in the way that you've outlined?  It 
would seem to go against the very nature of the web to *not* allow
two calls to be made in parallel, regardless of how it was declared.

In the example you gave, if the schema of the document that is 
POST-ed to the "Bank" partner required elements that would be returned 
from calls to the "Seller" and "Shipper" partners, wouldn't that be 
sufficient to, in essense, declare what the required flow would be?

Thanks.






-----------------------------------------------------------------------------------
Post ID:3081
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-18 16:19:03
Subject:Re: [rest-discuss] Re: Hypermedia workflow
Message:

On Wed, Dec 18, 2002 at 03:58:33PM -0000, bhaugen32 <bhaugen32@...> wrote:
> 1. I really like this part:
> "a critical point is that the choreography application model requires 
> that implementation details (the business process rules) be exposed 
> as part of the interface. This will make them very brittle should 
> they need to change, as well as drastically increasing the 
> coordination costs of implementing a multi-party process (since the 
> more parties that are in the process, the more agreement that will 
> need to be made). By keeping process implementation details hidden 
> behind the interface, none of those problems exist."
> 
> Incidentally, in UN/CEFACT we have proposed as a hypothesis that all 
> multi-party business scenarios can be decomposed into sets of two-
> party interactions with all coordination activities being the 
> *internal* responsibility of any party with dependent commitments 
> with multiple other parties.

I'm confident that a large number of scenarios can be so reduced, but
I'm not sure that all can.  For example, scenarios with fan-out
(pub/sub) or fan-in (multi-party rendezvous).  But perhaps you mean that
even fan-* can be abstracted as a two-party scenario, which is possible
since some party (likely third party) has to take responsibility for
providing the fan-in or fan-out point.  Have to think on that one ...

I agree with all your other observations too.

BTW, I meant to mention this in the paper;

http://www.ebpml.org/bpel4ws.htm

which I don't agree with completely, but it has some good observations,
including;

'However, "BeePEL" authors do not yet understand the concepts of "Business Transactions" and its necessity for business state alignment. They keep talking about callbacks and shy away from assembling messages into meaningful transactions which when successful guarantee state alignment: [...]'

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3082
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-18 16:25:24
Subject:Re: [rest-discuss] Hypermedia workflow
Message:

Hi Jeff,

On Wed, Dec 18, 2002 at 11:02:54AM -0500, Jeffrey Winter wrote:
> Mark,
> 
> Interesting read.
> 
> I have a comment about the section on "Flow":
> 
> Is there really any need at all to declare that two services 
> can be called in parallel, even in the way that you've outlined?  It 
> would seem to go against the very nature of the web to *not* allow
> two calls to be made in parallel, regardless of how it was declared.
> 
> In the example you gave, if the schema of the document that is 
> POST-ed to the "Bank" partner required elements that would be returned 
> from calls to the "Seller" and "Shipper" partners, wouldn't that be 
> sufficient to, in essense, declare what the required flow would be?

I didn't really understand their scenario, so can't respond to the
details of it.  But I'd say that any time a URI is exposed, that it's
automatically a valid state transition.  If it's exposed alongside
other URIs, then all of those URIs can be followed concurrently
(analogous to opening up a new browser window for each).  The point
I was trying to make was that if there aren't paths through the
application graph which can be followed concurrently, then the URIs
to that path should not be exposed until the predecessor paths are
completed.

I think some diagrams would help, but I haven't gotten to that.  Hmm,
I guess the "dot" stuff I set up for the RESTwiki could help with that.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3083
Sender:Jim Ancona <jim@...>
Post Date/Time:2002-12-18 17:11:09
Subject:Re: [rest-discuss] Time axis in GET: P2P and Media
Message:

S. Mike Dierken wrote:
> ----- Original Message -----
> From: "Mark Baker" <distobj@...>
> 
>>This is what KnowNow does, as I understand it, where each chunk is an
>>event notification.  I have no problem with it whatsoever, though from
>>an XML POV, it's slightly flawed because the composite stream (what you
>>get when you concatenate all the chunks) is not well-formed XML because
>>there's no "root container", like <event-stream> .. </event-stream>.
>>But I'm ok with that.
> 
> 
> Just grin & say they are 'xml fragments' and don't claim they are
> 'documents'.
> (I think Jabber is exactly the same - a stream of fragments. I don't know if
> they use a PI to separate the logical documents though)

If you want the XML chunks to be valid XML documents, you can separate 
one from another with a control character that is illegal in XML. I've 
seen form feed (U+000C) suggested.

Jim







-----------------------------------------------------------------------------------
Post ID:3084
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-18 17:46:20
Subject:Re: [rest-discuss] REST tidbits from XML 2002
Message:

Miles Sabin wrote:

> Ramin Firoozye wrote,
>
> >I talked to Amazon folks about this when they first came out with the
> >service. They support doing XSLT on the server (to my amazement -- it
> >opens up a whole can of worms I don't think they considered). No
> >support for installing extension functions on their servers, but with
> >the document() function, you can call external services via http
> >requests.
>
>
> They allow arbitrary user-supplied stylesheets to make arbitrary
> outgoing HTTP requests from their servers???!!!!
>
> Wow! That's an accident waiting to happen ... who needs a bunch of IRC
> zombies when you can hijack Amazons boxes for a DDoS.
>
> Paul, I suggest that until they fix it you _don't_ flag it up as an
> exemplar. Do you have a contact at Amazon?

Hijacking Amazon's boxes is not a "DDoS". You can at best launch one 
attack per connection from your box to Amazon's. All you've done is 
insert Amazon as an intermediary. You could have done the same with 
Babelfish. I'm not going to bug Amazon about this issue until I 
understand the danger myself. Babelfish has been doing GETs-on-my-behalf 
for several years. I can see how the feature could be very useful for 
combinign multiple information sources.

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:3085
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-12-18 18:37:32
Subject:Re: [rest-discuss] REST tidbits from XML 2002
Message:

Paul Prescod wrote,
> Hijacking Amazon's boxes is not a "DDoS". You can at best launch one
> attack per connection from your box to Amazon's. All you've done is
> insert Amazon as an intermediary.

The stylesheet might contain multiple uses of, or a loop over, the 
document function. That means that a single malicious client -> Amazon 
request could result in multiple Amazon -> victim requests. IOW Amazon 
executing the stylesheet could act as an amplifier (cp. smurf/fraggle). 
Not to mention the fact that Amazon has a much fatter pipe than your 
average script kiddie.

> You could have done the same with Babelfish. I'm not going to bug
> Amazon about this issue until I understand the danger myself.
> Babelfish has been doing GETs-on-my-behalf for several years.

I don't think you can persuade Babelfish to do multiple GETs on your 
behalf with just one GET of your own. If there's no amplification 
there's much less danger.

> I can see how the feature could be very useful for combinign multiple
> information sources.

Of course it's useful. But it's a sharp tool: use with care.

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:3086
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-12-18 18:55:12
Subject:ANN: Distributed Registry for Web Services
Message:

Hi Folks,

You are invited to participate in the collaborative development of a
distributed registry technology.

We have created a list (distributed-registry) for discussion of this
topic.  To subscribe to the list send an empty email to:

    distributed-registry-subscribe@yahoogroups.com

Here is a description of the purpose of a distributed registry:

A Web service registry provides information about what services do, and
how they are used. Today's Web service registries (e.g., UDDI and ebXML)
are implemented as centralized repositories. That is, all services store
their service descriptions within a single, or a small number of
registries. The purpose of this effort is to develop a concrete,
implementable architecture for a highly distributed registry. The notion
is that each Web service defines their own registry - comprised of the
collection of documents that describes the service. 

We have created a Web page which 
   - lists the design goals for a distributed registry, and 
   - proposes an architecture

Here's the URL to the Web page:

    http://www.xfront.com/dist-reg/distributed-registry.html

We invite you to participate in the development of this technology. 
Thanks!

           Roger L. Costello and David B. Jacobs







-----------------------------------------------------------------------------------
Post ID:3087
Sender:"bhaugen32 <bhaugen32@...>" <bhaugen32@...>
Post Date/Time:2002-12-18 22:30:25
Subject:Re: Hypermedia workflow
Message:

Mark Baker wrote:
> bhaugen32 <bhaugen32@y...> wrote:
> > in UN/CEFACT we have proposed as a hypothesis that all 
> > multi-party business scenarios can be decomposed into sets of two-
> > party interactions with all coordination activities being the 
> > *internal* responsibility of any party with dependent commitments 
> > with multiple other parties.
> 
> I'm confident that a large number of scenarios can be so reduced, 
but
> I'm not sure that all can.  

Well, I said "hypothesis".
But so far it's holding up pretty well,
and as you wrote it gets a lot more expensive
if and when it doesn't hold up.

> For example, scenarios with fan-out
> (pub/sub) or fan-in (multi-party rendezvous).  But perhaps you mean 
that
> even fan-* can be abstracted as a two-party scenario, which is 
possible
> since some party (likely third party) has to take responsibility for
> providing the fan-in or fan-out point.  Have to think on that 
one ...

Can you tell me a story about each of those scenarios so I can get in 
in my mind better?  Preferably a business scenario, since that is all 
I would claim, and preferably identifying the participants even if 
hypothetically by class?

And just to be clear, I'm not saying that multiple parties are not 
involved in some way, just that only two parties need to interact at 
a time, and all coordination between more than two parties is done as 
the internal responsibility of parties with multiple commitments with 
multiple other parties.

Here's another version of the hypothesis:
http://www.collaxa.com/news.blog.html#90008925
<quote>
Tuesday, December 03, 2002
Multi-Party Business Transactions - UNCEFACT White Papers - multiple
parties were involved in the whole scenario, but they interacted in
pairs and all coordination between dependent commitments was the
internal and private responsibility of only one party. Here are some 
of the reasons why: simplicity, accountability as [who] agreed to do 
exactly what for exactly whom, ...the more parties to a contract, the 
more parties have to agree on everything, ...economic commitments and 
events involve two and only two parties, security - need-to-know. 
Trading partners need to know about each other, but they rarely need 
to know what other partners each may have, and in many cases should 
not know even that others exist. Decoupling to avoid ripples of 
change - if parties A and B change their procedures, it may not 
affect parties C and D, unless all four parties are bound into the 
same contract. 

Collaxa's Take: +1. This design pattern also known as a star 
interaction pattern is very important for building "self healing" and 
adaptable distributed applications: managing exception is easier in a 
pair conversations. The same is true for version control.
Posted 11:32 AM by Edwin Khodabakchian
</quote>








-----------------------------------------------------------------------------------
Post ID:3088
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-19 01:18:49
Subject:Re: [rest-discuss] Re: Hypermedia workflow
Message:

On Wed, Dec 18, 2002 at 10:30:25PM -0000, bhaugen32 <bhaugen32@...> wrote:
> Can you tell me a story about each of those scenarios so I can get in 
> in my mind better?  Preferably a business scenario, since that is all 
> I would claim, and preferably identifying the participants even if 
> hypothetically by class?

An example of both fan-out and fan-in would be me invoking GET on a URI
identifying "my current net worth", which may not be stored in one
place.  So the GET gets fanned out to every party that I have any assets
with, and then responses then fan-in back.  The parties there would be
me, the parties holding my assets, plus an intermediary party who can
aggregate that information (optionally - it could just be software under
my control, or software that one of the other parties uses).

That's a bit of a weak fan-in example, since it's plain-vanilla
responses to a GET request (at least after the intermediary).  But you
could imagine responses being disconnected (via explicit correlation
rather than implicit correlation via the connection) from requests.

> Collaxa's Take: +1. This design pattern also known as a star 
> interaction pattern is very important for building "self healing" and 
> adaptable distributed applications: managing exception is easier in a 
> pair conversations. The same is true for version control.
> Posted 11:32 AM by Edwin Khodabakchian

That makes some sense.  I haven't given it much thought.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3089
Sender:"bhaugen32 <bhaugen32@...>" <bhaugen32@...>
Post Date/Time:2002-12-19 11:56:10
Subject:Re: Hypermedia workflow
Message:

Mark Baker wrote:
> An example of both fan-out and fan-in would be me invoking GET on a 
URI
> identifying "my current net worth", which may not be stored in one
> place.  So the GET gets fanned out to every party that I have any 
assets
> with, and then responses then fan-in back.  The parties there would 
be
> me, the parties holding my assets, plus an intermediary party who 
can
> aggregate that information (optionally - it could just be software 
under
> my control, or software that one of the other parties uses).

Where in that scenario do multiple parties actually interact?
I read:
* you interact with intermediary
* intermediary interacts with each asset-holder individually
* none of the asset-holders needs to even know about the others
* intermediary coordinates (sums) results
What am I missing?

> That's a bit of a weak fan-in example, since it's plain-vanilla
> responses to a GET request (at least after the intermediary).  But 
you
> could imagine responses being disconnected (via explicit correlation
> rather than implicit correlation via the connection) from requests.

How would this change the situation so that more than two parties 
would need to interact at a time?

-Bob Haugen







-----------------------------------------------------------------------------------
Post ID:3090
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-19 14:58:55
Subject:Re: [rest-discuss] Re: Hypermedia workflow
Message:

On Thu, Dec 19, 2002 at 11:56:10AM -0000, bhaugen32 <bhaugen32@...> wrote:
> Where in that scenario do multiple parties actually interact?
> I read:
> * you interact with intermediary
> * intermediary interacts with each asset-holder individually
> * none of the asset-holders needs to even know about the others
> * intermediary coordinates (sums) results
> What am I missing?

The intermediary could be an independant party.

Did you have some specific form of multi-party interaction that you
were looking for?

> > That's a bit of a weak fan-in example, since it's plain-vanilla
> > responses to a GET request (at least after the intermediary).  But 
> you
> > could imagine responses being disconnected (via explicit correlation
> > rather than implicit correlation via the connection) from requests.
> 
> How would this change the situation so that more than two parties 
> would need to interact at a time?

It wouldn't, it would just better illustrate fan-in.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3091
Sender:"bhaugen32 <bhaugen32@...>" <bhaugen32@...>
Post Date/Time:2002-12-19 16:11:04
Subject:Re: Hypermedia workflow
Message:

Mark Baker wrote:
> The intermediary could be an independant party.

But the interactions are still pairwise, no?
* You<->intermediary
* intermediary<->each asset-holder

> Did you have some specific form of multi-party interaction that you
> were looking for?

Not really.  Trying to cover the waterfront of business interactions.

I'm ready to admit exceptions to the pairwise hypothesis, but do want 
to catalog them and figure out the costs as far as possible for 
survey-level depth-of-thinking.







-----------------------------------------------------------------------------------
Post ID:3092
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-19 18:09:55
Subject:Re: [rest-discuss] Re: Hypermedia workflow
Message:

On Thu, Dec 19, 2002 at 04:11:04PM -0000, bhaugen32 <bhaugen32@...> wrote:
> Mark Baker wrote:
> > The intermediary could be an independant party.
> 
> But the interactions are still pairwise, no?
> * You<->intermediary
> * intermediary<->each asset-holder

Yah, I was just giving an example of fan-out and fan-in, not suggesting
that this particular example couldn't be reduced to a series of
pairwise interactions.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3093
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-12-19 18:15:37
Subject:query as part of the URI? (was: Re: [rest-discuss] Representation format as part of URIs?)
Message:

*whew* now I can get rid of a draft response that says the same thing (only
yours illustrated it better).  I had an additional thought on this...

What if we were to let the server report back to the client what it thinks
constitutes the part that identifies it and the part that doesn't?  For
instance, suppose you were to do a GET on:

    http://sample.org/foo?bar

When getting the response, the server returned headers something like:

Location: http://sample.org/foo
Query: bar
Varies: Query

In this case, it is saying that the value of Location is the URI that
identifies the resource.  The query string is stored in another header so
that the Varies header can indicate it for caching purposes, etc.

Of course, my understanding of HTTP headers has only recently into Varies,
Location, etc., so this may not be an appropriate way of handling this.
Just a thought...

---
Seairth Jacobs
seairth@...

----- Original Message -----
From: "Miles Sabin" <miles@...>
To: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Wednesday, December 18, 2002 5:00 AM
Subject: Re: [rest-discuss] Representation format as part of URIs?


> Roy T. Fielding wrote,
> > > 2396 is not clear about that. It says:
> > >
> > > "3.4. Query Component
> > >
> > >    The query component is a string of information to be interpreted
> > >    by the resource."
> >
> > Yes, but it doesn't say that the resource is identified by what comes
> > before the query component.
>
> True, but puzzling.
>
> If the resource is identified by the whole URI then,
>
> 1. http://www.example.com/foo?bar
>
> and,
>
> 2. http://www.example.com/foo?baz
>
> identify two distinct resources R1 and R2, in which case there doesn't
> seem to be very much "interpretation" to be done: "?bar" is encoded
> into the identifier for R1 and "?baz" is encoded into the identifier
> for R2, so any further inspection of the query component by either
> resource would be redundant.
>
> Whatever the currently preferred understanding of the relationship
> between URIs, resources and representations, 3.4 only really makes any
> sense if we treat the prefix,
>
>    http://www.example.com/foo
>
> as identifying a _process_ and the query component as specifying an
> argument to be provided to that process.
>
> But that pretty clearly isn't your currently preferred understanding,
> which, even if it's not strictly speaking inconsistent with 3.4,
> certainly seems to be in tension with it. So maybe 3.4 needs tweaking?
>
> Cheers,
>
>
> Miles
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>







-----------------------------------------------------------------------------------
Post ID:3094
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-19 20:01:02
Subject:REST toolkit
Message:

I have no problem whatsoever with people making toolkits that make it 
easier to program in the REST style. I've got my own little toolkit that 
I use for simple Python projects where Zope etc. are overkill. But here 
is where I get nervous: a toolkit that helps people use HTTP as it was 
designed to be used is an HTTP toolkit. Perhaps it is a _better_ HTTP 
toolkit than the ones that exist, but it is still an HTTP toolkit. 
Phil's example code is a perfect example of using HTTP right. I won't 
argue if Phil calls it a REST toolkit but I don't see a clear boundary 
between "good" HTTP toolkits and REST toolkits. When an HTTP toolkit 
strays from REST it is probably just a misunderstanding by the toolkit's 
author and we should probably work with them to correct it.

Also, some people probably think that REST toolkit would embed a bunch 
of XML smarts. This stems from the confusion that REST is about using 
XML over HTTP. I don't think Phil has this confusion but I bet many 
people asking for REST toolkits do!

  Paul Prescod







-----------------------------------------------------------------------------------
Post ID:3095
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-12-19 20:27:47
Subject:Re: [rest-discuss] REST toolkit
Message:


Paul Prescod wrote:

>I have no problem whatsoever with people making toolkits that make it 
>easier to program in the REST style. I've got my own little toolkit that 
>I use for simple Python projects where Zope etc. are overkill. But here 
>is where I get nervous: a toolkit that helps people use HTTP as it was 
>designed to be used is an HTTP toolkit. Perhaps it is a _better_ HTTP 
>toolkit than the ones that exist, but it is still an HTTP toolkit. 
>Phil's example code is a perfect example of using HTTP right. I won't 
>argue if Phil calls it a REST toolkit but I don't see a clear boundary 
>between "good" HTTP toolkits and REST toolkits. When an HTTP toolkit 
>strays from REST it is probably just a misunderstanding by the toolkit's 
>author and we should probably work with them to correct it.
>
I agree.  But given existing bad habits and the lack of understanding of 
what REST really is (protocol vs style), I think "RESTful HTTP toolkit" 
or "REST-compliant HTTP toolkit" would be better terminology.

--Chuck


>
>Also, some people probably think that REST toolkit would embed a bunch 
>of XML smarts. This stems from the confusion that REST is about using 
>XML over HTTP. I don't think Phil has this confusion but I bet many 
>people asking for REST toolkits do!
>
>  Paul Prescod
>
>
>
>To unsubscribe from this group, send an email to:
>rest-discuss-unsubscribe@yahoogroups.com
>
> 
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
>
>
>








-----------------------------------------------------------------------------------
Post ID:3096
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-12-19 20:45:14
Subject:Re: [rest-discuss] REST toolkit
Message:

From: "Chuck Hinson" <cmhinson@...>
>
> I agree.  But given existing bad habits and the lack of understanding of
> what REST really is (protocol vs style), I think "RESTful HTTP toolkit"
> or "REST-compliant HTTP toolkit" would be better terminology.

I would suggest something like "REST-oriented" instead of "REST-compliant".
I'm afraid that people would interpret "compliant" to mean "if the toolkit
allows me to do it, then it is RESTful", which we certainly don't want
people thinking.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:3097
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-19 20:49:19
Subject:Re: [rest-explore] simple implementation on network based application using java ?
Message:

----- Original Message -----
From: "Mike Beedle" <beedlem@...>

>
> b) that these tools would give the developer
> facilities to interact with other architectural
> services like logging, persistence, messaging,
> etc.; out of the box
If you are a java programmer, I'd recommend Tomcat (Servlet engine) or JBoss
(J2EE/EJB/JDBC/JMS/log4j/etc.).
There are some toolkits in the J2EE arena that I suspect are not very REST
aligned (like struts, but I don't want to say anything negative without real
investigation) but if you have read the 'REST for Dummies' book and 'REST
Zen in 27.3 days' (what? nobody has written those yet?) you should be fine
with these powerful tools.
The toolkit that I want is a client rather than a server - I'm alreay very
familiar with the server environments available and they work for me just
fine. The java based clients feel too 'protocol' level though. I suppose all
I really want is a set of really good Java classes for MIME packaged content
(including multi-part, with XML support, etc.)

>
> In other words, REST-specific tools in programming
> languages that unlike the tools you list above,
> would greatly expedite the development of
> applications using the REST style.

REST is more about good design than about specific programming.
Just as with an RDBMS and SQL, regardless of the ease or completeness of the
tools and servers, you can still create the query from hell, or have tables
that are not normalized enough (or too normalized), or poor queries, and so
on. A book showing good design and good queries will do more for SQL/RDBMS
than a toolkit or API. Some things - like connection pooling and
authentication - definitely make sense for language and API and language
level toolkits.








-----------------------------------------------------------------------------------
Post ID:3098
Sender:"Roy T. Fielding" <fielding@...>
Post Date/Time:2002-12-19 22:29:46
Subject:Re: [rest-discuss] Representation format as part of URIs?
Message:

> But that pretty clearly isn't your currently preferred understanding,
> which, even if it's not strictly speaking inconsistent with 3.4,
> certainly seems to be in tension with it. So maybe 3.4 needs tweaking?

That's already on the issues list due to a couple other issues.

....Roy







-----------------------------------------------------------------------------------
Post ID:3099
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-12-20 02:32:50
Subject:Re: [rest-discuss] REST toolkit
Message:

I would just say "it's REST" and leave it at that.  Afterall, you don't say
that
your house is "Victorian-compliant", "Victorian-oriented", although you
might
say it's "Craftsman-style".  Me, I live in a Victorian.

Walden

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>
To: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Thursday, December 19, 2002 3:45 PM
Subject: Re: [rest-discuss] REST toolkit


> From: "Chuck Hinson" <cmhinson@...>
> >
> > I agree.  But given existing bad habits and the lack of understanding of
> > what REST really is (protocol vs style), I think "RESTful HTTP toolkit"
> > or "REST-compliant HTTP toolkit" would be better terminology.
>
> I would suggest something like "REST-oriented" instead of
"REST-compliant".
> I'm afraid that people would interpret "compliant" to mean "if the toolkit
> allows me to do it, then it is RESTful", which we certainly don't want
> people thinking.
>
> ---
> Seairth Jacobs
> seairth@...
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:3100
Sender:"Donald Ball" <dball@...>
Post Date/Time:2002-12-20 16:00:39
Subject:Re: [rest-discuss] REST toolkit
Message:

On 12/19/2002 at 12:01 PM Paul Prescod wrote:

>I have no problem whatsoever with people making toolkits that make it 
>easier to program in the REST style. I've got my own little toolkit that 
>I use for simple Python projects where Zope etc. are overkill. But here 
>is where I get nervous: a toolkit that helps people use HTTP as it was 
>designed to be used is an HTTP toolkit. Perhaps it is a _better_ HTTP 
>toolkit than the ones that exist, but it is still an HTTP toolkit. 
>Phil's example code is a perfect example of using HTTP right. I won't 
>argue if Phil calls it a REST toolkit but I don't see a clear boundary 
>between "good" HTTP toolkits and REST toolkits. When an HTTP toolkit 
>strays from REST it is probably just a misunderstanding by the toolkit's 
>author and we should probably work with them to correct it.

I think a REST advocacy group is a great idea in theory, but I fear it
wouldn't accomplish much in the real world without a lot of very patient
and persuasive advocates. Most developers don't seem to care that much that
their software doesn't work according to these abstract principles -
they're trying to get work done in the real world.

For example, the apache tomcat servlet engine breaks REST in at least one
way. Just like in apache httpd, you can associate error pages with http
error response codes to present the user with something more elegant and
site-specific than the generic server-generated error content (the
error-page element of the web.xml deployment descriptor). Unlike apache
httpd, when tomcat returns that error content, it attaches a status code of
200 instead of the original error code! Thus, 404 responses aren't noted as
such by search engines, proxy servers, et. al. because they're rewritten as
200 responses. I've been trying for days now to get the tomcat developers
to acknowledge the bug, but so far they've ignored it.

(If anyone wants to vote for this bug, it's
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15406)

It would seem that the developers either don't agree that it's a bug, or
don't think it's a bug that's worth fixing. Either way, I'm not sure how to
proceed.

Another example might be apache struts. Struts heavily uses the
RequestDispatcher servlet api to internally forward requests to different
components. In and of itself that's not a bad thing, but struts uses it to
such a degree that the "URL" of a given page and the contents of that page
may have no relation to one another. It also seems to encourage developers
to use the HttpSession object to store conversational state, which is
problematic from a REST point of view.

Fixing struts to be RESTful would require a serious amount of work, and I
guess I doubt that the developers could be convinced that it would be a
worthwhile investment. (which is very much too bad, since struts seems to
be very popular as a webapp infrastructure.)

Any suggestions for addressing either these specific instances or the
general problem?

- donald







-----------------------------------------------------------------------------------
Post ID:3101
Sender:Seth Ladd <seth@...>
Post Date/Time:2002-12-20 16:36:07
Subject:Re: [rest-discuss] REST toolkit
Message:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


| Any suggestions for addressing either these specific instances or the
| general problem?

One of the first things we'll have to do is fix browsers to be more
RESTful.  For instance, they only GET and POST w/ ease right now.  That
is one of the reasons Struts works the way it does.  It must work with
its clients.

A big gain for REST will come when XForms arrives.  I hope the actions
of PUT and DELETE will work with XForms.  If so, browsers will become
much more capable to work in RESTful environments.

Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+A0b2Nx3GJTf/82URAt3/AJ0dVsm8ih/YSzFNKpF76aZYHhIE1ACfZTBp
qcinWtEzidytEKJgCUIbLVw=
=TexD
-----END PGP SIGNATURE-----







-----------------------------------------------------------------------------------
Post ID:3102
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-12-20 18:45:23
Subject:Re: [rest-discuss] REST toolkit
Message:

From: "Donald Ball" <dball@...>
>
> Most developers don't seem to care that much that
> their software doesn't work according to these abstract principles -
> they're trying to get work done in the real world.

If anything, I think that most developers are not aware of those principals.
The "bug" in tomcat may be more of an indication that its developers are not
fully aware of those principals rather than being aware of them and choosing
to ignore them.  To imply that working according to these abstract
principles means one cannot "get work done in the real world" is just plain
wrong.  That would  be equatable to saying you don't care much about design
patterns in programming becuase you need to get work done in the real world.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:3103
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-20 18:53:40
Subject:Re: [rest-discuss] REST toolkit
Message:

----- Original Message -----
From: "Seairth Jacobs" <seairth@...>

> The "bug" in tomcat may be more of an indication that its developers are
not
> fully aware of those principals rather than being aware of them and
choosing
> to ignore them.
I vaguely remember looking into that & seeing a dependency on another
component somewhere that broke things when a non-200 response code was
present. But I might be mis-remembering it.
Also, MS's Internet Explorer does a handy job of hiding error pages with
'friendly error' pages - so developers that want control over look & feel
are pushed toward using 200 OK for everything.






-----------------------------------------------------------------------------------
Post ID:3104
Sender:"Donald Ball" <dball@...>
Post Date/Time:2002-12-20 19:15:46
Subject:Re: [rest-discuss] REST toolkit
Message:

On 12/20/2002 at 1:45 PM Seairth Jacobs wrote:

>From: "Donald Ball" <dball@...>
>>
>> Most developers don't seem to care that much that
>> their software doesn't work according to these abstract principles -
>> they're trying to get work done in the real world.
>
>If anything, I think that most developers are not aware of those
>principals.
>The "bug" in tomcat may be more of an indication that its developers are
>not
>fully aware of those principals rather than being aware of them and
>choosing
>to ignore them.  To imply that working according to these abstract
>principles means one cannot "get work done in the real world" is just
plain
>wrong.  That would  be equatable to saying you don't care much about
design
>patterns in programming becuase you need to get work done in the real
>world.

I don't mean to imply that working according to those abstract design
principles means you can't get work done in the real world - I'm just
trying (poorly?) to put myself in the shoes of the developers of non
RESTful web infrastructures. In the case of jakarta struts, I don't know
that the position is entirely indefensible. Would the developers get more
payoff from refactoring struts to adhere to REST design principles, or
from, I dunno, adding some new whizbang feature? Probably the latter, at
least from the point of view of their employers.

- donald







-----------------------------------------------------------------------------------
Post ID:3105
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-20 20:13:56
Subject:Re: [rest-discuss] REST toolkit
Message:

----- Original Message -----
From: "Donald Ball" <dball@...>

> I don't mean to imply that working according to those abstract design
> principles means you can't get work done in the real world - I'm just
> trying (poorly?) to put myself in the shoes of the developers of non
> RESTful web infrastructures. In the case of jakarta struts, I don't know
> that the position is entirely indefensible. Would the developers get more
> payoff from refactoring struts to adhere to REST design principles, or
> from, I dunno, adding some new whizbang feature? Probably the latter, at
> least from the point of view of their employers.
>
Another thing to consider in the case of Struts is that it is meant more for
web-based user interface purposes than pure information access purposes. The
existing technology and needs of user interface apps make it hard to apply
REST principles or gain the benefits that a pure information based app
typically gets.
So, I think there are some things Struts could do to make apps built with it
more capable, but I wouldn't push it too far since I believe the needs and
goals are different.






-----------------------------------------------------------------------------------
Post ID:3106
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-12-20 20:31:10
Subject:Re: [rest-discuss] REST toolkit
Message:

----- Original Message -----
From: "S. Mike Dierken" <mdierken@...>
To: <rest-discuss@yahoogroups.com>
Sent: Friday, December 20, 2002 3:13 PM
Subject: Re: [rest-discuss] REST toolkit


> The
> existing technology and needs of user interface apps make it hard to apply
> REST principles or gain the benefits that a pure information based app
> typically gets.

This confused me, S. Mike.  If REST is a distillation of what makes the
current
Web work, and the current web is largely if not entirely driven by
browser-to-
website interactions (where the browser is the UI), then why should it be
"hard"
to apply REST principals to that?

Walden








-----------------------------------------------------------------------------------
Post ID:3107
Sender:Jeff Bone <jbone@...>
Post Date/Time:2002-12-20 20:35:38
Subject:Ignoring Opacity for Fun and Profit
Message:

Craig Johnson (via Udell) on meaningful URI and URI (de)construction by 
humans...  lending more credence to the notion that URI should be 
(de)constructable.

	http://weblog.infoworld.com/udell/2002/12/20.html#a552

jb







-----------------------------------------------------------------------------------
Post ID:3108
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-20 20:47:29
Subject:Re: [rest-discuss] REST toolkit
Message:

----- Original Message -----
From: "Walden Mathews" <waldenm@...>
>
> > The
> > existing technology and needs of user interface apps make it hard to
apply
> > REST principles or gain the benefits that a pure information based app
> > typically gets.
>
> This confused me, S. Mike.  If REST is a distillation of what makes the
current
> Web work, and the current web is largely if not entirely driven by
browser-to-
> website interactions (where the browser is the UI), then why should it be
"hard"
> to apply REST principals to that?

Because the principles are generally ignored for short term gain. When they
are not ignored, great things happen - that was the insight that generated
the summary of the principles. REST is not a distillation of what is
/popular/ but what worked well.
For example, using Flash satisfies many user interface needs, but often does
not employ the simple aspects of REST that most people recognize
(hyperlinking). Java servlet based session IDs are a convenience for
programmers, but a pain for usability - this continues to be popular even
though it isn't close to being REST aware due to the fact that it does
indeed solve certain problems.
The existing tools - browsers, cookies, javascript, sessions, etc. etc. -
solve real issues with human interface based applications at the cost of
sometimes not being RESTful. Trying to bend existing tools and practices
won't work in my opinion. I favor working on automation based applications
for the application of REST - essentially the same problem space as SOAP
based Web Services.









-----------------------------------------------------------------------------------
Post ID:3109
Sender:Vincent D Murphy <vdm@...>
Post Date/Time:2002-12-21 04:41:33
Subject:Re: [rest-discuss] REST toolkit
Message:

S. Mike Dierken wrote:
> Also, MS's Internet Explorer does a handy job of hiding error
> pages with 'friendly error' pages - so developers that want
> control over look & feel are pushed toward using 200 OK
> for everything.

no offence intended, but this is bogus.

http://www.google.com/search?q=internet+explorer+200+friendly
http://www.oreillynet.com/cs/user/view/wlg/1983
http://support.microsoft.com/default.aspx?scid=KB;en-us;q294807

you can sniff the user-agent header and pad your response to >n bytes
where n is an entry in internet explorer's registry area indexed on the
reponse code.  generalising, you can pad to >512 bytes and internet
explorer will display the entity response you returned unmolested.  YMMV.

no doubt about it though, the 'user-friendly error' 'feature' is totally
brain damaged (IMNSHO).  thankfully they left a (quick/dirty/cheap) way
for you to escape it.

ATB,
-vincent







-----------------------------------------------------------------------------------
Post ID:3110
Sender:Duncan Wilcox <duncan@...>
Post Date/Time:2002-12-24 12:18:43
Subject:Future proof
Message:

I have recently been working on a REST interface for a set of services, 
exchanging mainly service configuration documents.

In reading recent blogging about the power of unintended, unexpected 
use and combination of web resources (as opposed to contractualized 
RPC), it has occurred to me that I might be "limiting creativity" by 
how I handle documents.

On the PUT of a service configuration expressed as XML, I currently 
extract the data I know about (or return an error), and store only the 
valid, known configuration.

I remember reading on this list (if I'm not mistaken), that PUT should 
store the document as is, and you should be able to retrieve the 
unchanged document through a GET.

I suspect that along with a reasonable path design, this is one of the 
keys to making a REST interface future proof and usable beyond the 
initial expectations.

If this assumption is correct I guess I should fix my interface, 
however there different problems for different solutions:

- always return an error if the document isn't strictly what I want 
(i.e. if the XML contains unexpected tags)

- return an error only when the subset of the document I currently 
support isn't what I want, extract relevant part for service 
configuration purposes, store the whole document for a later GET

The rationale for the first solution is to preserve the expectation 
that you will GET what you PUT, however it also seems to swing the 
interface towards a rigidly defined RPC direction.

Solution 2 would be better, I guess it would allow the user to store 
her own extra tidbits without ever needing to let me know about it, but 
it doesn't seem to be very future proof in that I might want to use 
portions of the document structure for myself in later versions. In the 
specific case of configuration documents in XML, there could be 
conflict of tags, and I'd rather take a monastic approach to the use of 
XML namespaces (limit their use, that is).

Ideas appreciated.

Thanks,
Duncan

--
http://duncan.focuseek.com







-----------------------------------------------------------------------------------
Post ID:3111
Sender:Joe Gregorio <joe@...>
Post Date/Time:2002-12-24 14:26:13
Subject:Re: [rest-discuss] Future proof
Message:

Duncan Wilcox wrote:
> I have recently been working on a REST interface for a set of services, 
> exchanging mainly service configuration documents.
> 
> In reading recent blogging about the power of unintended, unexpected 
> use and combination of web resources (as opposed to contractualized 
> RPC), it has occurred to me that I might be "limiting creativity" by 
> how I handle documents.
> 
> On the PUT of a service configuration expressed as XML, I currently 
> extract the data I know about (or return an error), and store only the 
> valid, known configuration.
> 
> I remember reading on this list (if I'm not mistaken), that PUT should 
> store the document as is, and you should be able to retrieve the 
> unchanged document through a GET.
> 
> I suspect that along with a reasonable path design, this is one of the 
> keys to making a REST interface future proof and usable beyond the 
> initial expectations.
> 
> If this assumption is correct I guess I should fix my interface, 
> however there different problems for different solutions:
> 
> - always return an error if the document isn't strictly what I want 
> (i.e. if the XML contains unexpected tags)
> 
> - return an error only when the subset of the document I currently 
> support isn't what I want, extract relevant part for service 
> configuration purposes, store the whole document for a later GET
> 

I took the second approach in the implementation of RESTLog.
How that extensibility works is explained here:
http://wellformedweb.org/RESTLog.cgi/17

> The rationale for the first solution is to preserve the expectation 
> that you will GET what you PUT, however it also seems to swing the 
> interface towards a rigidly defined RPC direction.
> 
> Solution 2 would be better, I guess it would allow the user to store 
> her own extra tidbits without ever needing to let me know about it, but 
> it doesn't seem to be very future proof in that I might want to use 
> portions of the document structure for myself in later versions. In the 
> specific case of configuration documents in XML, there could be 
> conflict of tags, and I'd rather take a monastic approach to the use of 
> XML namespaces (limit their use, that is).

In this case I am just re-using the work already done in 
using namespaces in RSS 1.0 and 2.0 which is fairly stable. YMMV.

	-joe

-- 
http://BitWorking.org
http://WellFormedWeb.org







-----------------------------------------------------------------------------------
Post ID:3112
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-12-24 15:12:04
Subject:Re: [rest-discuss] Future proof
Message:

> > I remember reading on this list (if I'm not mistaken), that PUT should 
> > store the document as is, and you should be able to retrieve the 
> > unchanged document through a GET.

Reading that on this list doesn't make it true.  This is not clear in the
language of 2616, and so I question its status as "standard".  Generally,
resources, according to REST, are functions that map time to values,
and there are no constraints in REST saying that resource values may
only be changed via the HTTP interface.

If someone can find, somewhere in the body of standards, clear
language to the effect that the resource implementation is expected to
store a PUT value in bit-literal form, and that a subsequent GET on
a resource that has suffered a PUT at some time in its life is required
to serve out bit-literal representations...

If someone finds that, would they please give me a pointer?

Walden







-----------------------------------------------------------------------------------
Post ID:3113
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-12-24 20:40:13
Subject:Re: [rest-discuss] Future proof
Message:

Chuck,

Thanks for the reference to the Roy message.

I see two issues here, worth separating.  There is the notion of a resource
capable of delivering out a variety of different representations at a single
point in time, that variety being the space in which content negotiation may
take place.

There is another issue, closer to "equivalence" (which causes trouble in
other areas as well, it seems.  I PUT this representation to this URI, and
it
replaces any existing representations.  That means that upon the completion
of PUT, that resource has but one representation.

But when we say "one representation", we're not also spelling out the
rules for what would distinguish one from two.  If characters are present,
does case matter?  ASCII or other?  If the representation consists of a
"bag" of things, does literality force an unintended ordering on that?  And
so on.

When Roy says that 2616 "PUT" method specifies that PUT obliterates
variance of representation, I believe the language of 2616 reasonably
supports his assertion.  If he were asserting that 2616 PUT method specifies
literality, I'd have to say that my careful readings so far can't find that.

There's another problem here, in that the great majority of web application
developers don't have access to Roy to to his email conversations, and
so those resources don't quality as part of the standard, unfortunately.
We need to approach that problem with care, I think.

Walden

----- Original Message -----
From: "Chuck Hinson" <cmhinson@...>
To: "Walden Mathews" <waldenm@...>
Sent: Tuesday, December 24, 2002 11:35 AM
Subject: Re: [rest-discuss] Future proof


>
>
> Walden Mathews wrote:
>
> >>>I remember reading on this list (if I'm not mistaken), that PUT should
> >>>store the document as is, and you should be able to retrieve the
> >>>unchanged document through a GET.
> >>>
> >
> >Reading that on this list doesn't make it true.  This is not clear in the
> >language of 2616, and so I question its status as "standard".  Generally,
> >resources, according to REST, are functions that map time to values,
> >and there are no constraints in REST saying that resource values may
> >only be changed via the HTTP interface.
> >
> >If someone can find, somewhere in the body of standards, clear
> >language to the effect that the resource implementation is expected to
> >store a PUT value in bit-literal form, and that a subsequent GET on
> >a resource that has suffered a PUT at some time in its life is required
> >to serve out bit-literal representations...
> >
> It's not quite that limiting strict.  The interpretation presented
> earlier on this list was that given no intervening operations between a
> PUT and a GET (and assuming no other mechanism changes the resource's
> state),  a GET should return the exact representation submitted by the
> immediately previous PUT.  Note, however,  that once a representation
> has been PUT, there's nothing that says the state of the resource can't
> be changed by some other means.
>
> >
> >If someone finds that, would they please give me a pointer?
> >
>
> We can certainly argue about what the spec actually says vs what one or
> more of it's authors intended . However, Roy Fielding has made at least
> one statement[1] that I (and I believe others) interpret to mean what I
> stated above.
>
> [1] http://lists.w3.org/Archives/Public/uri/2002Sep/0046.html
>
> --Chuck
>
>
>







-----------------------------------------------------------------------------------
Post ID:3114
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-12-25 13:45:12
Subject:RE: [rest-discuss] Future proof
Message:

However,

Roy never answered to my response ([1]), so I really think we are far from
fully understanding how PUT relates to GET. So far, I haven't seen a
convincing argument why PUT can't be symmetric to GET (setting specific
representations). However I agree that it's probably better to assign
distinct URIs to each variant (making authoring of them more
straightforward), but I fail to see where RFC2616 (as published!) requires
this.

Julian


[1] <http://lists.w3.org/Archives/Public/uri/2002Sep/0047.html>

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@...]
> Sent: Tuesday, December 24, 2002 9:40 PM
> To: cmhinson@...
> Cc: rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Future proof
>
>
> Chuck,
>
> Thanks for the reference to the Roy message.
>
> I see two issues here, worth separating.  There is the notion of
> a resource
> capable of delivering out a variety of different representations
> at a single
> point in time, that variety being the space in which content
> negotiation may
> take place.
>
> There is another issue, closer to "equivalence" (which causes trouble in
> other areas as well, it seems.  I PUT this representation to this URI, and
> it
> replaces any existing representations.  That means that upon the
> completion
> of PUT, that resource has but one representation.
>
> But when we say "one representation", we're not also spelling out the
> rules for what would distinguish one from two.  If characters are present,
> does case matter?  ASCII or other?  If the representation consists of a
> "bag" of things, does literality force an unintended ordering on
> that?  And
> so on.
>
> When Roy says that 2616 "PUT" method specifies that PUT obliterates
> variance of representation, I believe the language of 2616 reasonably
> supports his assertion.  If he were asserting that 2616 PUT
> method specifies
> literality, I'd have to say that my careful readings so far can't
> find that.
>
> There's another problem here, in that the great majority of web
> application
> developers don't have access to Roy to to his email conversations, and
> so those resources don't quality as part of the standard, unfortunately.
> We need to approach that problem with care, I think.
>
> Walden
>
> ----- Original Message -----
> From: "Chuck Hinson" <cmhinson@...>
> To: "Walden Mathews" <waldenm@...>
> Sent: Tuesday, December 24, 2002 11:35 AM
> Subject: Re: [rest-discuss] Future proof
>
>
> >
> >
> > Walden Mathews wrote:
> >
> > >>>I remember reading on this list (if I'm not mistaken), that
> PUT should
> > >>>store the document as is, and you should be able to retrieve the
> > >>>unchanged document through a GET.
> > >>>
> > >
> > >Reading that on this list doesn't make it true.  This is not
> clear in the
> > >language of 2616, and so I question its status as "standard".
> Generally,
> > >resources, according to REST, are functions that map time to values,
> > >and there are no constraints in REST saying that resource values may
> > >only be changed via the HTTP interface.
> > >
> > >If someone can find, somewhere in the body of standards, clear
> > >language to the effect that the resource implementation is expected to
> > >store a PUT value in bit-literal form, and that a subsequent GET on
> > >a resource that has suffered a PUT at some time in its life is required
> > >to serve out bit-literal representations...
> > >
> > It's not quite that limiting strict.  The interpretation presented
> > earlier on this list was that given no intervening operations between a
> > PUT and a GET (and assuming no other mechanism changes the resource's
> > state),  a GET should return the exact representation submitted by the
> > immediately previous PUT.  Note, however,  that once a representation
> > has been PUT, there's nothing that says the state of the resource can't
> > be changed by some other means.
> >
> > >
> > >If someone finds that, would they please give me a pointer?
> > >
> >
> > We can certainly argue about what the spec actually says vs what one or
> > more of it's authors intended . However, Roy Fielding has made at least
> > one statement[1] that I (and I believe others) interpret to mean what I
> > stated above.
> >
> > [1] http://lists.w3.org/Archives/Public/uri/2002Sep/0046.html
> >
> > --Chuck
> >
> >
> >
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:3115
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-26 00:34:20
Subject:Re: [rest-discuss] Future proof
Message:

----- Original Message -----
From: "Julian Reschke" <julian.reschke@...>

> However I agree that it's probably better to assign
> distinct URIs to each variant (making authoring of them more
> straightforward),
With different URIs you'll need to discover those URIs through a response
against a different URI. And what is this 'primary' URI supposed to mean?
Should all content negotiation continue to use Accept headers against this
primary URI and have the response provide a Location header for the
representation format identified by the Content-Type response header? Will
intermediaries understand this?







-----------------------------------------------------------------------------------
Post ID:3116
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-12-26 15:52:13
Subject:A Simple Extension of the Current Web Architecture to Support the Next Generation Web Services
Message:

Hi Folks,

Below I describe a simple technique for evolving the current HTML-based
Web service architecture to support the next generation Web services. 
The approach is RESTful.  That is, it capitalizes on the current Web
architecture. I would be very interested in your thoughts.

Consider what is involved in setting up a Web site today.  I will take
my Web site as an example.  Creating my Web site was really
straightforward - I created an HTML page that contained the content, and
in the header section of the HTML I added a <meta> tag to provide
subject and category metadata.  In a short period of time many different
search engines had indexed and categorized my Web site.  Further, over
time other Web sites have linked to my Web site.

My Web site is a Web service, in its simplest form.  It is an HTML-based
Web service.  It provides an information service to Web clients.  My
service has metadata.  

Today's Web service architectural model has three key ingredients -
content, metadata, and search engines (matchmakers).  This architectural
model has many wonderful properties:

1. It is massively scalable.
2. It is a completely distributed architecture.
3. It is a lightweight architecture - just build a Web service and
you're done.
4. Standard Web components are used - URIs to identify a Web service,
the HTTP verbs (GET, PUT, POST, DELETE) to access and manipulate the
service.
5. Tremendous interconnectedness - others link to my Web service and I
can link to other Web services.  Recall Metcalf's Law which states that
the value of a networked system is related exponentially to the amount
of interconnections.
6. A wonderful side-effect of the architecture is a whole search engine
cottage industry has been created.  This is because the Web services are
decoupled from the search engines. 

Since the current Web architecture has been so successful, it seems
reasonable to use that architecture at least as the starting point for
the next generation of Web services.  Here's how the next generation Web
services would operate if we simply apply the current approach:  

    A client invoking a next generation Web service will receive 
    SOAP or XML or XML-RPC content, with metadata bundled into the 
    response (analogous to today where the client receives 
    HTML content with metadata bundled in).

However, there is a problem with simply applying the current approach to
the next generation of Web services: 

    The next generation Web services will be a lot more complicated,
    so the metadata will need to be a lot more involved, i.e.,
    bigger.  You don't want clients to be forced to receive an 
    extensive description of everything the service does and all the 
    instructions on how to use the service every time they use a 
    Web service.  The first time they use it they will want to 
    view the service description metadata but from then on they 
    will not.

So we probably want to keep the metadata and the service representation
separate.  This has the additional benefit of flexibility with regards
to the format of the metadata - it could be expressed as RDF or DAML or
OWL or even XHTML.

However, keeping the metadata separate from the service representation
then introduces a problem: 

    - if a client has the URL to a service, how does the client
      locate the metadata for the service?
    - alternatively, if the client has the URL to the metadata,
      how does the client locate the service?

This is solved very simply by introducing two new HTTP headers:

    - The Meta-Location HTTP header provides the URL to the metadata
    - The Meta-About HTTP header provides the URL to the service.

That's it!  With these simple changes we can extend the current
(HTML-based) Web services architecture to meet the challenges of the
next generation Web services.  Let's review what changes are made to the
current Web services architecture:

1. Separate the metadata from the service representation 
2. A URL to a Web service results in returning a representation of the
service.  The HTTP header contains Meta-Location, which provides the URL
to the service's metadata.
3. A URL to the metadata results in returning a representation of the
metadata.  The HTTP header contains Meta-About, which provides the URL
to the service.

This approach retains all of the wonderful properties of the current
(HTML-based) Web services architecture:

1. It is massively scalable.
2. It is a completely distributed architecture.
3. It is a lightweight architecture - just build the Web service, create
your metadata, and you're done.
4. The standard Web components are used - URIs to identify the Web
service and the metadata, the HTTP verbs (GET, PUT, POST, DELETE) to
access and manipulate the service and metadata.
5. Tremendous interconnectedness - others link to my Web service and to
my metadata and I can link my Web service or my metadata to other Web
services or metadata.
6. The search engine cottage industry is enhanced further.  The industry
will grow at an increasing rate as new types of search engines will be
required.  For example, for RDF-based services there will be RDF-based
search engines that will enable inductive and deductive reasoning; for
DAML/OWL-based services there will be DAML and OWL tools that enable
associations using ontologies; and, of course, there will continue to be
the old HTML-based search tools for browser-based clients.

Lastly, I would like to highlight one very important point:

After creating my Web site I did not then "register" it (anywhere).  The
search engines found my Web site.  I did not have to go out and find the
search engines.  This is a good thing.  The responsibility is on the
search engines to keep track of the Web sites (Web services) that are
out there.  The responsibility is not on individual Web site developers
to keep track of what search engines are out there.

Matchmaker (search engine) tool axiom:

   The onus is on the matchmaker tools to find the Web 
   services, and provide information to clients based upon 
   the Web services description metadata.  

Thus, the matchmakers cannot require, nor expect, Web services to
register with them.  The burden is thus on the matchmakers, not on the
Web services.

Stated another way: the matchmakers must remain decoupled from the Web
service and its service description.  

Comments?  /Roger







-----------------------------------------------------------------------------------
Post ID:3117
Sender:Joe Gregorio <joe@...>
Post Date/Time:2002-12-26 20:11:33
Subject:Re: [rest-discuss] A Simple Extension of the Current Web Architecture to Support the Next Generation Web Services
Message:

Roger L. Costello wrote:
> 
> However, keeping the metadata separate from the service representation
> then introduces a problem: 
> 
>     - if a client has the URL to a service, how does the client
>       locate the metadata for the service?
>     - alternatively, if the client has the URL to the metadata,
>       how does the client locate the service?
> 
> This is solved very simply by introducing two new HTTP headers:
> 
>     - The Meta-Location HTTP header provides the URL to the metadata
>     - The Meta-About HTTP header provides the URL to the service.
> 


Why not just introduce only one new header:

   Content-alternatives: 

which returns a comma seperated list of content-types that can serverd from the URL.

GETting those alternate types can be the gateway to
other services. For example, Content-alternatives could include 'application/rss+xml' to indicate
the RSS feed. It could also return 'application/wsil+xml'[1] or 'application/rsd+xml'[2]
to describe available web services (modulo some politically correct definition of 'web service').
This would allow multiple competing formats for web service and meta-data identification
to be developed and deployed.

[1] http://www-106.ibm.com/developerworks/webservices/library/ws-wsilspec.html
[2] http://archipelago.phrasewise.com/rsd

	-joe

-- 
http://BitWorking.org
http://WellFormedWeb.org







-----------------------------------------------------------------------------------
Post ID:3118
Sender:"Roger L. Costello" <costello@...>
Post Date/Time:2002-12-27 13:07:02
Subject:Re: [rest-discuss] A Simple Extension of the Current Web Architectureto Support the Next Generation Web Services
Message:

Hi Joe,

Joe Gregorio wrote:
> 
> Why not just introduce only one new header:
> 
>    Content-alternatives:
> 
> which returns a comma separated list of content-types that can be
> served from the URL.

Thanks for the suggestion!  Your suggestion is actually very close to
what we are doing, only one step removed.

The problem is when both the service and its description have the same
content-type.  For example, the service returns an XHTML representation
of the service, and the service description returns an XHTML
representation of the metadata.  

We didn't want to overload the semantics of the service URL because of
this confusion that occurs when the content type of the service and the
content type of the meta data are the same.  /Roger







-----------------------------------------------------------------------------------
Post ID:3119
Sender:Jim Ancona <jim@...>
Post Date/Time:2002-12-27 15:39:33
Subject:Re: [rest-discuss] A Simple Extension of the Current Web Architectureto Support the Next Generation Web Services
Message:

Roger L. Costello wrote:
> Joe Gregorio wrote:
>>Why not just introduce only one new header:
>>
>>   Content-alternatives:
>>
>>which returns a comma separated list of content-types that can be
>>served from the URL.
> 
> The problem is when both the service and its description have the same
> content-type.  For example, the service returns an XHTML representation
> of the service, and the service description returns an XHTML
> representation of the metadata.  

Another problem with Joe's approach is that metadata _about_ a resource 
is not a representation of the resource it describes. Instead it is a 
separate resource, which should have its own URI.

Suppose I want to link to, or make assertions about, the metadata 
describing a service. Using your approach, I can use the URL in the 
Meta-Location header. Joe's approach in effect creates a private address 
space where content-type is used to address different resources, rather 
than just different representations. That seems non-REST-like to me.

Jim







-----------------------------------------------------------------------------------
Post ID:3120
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-12-28 11:21:51
Subject:RE: [rest-discuss] Future proof
Message:

> From: S. Mike Dierken [mailto:mdierken@...]
> ...
> > However I agree that it's probably better to assign
> > distinct URIs to each variant (making authoring of them more
> > straightforward),
> With different URIs you'll need to discover those URIs through a response
> against a different URI. And what is this 'primary' URI supposed to mean?

Why through "a different" URI?

I imagine the 'primary' resource to be just an arbiter. BTW: there's a very
early WebDAV draft for authoring variants ([1]), and this draft calls these
primary resources "variant controllers". As far as I understand, namespace
operations on variant controllers (MOVE/COPY) will affect the variants (and
their URIs as well). One probably could also use PROPPATCH on the variant
controller to add/remove variants...

> Should all content negotiation continue to use Accept headers against this
> primary URI and have the response provide a Location header for the
> representation format identified by the Content-Type response header? Will

Yes!

> intermediaries understand this?

Good question.


[1]
<http://www.webdav.org/deltav/protocol/draft-ietf-deltav-variants-xx.1.htm>

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760







-----------------------------------------------------------------------------------
Post ID:3121
Sender:=?ISO-8859-1?Q?Bill_de_h=D3ra?= <dehora@...>
Post Date/Time:2002-12-28 18:58:47
Subject:Re: [rest-discuss] REST toolkit
Message:

Donald Ball wrote:

> Another example might be apache struts. Struts heavily uses the
> RequestDispatcher servlet api to internally forward requests to different
> components. In and of itself that's not a bad thing, but struts uses it to
> such a degree that the "URL" of a given page and the contents of that page
> may have no relation to one another. It also seems to encourage developers
> to use the HttpSession object to store conversational state, which is
> problematic from a REST point of view.

And in some cases, from the point of view of a browser's back button.


> Fixing struts to be RESTful would require a serious amount of work, and I
> guess I doubt that the developers could be convinced that it would be a
> worthwhile investment. (which is very much too bad, since struts seems to
> be very popular as a webapp infrastructure.)

The core problem with these frameworks (and their reason for being) 
is session management. In REST/OO terms the session is the 
resource/object the business and thus the webapp developers really 
care about. However smearing that resource across a web site and a 
browser (cookies, session ids in urls) makes for highly messy 
software. Rather than remove this problem, webapp frameworks paint 
abstractions on top of it. There must be a dozen other frameworks in 
Java-land doing the same job in much the same way.

And even if you did refactor struts to do a better job of sessions, 
they're managing sessions the way they do in large part because web 
browsers are they way they are. Realistically, you'd have to fix the 
browsers too.

Any useful REST toolkit is going to look like a webapp framework 
that lets developers manage session state over HTTP in a sane way.

Bill de h�ra







-----------------------------------------------------------------------------------
Post ID:3122
Sender:Sam Ruby <rubys@...>
Post Date/Time:2002-12-29 01:09:58
Subject:Towards a RESTful validation interface
Message:

I have implemented a web service interface to the RSS validator [1]. 
The essence of the interface is that one can simply POST your RSS feed, 
and you will get back either a set of messages or a fault, complete with 
the server's python stack traceback at the time of the error.

At the bottom on this e-mail is a working example of a Python client for 
this web service.

Other information that may or may not be relevant: the server 
implementation will ignore any SOAPAction HTTP header or SOAP Envelope 
or Body elements.  The responses are well formed XML and valid SOAP. 
Both the request and response are described by XML Schema, and the 
interaction is declared by a WSDL document [2].

Now let me get to the point of this e-mail.  In response to criticism 
[3], I am looking for constructive suggestions as to how to make this 
interface more compatible with REST.

[1] http://feeds.archive.org/validator/
[2] http://feeds.archive.org/validator/RSSValidator.wsdl
[3] http://www.intertwingly.net/blog/1049.html#c1041017434

- - - -

import urllib, httplib
from xml.dom import minidom

feed='http://www.aaronsw.com/weblog/index.xml'
request=urllib.urlopen(feed).read()

connection=httplib.HTTPConnection("feeds.archive.org", 80)
connection.request('POST',"/validator/", request)
response=connection.getresponse()
document=minidom.parseString(response.read())

if response.status >= 500:
   errors = document.getElementsByTagName("faultstring")
else:
   errors = document.getElementsByTagName("text")

if not errors:
   print "The feed is valid!"
else:
   for node in errors:
     print "".join([child.data for child in node.childNodes])







-----------------------------------------------------------------------------------
Post ID:3123
Sender:"David and Lisa Jacobs <dbj@...>" <dbj@...>
Post Date/Time:2002-12-27 00:17:28
Subject:Re: A Simple Extension of the Current Web Architecture to Support the Next Generation Web Services
Message:

--- In rest-discuss@yahoogroups.com, Joe Gregorio <joe@b...> wrote:
> Why not just introduce only one new header:
> 
>    Content-alternatives: 
> 
> which returns a comma seperated list of content-types that can 
serverd from the URL.
> 
> GETting those alternate types can be the gateway to
> other services. For example, Content-alternatives could 
include 'application/rss+xml' to indicate
> the RSS feed. It could also return 'application/wsil+xml'[1] 
or 'application/rsd+xml'[2]
> to describe available web services (modulo some politically correct 
definition of 'web service').
> This would allow multiple competing formats for web service and 
meta-data identification
> to be developed and deployed.
> 
> [1] http://www-106.ibm.com/developerworks/webservices/library/ws-
wsilspec.html
> [2] http://archipelago.phrasewise.com/rsd

What you propose is actually very close to what we are doing only 
removed one step.  We didn't want to overload the semantics of the 
service URL because of the confusion that could happen when the 
content type of the service and the content type of the meta data are 
the same.

David











-----------------------------------------------------------------------------------
Post ID:3124
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-12-29 03:59:02
Subject:PUT-followed-by-GET (was Re: [rest-discuss] Future proof)
Message:

From: "Walden Mathews" <waldenm@...>
>
> If someone can find, somewhere in the body of standards, clear
> language to the effect that the resource implementation is expected to
> store a PUT value in bit-literal form, and that a subsequent GET on
> a resource that has suffered a PUT at some time in its life is required
> to serve out bit-literal representations...

I have had problems with this as well.  So far, I just cannot see how this
could be enforced.  Between the moment that the PUT was completed and a
subsequent GET was requested, the resource could have been updated (via
PUTs, if you want) several times.  There is no mechanism in HTTP to perform
a PUT-followed-by-GET as an atomic operation.  As a result, it seems that
one should *ever* expect the representation sent with a PUT to be the same
as the representation retrieved with a GET, at least as a general rule.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:3125
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-12-30 00:43:11
Subject:Re: PUT-followed-by-GET (was Re: [rest-discuss] Future proof)
Message:

From: "Seairth Jacobs" <seairth@...>
>
> one should *ever* expect the representation sent with a PUT to be the same

that should be "never", not "ever"... sorry.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:3126
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-12-30 01:39:15
Subject:Re: PUT-followed-by-GET (was Re: [rest-discuss] Future proof)
Message:

I'm certainly no expert on HTTP caching, but the definition of PUT
does include the line:

    If the request passes through a cache and the Request-URI
    identifies one or more currently cached entities, those
    entries SHOULD be treated as stale.

Notice that this doesn't say "MUST."  This would seem to imply
the a cache *could* simply update it's entry without marking
it stale, and hence respond to another request without revalidating
against the origin server (depending on the cache control headers
of the request and the original response).

If the origin server had changed "<number>1</number>" to
"<number>one</number>" things could get ugly.

If PUT did require the entity to be stored as-is (which we keep
hearing it does) then this wouldn't be an issue.

I could be completely wrong about this and would appreciate
hearing about where I went awry.

- Winter


----- Original Message -----
From: "Seairth Jacobs" <seairth@...>
To: "rest-discuss" <rest-discuss@yahoogroups.com>
Sent: Saturday, December 28, 2002 10:59 PM
Subject: PUT-followed-by-GET (was Re: [rest-discuss] Future proof)


> From: "Walden Mathews" <waldenm@...>
> >
> > If someone can find, somewhere in the body of standards, clear
> > language to the effect that the resource implementation is expected to
> > store a PUT value in bit-literal form, and that a subsequent GET on
> > a resource that has suffered a PUT at some time in its life is required
> > to serve out bit-literal representations...
>
> I have had problems with this as well.  So far, I just cannot see how this
> could be enforced.  Between the moment that the PUT was completed and a
> subsequent GET was requested, the resource could have been updated (via
> PUTs, if you want) several times.  There is no mechanism in HTTP to
perform
> a PUT-followed-by-GET as an atomic operation.  As a result, it seems that
> one should *ever* expect the representation sent with a PUT to be the same
> as the representation retrieved with a GET, at least as a general rule.
>
> ---
> Seairth Jacobs
> seairth@...
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:3127
Sender:Ian Clelland <ian@...>
Post Date/Time:2002-12-30 02:21:36
Subject:Re: PUT-followed-by-GET
Message:

On Sun, Dec 29, 2002 at 08:39:15PM -0500, Jeffrey Winter wrote:
> I'm certainly no expert on HTTP caching, but the definition of PUT
> does include the line:
> 
>     If the request passes through a cache and the Request-URI
>     identifies one or more currently cached entities, those
>     entries SHOULD be treated as stale.
> 
> Notice that this doesn't say "MUST."  This would seem to imply
> the a cache *could* simply update it's entry without marking
> it stale, and hence respond to another request without revalidating
> against the origin server (depending on the cache control headers
> of the request and the original response).

I read that line a little differently -- It refers to a PUT request
from a user agent passing through a proxy cache on its way to an origin
server. I'm fairly certain that the cache is not allowed to update its
contents based on that PUT request, since it has no idea whether the PUT
will even be accepted by the origin server.

What it *is* allowed to do, though, is mark its cached copies as
'stale', so that the next GET request for that resource will cause the
cache to query the origin server for the most recent version.

This behaviour is only given the strength of 'SHOULD', since not doing
it doesn't weaken the caching semantics in any way. The old version of
the resource can still be served until it expires -- just as all of the
other caches, which didn't see the PUT, will be doing.


> If the origin server had changed "<number>1</number>" to
> "<number>one</number>" things could get ugly.
> 
> If PUT did require the entity to be stored as-is (which we keep
> hearing it does) then this wouldn't be an issue.

I don't think this section of RFC 2616 has anything to say about whether
the server must store the entity as-is. If the server modifies the entity
when it receives it, then the cache should retrieve the modified version
when it revalidates.

The existence of caching, though, does mean that you can't assume that a
GET issued immediately after a PUT will return the recently-PUT entity.
It could legitimately return with any non-expired version of the entity
previously served by the origin server.


Ian Clelland
<ian@...>







-----------------------------------------------------------------------------------
Post ID:3128
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-30 03:14:14
Subject:Re: [rest-discuss] Re: PUT-followed-by-GET
Message:

On Sun, Dec 29, 2002 at 06:21:36PM -0800, Ian Clelland wrote:
> I read that line a little differently -- It refers to a PUT request
> from a user agent passing through a proxy cache on its way to an origin
> server. I'm fairly certain that the cache is not allowed to update its
> contents based on that PUT request, since it has no idea whether the PUT
> will even be accepted by the origin server.
> 
> What it *is* allowed to do, though, is mark its cached copies as
> 'stale', so that the next GET request for that resource will cause the
> cache to query the origin server for the most recent version.
> 
> This behaviour is only given the strength of 'SHOULD', since not doing
> it doesn't weaken the caching semantics in any way. The old version of
> the resource can still be served until it expires -- just as all of the
> other caches, which didn't see the PUT, will be doing.

That's exactly my interpretation.

> > If the origin server had changed "<number>1</number>" to
> > "<number>one</number>" things could get ugly.
> > 
> > If PUT did require the entity to be stored as-is (which we keep
> > hearing it does) then this wouldn't be an issue.
> 
> I don't think this section of RFC 2616 has anything to say about whether
> the server must store the entity as-is.

Well, the first sentence of section 9.6 says;

"The PUT method requests that the enclosed entity be stored under the
supplied Request-URI."

I know some people have a more liberal interpretation of "store" than
I do, which is fine.  But I think that a significant number think -
and more importantly, have written software that assumes - that "store"
means, well, "store". 8-)

I don't know how much software out there makes this assumption, but
I'd be willing to bet money that anybody developing software that
doesn't make this assumption, will eventually have problems when it
discovers the other software.

Doesn't WebDAV + supporting specs assume that PUT = store?  Julian?

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3129
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-12-30 03:58:46
Subject:Re: PUT-followed-by-GET (was Re: [rest-discuss] Future proof)
Message:


Seairth Jacobs wrote:

>From: "Walden Mathews" <waldenm@...>
>
>>If someone can find, somewhere in the body of standards, clear
>>language to the effect that the resource implementation is expected to
>>store a PUT value in bit-literal form, and that a subsequent GET on
>>a resource that has suffered a PUT at some time in its life is required
>>to serve out bit-literal representations...
>>
>
>I have had problems with this as well.  So far, I just cannot see how this
>could be enforced.  Between the moment that the PUT was completed and a
>subsequent GET was requested, the resource could have been updated (via
>PUTs, if you want) several times.  There is no mechanism in HTTP to perform
>a PUT-followed-by-GET as an atomic operation.  As a result, it seems that
>one should *ever* expect the representation sent with a PUT to be the same
>as the representation retrieved with a GET, at least as a general rule.
>
I'm not sure I understand the previous sentence.  Is that *ever* or 
*never*.  I'll assume you meant *never*.

I believe you're leaving out important parts of the statement.  I'll try 
to restate it here as I understand it:

A GET operation that immediately follows a PUT operation must return 
exactly the representation presented by the PUT, _provided that the 
resource's state does not change between those two operations_.  Note 
that this statement is about the behavior of the server; it is not about 
behavior that an arbitraty client might be able to observe.

I'm pretty sure we've had this discussion here before (or maybe it was 
rest-expolore), but I can't suffer through Yahoo's UI to provide a 
reference.  (Try searching the August/September 2002 archives)

If I remember correctly, this whole thing is not really about what you 
GET after a PUT.  It is more about whether or not you can do content 
negotiation/have variants on a PUT.  As I understand it, Fielding says 
you can't because there's no mechanism (in HTTP) to indicate whether the 
contents of the PUT is a variant of the current representation or a 
replacement for the current representation.  I seem to remember that the 
conversation wrapped up with an understanding that, in general, 
resources that support PUT cannot support content negotiation.


--Chuck








-----------------------------------------------------------------------------------
Post ID:3130
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-12-30 04:30:48
Subject:Re: [rest-discuss] Re: PUT-followed-by-GET
Message:

From: "Mark Baker" <distobj@...>
>
> On Sun, Dec 29, 2002 at 06:21:36PM -0800, Ian Clelland wrote:
> >
> > I don't think this section of RFC 2616 has anything to say about whether
> > the server must store the entity as-is.
>
> Well, the first sentence of section 9.6 says;
>
> "The PUT method requests that the enclosed entity be stored under the
> supplied Request-URI."
>
> I know some people have a more liberal interpretation of "store" than
> I do, which is fine.  But I think that a significant number think -
> and more importantly, have written software that assumes - that "store"
> means, well, "store". 8-)

I am guessing that many (maybe even most) implementations implicitly assume
that PUT is being used by a limited/controlled number of clients (usually
one) on a given URI.  For example, if I were to update my website using PUT,
I am the sole user of PUT on any given URI.  This allows me to "safely"
state that my html file was stored "as is" at that request-URI.

However, suppose you have a URI that is being updated by several clients
independently.  For example, suppose that you have a client that scans all
documents and auto-corrects misspelled words.  In this case, a
PUT-followed-by-GET would not guarantee that the returned entity would be
the same as the one sent in the first place because PUTs from other
client(s) could happen in between the PUT and GET operations.

Now, if you were to take this a bit further, the server itself could update
the resource between the PUT and GET.  If you want, think of it as an
implicit GET-followed-by-PUT where the server is acting like a "client".
The end result would be no different from another client performing the same
operation.

> I don't know how much software out there makes this assumption, but
> I'd be willing to bet money that anybody developing software that
> doesn't make this assumption, will eventually have problems when it
> discovers the other software.

It seems to me that adding a constraint where "store" means "as is" will be
the more likely cause of the problems.  Taking a looser interpretation can
still allow "as is" when it's needed without forcing thos blinders all
implementations.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:3131
Sender:"Seairth Jacobs" <seairth@...>
Post Date/Time:2002-12-30 04:42:24
Subject:Re: PUT-followed-by-GET (was Re: [rest-discuss] Future proof)
Message:

From: "Chuck Hinson" <cmhinson@...>
>
> Seairth Jacobs wrote:
>
> >From: "Walden Mathews" <waldenm@...>
> >
> >>If someone can find, somewhere in the body of standards, clear
> >>language to the effect that the resource implementation is expected to
> >>store a PUT value in bit-literal form, and that a subsequent GET on
> >>a resource that has suffered a PUT at some time in its life is required
> >>to serve out bit-literal representations...
> >>
> >
> >I have had problems with this as well.  So far, I just cannot see how
this
> >could be enforced.  Between the moment that the PUT was completed and a
> >subsequent GET was requested, the resource could have been updated (via
> >PUTs, if you want) several times.  There is no mechanism in HTTP to
perform
> >a PUT-followed-by-GET as an atomic operation.  As a result, it seems that
> >one should *ever* expect the representation sent with a PUT to be the
same
> >as the representation retrieved with a GET, at least as a general rule.
> >
> I'm not sure I understand the previous sentence.  Is that *ever* or
> *never*.  I'll assume you meant *never*.

Yeah, that's what I meant. <s>

> I believe you're leaving out important parts of the statement.  I'll try
> to restate it here as I understand it:
>
> A GET operation that immediately follows a PUT operation must return
> exactly the representation presented by the PUT, _provided that the
> resource's state does not change between those two operations_.  Note
> that this statement is about the behavior of the server; it is not about
> behavior that an arbitraty client might be able to observe.

But if PUT means that the server maps the request-entity "as is" to the
request-URI, then the only way that a resource state can change between
those two operations is via a client.  From what some are saying, the
"behaviour" of the server for PUT will never cause a state change before the
subsequent GET (assuming no other external operations are performed in
between). Am I wrong about this?

> I'm pretty sure we've had this discussion here before (or maybe it was
> rest-expolore), but I can't suffer through Yahoo's UI to provide a
> reference.  (Try searching the August/September 2002 archives)

perma-thread...

> If I remember correctly, this whole thing is not really about what you
> GET after a PUT.  It is more about whether or not you can do content
> negotiation/have variants on a PUT.  As I understand it, Fielding says
> you can't because there's no mechanism (in HTTP) to indicate whether the
> contents of the PUT is a variant of the current representation or a
> replacement for the current representation.  I seem to remember that the
> conversation wrapped up with an understanding that, in general,
> resources that support PUT cannot support content negotiation.

I think you are talking about a different thread than I am.  I think there
are very real examples of this problem without bringing content negotiation
or variants into it.  I admit that's an issue, but a different one.

---
Seairth Jacobs
seairth@...







-----------------------------------------------------------------------------------
Post ID:3132
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-12-30 04:59:41
Subject:Re: PUT-followed-by-GET (was Re: [rest-discuss] Future proof)
Message:

I'll nitpick with your use of "imply".  I don't think the quoted language
implies the consequence at all.  It' just doesn't explicitly prohibit it.
I'm
no expert on HTTP caching either, but given that a PUT is still just
a _request_ on the server to accept the representation, and the server
doesn't have to honor the request, updating the cache from a PUT
representation seems highly questionable.

Walden.


----- Original Message -----
From: "Jeffrey Winter" <j.winter@...>
To: "rest-discuss" <rest-discuss@yahoogroups.com>; "Seairth Jacobs"
<seairth@...>
Sent: Sunday, December 29, 2002 8:39 PM
Subject: Re: PUT-followed-by-GET (was Re: [rest-discuss] Future proof)


> I'm certainly no expert on HTTP caching, but the definition of PUT
> does include the line:
>
>     If the request passes through a cache and the Request-URI
>     identifies one or more currently cached entities, those
>     entries SHOULD be treated as stale.
>
> Notice that this doesn't say "MUST."  This would seem to imply
> the a cache *could* simply update it's entry without marking
> it stale, and hence respond to another request without revalidating
> against the origin server (depending on the cache control headers
> of the request and the original response).
>
> If the origin server had changed "<number>1</number>" to
> "<number>one</number>" things could get ugly.
>
> If PUT did require the entity to be stored as-is (which we keep
> hearing it does) then this wouldn't be an issue.
>
> I could be completely wrong about this and would appreciate
> hearing about where I went awry.
>
> - Winter
>
>
> ----- Original Message -----
> From: "Seairth Jacobs" <seairth@...>
> To: "rest-discuss" <rest-discuss@yahoogroups.com>
> Sent: Saturday, December 28, 2002 10:59 PM
> Subject: PUT-followed-by-GET (was Re: [rest-discuss] Future proof)
>
>
> > From: "Walden Mathews" <waldenm@...>
> > >
> > > If someone can find, somewhere in the body of standards, clear
> > > language to the effect that the resource implementation is expected to
> > > store a PUT value in bit-literal form, and that a subsequent GET on
> > > a resource that has suffered a PUT at some time in its life is
required
> > > to serve out bit-literal representations...
> >
> > I have had problems with this as well.  So far, I just cannot see how
this
> > could be enforced.  Between the moment that the PUT was completed and a
> > subsequent GET was requested, the resource could have been updated (via
> > PUTs, if you want) several times.  There is no mechanism in HTTP to
> perform
> > a PUT-followed-by-GET as an atomic operation.  As a result, it seems
that
> > one should *ever* expect the representation sent with a PUT to be the
same
> > as the representation retrieved with a GET, at least as a general rule.
> >
> > ---
> > Seairth Jacobs
> > seairth@...
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > rest-discuss-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
>
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>







-----------------------------------------------------------------------------------
Post ID:3133
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-12-30 05:14:39
Subject:Re: [rest-discuss] Re: PUT-followed-by-GET
Message:

> Well, the first sentence of section 9.6 says;
> 
> "The PUT method requests that the enclosed entity be stored under the
> supplied Request-URI."
> 
> I know some people have a more liberal interpretation of "store" than
> I do, which is fine.  But I think that a significant number think -
> and more importantly, have written software that assumes - that "store"
> means, well, "store". 8-)

In my opinion, that's overloading the term "store" just a teeny bit.  The
thrust of the quote above is *which URI* the representation should be
stored under, not whether it should be _stored_ or *stored* or "stored".

Anyway, storage is implementation detail.  If a server can receive a PUT
request and later dish up the right representation on GET, then it is
behaving correctly, and if it can do that without _storing_ the rep, well
that's none of our business.

/walden







-----------------------------------------------------------------------------------
Post ID:3134
Sender:Walden Mathews <waldenm@...>
Post Date/Time:2002-12-30 05:34:39
Subject:Re: PUT-followed-by-GET (was Re: [rest-discuss] Future proof)
Message:

> I believe you're leaving out important parts of the statement.  I'll try
> to restate it here as I understand it:
>
> A GET operation that immediately follows a PUT operation must return
> exactly the representation presented by the PUT,

Is some kind of equivalence implied?  If so, what is its specification?
There
are folks hotly debating, as we speak, how to do equiavalence on URI
strings.

> _provided that the
> resource's state does not change between those two operations_.  Note
> that this statement is about the behavior of the server; it is not about
> behavior that an arbitraty client might be able to observe.

Are you talking about nontransparent cache effects here?  If not, then
I don't understand why you say that GET's behavior is not observable
by clients.

>
> If I remember correctly, this whole thing is not really about what you
> GET after a PUT.  It is more about whether or not you can do content
> negotiation/have variants on a PUT.  As I understand it, Fielding says
> you can't because there's no mechanism (in HTTP) to indicate whether the
> contents of the PUT is a variant of the current representation or a
> replacement for the current representation.  I seem to remember that the
> conversation wrapped up with an understanding that, in general,
> resources that support PUT cannot support content negotiation.

Let's look at a SQL analogy in which UPDATE is in the same role as
HTTP PUT.

>    UPDATE ORDER SET ORDER_DATE = '1/12/2003 09:00:00' where KEY='1'

1 row(s) updated

Here I've supplied a string representation of a date field, whose internal
storage for whatever SQL engine I'm using is irrelevant.  Now I'll retrieve
the same info:

>    SELECT ORDER_DATE from ORDER where KEY='1'

Jan 12, 2003 9:00 AM

1 row(s)

Semantically equivalent, but the format's been changed.  Happens all
the time.  The UPDATE didn't store yet another variant, nor did it take
my string and try to treat its bits as a long integer or something else.

/walden







-----------------------------------------------------------------------------------
Post ID:3135
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-30 06:16:17
Subject:Re: [rest-discuss] Re: PUT-followed-by-GET
Message:

On Mon, Dec 30, 2002 at 12:14:39AM -0500, Walden Mathews wrote:
> In my opinion, that's overloading the term "store" just a teeny bit.  The
> thrust of the quote above is *which URI* the representation should be
> stored under, not whether it should be _stored_ or *stored* or "stored".
>
> Anyway, storage is implementation detail.  If a server can receive a PUT
> request and later dish up the right representation on GET, then it is
> behaving correctly, and if it can do that without _storing_ the rep, well
> that's none of our business.

RFC 2616 is describing a network interface.  The meaning of PUT - store -
prescribes only storage interface semantics; bits in, same bits out.

I understand your angle here, but it's a tad academic, since all that
really matters is what most other people believe and implement - and
that's bit-wise equivalence in everything I've seen PUT used for.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3136
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-12-30 08:54:03
Subject:Re: PUT-followed-by-GET (was Re: [rest-discuss] Future proof)
Message:

Walden Mathews wrote:

>>I believe you're leaving out important parts of the statement.  I'll try
>>to restate it here as I understand it:
>>
>>A GET operation that immediately follows a PUT operation must return
>>exactly the representation presented by the PUT,
>>
>
>Is some kind of equivalence implied?  If so, what is its specification?
>There
>are folks hotly debating, as we speak, how to do equiavalence on URI
>strings.
>

I'm not sure I see the connection.  One is talking about comparing URI 
strings, while the other is about the equivalence of representations 
(and then only indirectly)..

>>_provided that the
>>resource's state does not change between those two operations_.  Note
>>that this statement is about the behavior of the server; it is not about
>>behavior that an arbitraty client might be able to observe.
>>
>
>Are you talking about nontransparent cache effects here?  If not, then
>I don't understand why you say that GET's behavior is not observable
>by clients.
>

I probably overconstrained things by including the statment about what 
is observable by the client.  In retrospect, it seems kind of obvious 
that if the resource's state doesnt change between requests, then the 
observed behavior is the same at the server as well as at the client 
making the requests.  

>>If I remember correctly, this whole thing is not really about what you
>>GET after a PUT.  It is more about whether or not you can do content
>>negotiation/have variants on a PUT.  As I understand it, Fielding says
>>you can't because there's no mechanism (in HTTP) to indicate whether the
>>contents of the PUT is a variant of the current representation or a
>>replacement for the current representation.  I seem to remember that the
>>conversation wrapped up with an understanding that, in general,
>>resources that support PUT cannot support content negotiation.
>>
>
>Let's look at a SQL analogy in which UPDATE is in the same role as
>HTTP PUT.
>
>>   UPDATE ORDER SET ORDER_DATE = '1/12/2003 09:00:00' where KEY='1'
>>
>
>1 row(s) updated
>
>Here I've supplied a string representation of a date field, whose internal
>storage for whatever SQL engine I'm using is irrelevant.  Now I'll retrieve
>the same info:
>
>>   SELECT ORDER_DATE from ORDER where KEY='1'
>>
>
>Jan 12, 2003 9:00 AM
>
>1 row(s)
>
>Semantically equivalent, but the format's been changed.  Happens all
>the time.  The UPDATE didn't store yet another variant, nor did it take
>my string and try to treat its bits as a long integer or something else.
>
>/walden
>
I'm too tired to get a fully formed thought right now, but it seems to 
me that the difference here is that the various date formats are part of 
the sql specification whereas they are not in HTTP.  And because they 
are not, you cant have a uniform interface when some resources 
understand the semantic equivalence and others do not (or interpret it 
differently).

--Chuck








-----------------------------------------------------------------------------------
Post ID:3137
Sender:Chuck Hinson <cmhinson@...>
Post Date/Time:2002-12-30 08:59:44
Subject:Re: PUT-followed-by-GET (was Re: [rest-discuss] Future proof)
Message:


Seairth Jacobs wrote:

>From: "Chuck Hinson" <cmhinson@...>
>
[. . .]

>>A GET operation that immediately follows a PUT operation must return
>>exactly the representation presented by the PUT, _provided that the
>>resource's state does not change between those two operations_.  Note
>>that this statement is about the behavior of the server; it is not about
>>behavior that an arbitraty client might be able to observe.
>>
>
>But if PUT means that the server maps the request-entity "as is" to the
>request-URI, then the only way that a resource state can change between
>those two operations is via a client.  From what some are saying, the
>"behaviour" of the server for PUT will never cause a state change before the
>subsequent GET (assuming no other external operations are performed in
>between). Am I wrong about this?
>

Yes.  I didnt say that the server won't cause a state change.  I just 
said that if a state change does occur, then the rule no longer holds. 
 In other words, if a state change does occur, then there can be no 
garantees about the content of a GET following a PUT.

--Chuck







-----------------------------------------------------------------------------------
Post ID:3138
Sender:Paul Prescod <paul@...>
Post Date/Time:2002-12-30 02:32:26
Subject:document() and Amazon
Message:

FYI: according to Amazon they do in fact have precautions to prevent the 
inappropriate use of the document() function.

  Paul Prescod








-----------------------------------------------------------------------------------
Post ID:3139
Sender:"Julian Reschke" <julian.reschke@...>
Post Date/Time:2002-12-30 14:27:14
Subject:RE: [rest-discuss] Re: PUT-followed-by-GET
Message:

> From: Mark Baker [mailto:distobj@...]
> Sent: Monday, December 30, 2002 4:14 AM
> To: Ian Clelland
> Cc: Jeffrey Winter; rest-discuss@yahoogroups.com
> Subject: Re: [rest-discuss] Re: PUT-followed-by-GET
>
>
> ...
>
> > I don't think this section of RFC 2616 has anything to say about whether
> > the server must store the entity as-is.
>
> Well, the first sentence of section 9.6 says;
>
> "The PUT method requests that the enclosed entity be stored under the
> supplied Request-URI."
>
> I know some people have a more liberal interpretation of "store" than
> I do, which is fine.  But I think that a significant number think -
> and more importantly, have written software that assumes - that "store"
> means, well, "store". 8-)
>
> I don't know how much software out there makes this assumption, but
> I'd be willing to bet money that anybody developing software that
> doesn't make this assumption, will eventually have problems when it
> discovers the other software.
>
> Doesn't WebDAV + supporting specs assume that PUT = store?  Julian?

RFC2518 is very silent about PUT - it completely relies on the HTTP
definition.

Almost all real-world WebDAV implementations although use WebDAV as some
sort of filesystem replacement. So they assume that the entity sent with PUT
indeed is stored octet-per-octet, and that you can retrieve it exactly as
written with GET.

Which doesn't mean that I can think that you can or should rely on it. One
server (I think either Slide/Tamino or Oracle) allows WebDAV access to an
underlying XML store, and at least for XML-wellformed entities it is *not*
going to store the XML serialization, but the XML infoset in some internal
format. This means, that you aren't going to round-trip things like
attribute quoting (quote vs apostrophe and so on...).

Another use case would be a server that filters content that is PUT to
extract metadata (for storage as WebDAV properties). For instance, servers
may extract author information from Word or HTML files. So the submitted
entity is indeed stored (as octet stream), but the server automatically adds
metadata that wasn't explicit in the request.

WebDAV's interaction with conneg/variant handling currently is completely
underspecified. Indeed I just tried Apache 2.0.43 with moddav enabled on the
root and got very strange results when trying to create a new resource named
"index.html" (Apache crashing when using index.html as Destination for a
MOVE command). :-)  So obviously this needs work.

Julian






--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760







-----------------------------------------------------------------------------------
Post ID:3140
Sender:Miles Sabin <miles@...>
Post Date/Time:2002-12-30 14:42:46
Subject:Re: [rest-discuss] document() and Amazon
Message:

Paul Prescod wrote,
> FYI: according to Amazon they do in fact have precautions to prevent
> the inappropriate use of the document() function.

Interesting ... thanks.

Any chance of persuading Amazon to say what those restrictions are? 
They're surprisingly tricky to specify without leaving subtle loopholes 
(cp. the history of "originating host" flaws in browser based script 
and applet implementations), so if they've done it right it would be a 
helpful service to the community at large to publish the details.

OTOH, if they haven't got it right ... well, you know what they say 
about "security through obscurity".

Cheers,


Miles






-----------------------------------------------------------------------------------
Post ID:3141
Sender:DJ Adams <dj.adams@...>
Post Date/Time:2002-12-30 16:27:41
Subject:Re: [rest-discuss] Towards a RESTful validation interface
Message:

On Sat, Dec 28, 2002 at 08:09:58PM -0500, Sam Ruby wrote:
> Now let me get to the point of this e-mail.  In response to criticism 
> [3], I am looking for constructive suggestions as to how to make this 
> interface more compatible with REST.

While I don't really have any suggestions, I would like to throw in a
thought from here - I *think* I would like to be able to tell whether
the data that I threw at the validator was valid RSS or not by looking
at the status code. This requires a slight rethink of the model Sam has,
whereby the URI represents a container that you're *supposed* to throw
valid RSS at, and receive either:

a 200 status with no message body if the RSS is valid

or

a non-200 status back (with the details in the message body) if it's not. 

Thing is, I can't figure out what the status code should be. I first
looked at status code 415 (Unsupported Media Type) but I suspect that
would mean that 'application/rss+xml' was *generally* not supported at
that URI, rather than just *invalid* 'application/rss+xml'. 

So - is trying to get away from the 'homogenisation' of all results into
a 200 status code an appropriate thing to do here (or anywhere)? 

Thanks for any comments
dj

p.s. If I didn't know Sam better I would suspect this conundrum is 
deliberate ;) Either that, or my brane is too addled from festive food.






-----------------------------------------------------------------------------------
Post ID:3142
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-12-30 15:22:07
Subject:Re: [rest-discuss] Towards a RESTful validation interface
Message:

Personally, I don't see why this isn't a RESTful interface.   You're doing
a "GET" on a resource, e.g.:


http://feeds.archive.org/validator/check?url=http%3A%2F%2Fdiveintomark.org%2Fx
ml%2Frss.xml

and getting a response.

I'm curious about what you say about the SOAP <envelope> and <body> elements
though: under what circumstances would they occur in the returned document?

- Jeff



----- Original Message -----
From: "Sam Ruby" <rubys@...>
To: <rest-discuss@yahoogroups.com>
Sent: Saturday, December 28, 2002 8:09 PM
Subject: [rest-discuss] Towards a RESTful validation interface


I have implemented a web service interface to the RSS validator [1].
The essence of the interface is that one can simply POST your RSS feed,
and you will get back either a set of messages or a fault, complete with
the server's python stack traceback at the time of the error.

At the bottom on this e-mail is a working example of a Python client for
this web service.

Other information that may or may not be relevant: the server
implementation will ignore any SOAPAction HTTP header or SOAP Envelope
or Body elements.  The responses are well formed XML and valid SOAP.
Both the request and response are described by XML Schema, and the
interaction is declared by a WSDL document [2].

Now let me get to the point of this e-mail.  In response to criticism
[3], I am looking for constructive suggestions as to how to make this
interface more compatible with REST.

[1] http://feeds.archive.org/validator/
[2] http://feeds.archive.org/validator/RSSValidator.wsdl
[3] http://www.intertwingly.net/blog/1049.html#c1041017434

- - - -

import urllib, httplib
from xml.dom import minidom

feed='http://www.aaronsw.com/weblog/index.xml'
request=urllib.urlopen(feed).read()

connection=httplib.HTTPConnection("feeds.archive.org", 80)
connection.request('POST',"/validator/", request)
response=connection.getresponse()
document=minidom.parseString(response.read())

if response.status >= 500:
   errors = document.getElementsByTagName("faultstring")
else:
   errors = document.getElementsByTagName("text")

if not errors:
   print "The feed is valid!"
else:
   for node in errors:
     print "".join([child.data for child in node.childNodes])



To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/








-----------------------------------------------------------------------------------
Post ID:3143
Sender:"sa3ruby <rubys@...>" <rubys@...>
Post Date/Time:2002-12-30 15:57:32
Subject:Re: Towards a RESTful validation interface
Message:

DJ Adams wrote:
> 
> So - is trying to get away from the 'homogenisation' of all results
> into a 200 status code an appropriate thing to do here (or
> anywhere)? 

I think you answered your own question.  The value of HTTP is a
uniform interface.  This is a two edged sword.

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:3144
Sender:"sa3ruby <rubys@...>" <rubys@...>
Post Date/Time:2002-12-30 16:02:02
Subject:Re: Towards a RESTful validation interface
Message:

Jeffrey Winter wrote:
> Personally, I don't see why this isn't a RESTful interface.   
> You're doing a "GET" on a resource, and getting a response.

I'm sorry if I wasn't clear.  I was not asking about the HTML page,
but instead about the Python code, which is clearly doing a POST.

> I'm curious about what you say about the SOAP <envelope> and <body>
> elements though: under what circumstances would they occur in the
> returned document?

In response to a POST.

- Sam Ruby







-----------------------------------------------------------------------------------
Post ID:3145
Sender:Craeg Strong <cstrong@...>
Post Date/Time:2002-12-30 11:20:34
Subject:Why can't XML namespace declarations point to real live URLs?
Message:

Hello:

I recently got tripped up trying to use an EXSLT extension
function in my XSLT transformer.  I used

http://www.exslt.org/dyn/

as my namespace declaration.  This *does* point to the
web page describing the facility (the human-readable spec) but *is not* the correct namespace string.  The ns should
be declared as follows: 

http://exslt.org/dynamic

My question:  why can't they be the same thing?  Is there
some reason I haven't thought of?  In fact, couldn't the 
very same URL be used for: 

A) the namespace declaration
B) the human readable spec
C) mobile or manually downloadable code implementing the spec

where B/C is controlled through content negotiation
or some other ReSTful facility...  Opinions?

Regards,

--Craeg






-----------------------------------------------------------------------------------
Post ID:3146
Sender:DJ Adams <dj.adams@...>
Post Date/Time:2002-12-30 18:13:04
Subject:Re: [rest-discuss] Re: Towards a RESTful validation interface
Message:

On Mon, Dec 30, 2002 at 03:57:32PM -0000, sa3ruby <rubys@...> wrote:
> > So - is trying to get away from the 'homogenisation' of all results
> > into a 200 status code an appropriate thing to do here (or
> > anywhere)? 
> 
> I think you answered your own question.  The value of HTTP is a
> uniform interface. ...

Not wanting to appear obtuse, but I think the statement is a little
misleading, or at least ambiguous. Then again, perhaps I've misunderstood.
Are you saying that an HTTP status code of 201 following a successful PUT
is uniform (with 200?) or not?

dj






-----------------------------------------------------------------------------------
Post ID:3147
Sender:"S. Mike Dierken" <mdierken@...>
Post Date/Time:2002-12-30 18:29:37
Subject:Re: [rest-discuss] Towards a RESTful validation interface
Message:

----- Original Message -----
From: "Sam Ruby" <rubys@...>

>
> Now let me get to the point of this e-mail.  In response to criticism
> [3], I am looking for constructive suggestions as to how to make this
> interface more compatible with REST.

I agree with you that this interface is REST compatible, but because the
nature of the information is very transient I believe you won't see a lot of
the benefits of REST. This is just my opinion though.
I think there is a spectrum of capabilities that designers can add to
systems to get the most bang for the buck. At the low end of the spectrum
you might be 'compatible', but not really full featured - the tree isn't big
enough to hang a lot of fruit on.
If you add more features to your validator service you might begin seeing
more possibilities - but just to do this one thing, its fine as it is.

Things to add:
1. persistence
If the service remembered the POSTed data, then the service could provide a
URI that can be used to announce to the world the shameful RSS that was sent
to it.

2. links
If the client wanted to expose the prospective data as a Resource (requiring
an 'origin server' in REST speak), then the validation service only needs to
be given a URI - and perhaps it could be implemented via GET. This is
analagous to a file system utility that validates an XML file - like command
piping in Unix, except with URIs and the Web.
It would be interesting to create an extreme example of technology abuse by
having a client take the transient data, open a port to receive HTTP
requests on, send the URI to the service, respond to the GET with the
transient data, and then close the port. Kind of like creating a temp file
to pipe to a file-only aware command line utility.

3. response status
The client detects HTTP response status of 500 and above - is this for
detecting service failure or for detecting invalid RSS? I think that the
service should successfully report validation completion via a 2xx status
and use response content to describe the validity of the POSTed content.









-----------------------------------------------------------------------------------
Post ID:3148
Sender:Sam Ruby <rubys@...>
Post Date/Time:2002-12-30 18:33:18
Subject:Re: [rest-discuss] Re: Towards a RESTful validation interface
Message:

DJ Adams wrote:
> On Mon, Dec 30, 2002 at 03:57:32PM -0000, sa3ruby <rubys@...> wrote:
> 
>>>So - is trying to get away from the 'homogenisation' of all results
>>>into a 200 status code an appropriate thing to do here (or
>>>anywhere)? 
>>
>>I think you answered your own question.  The value of HTTP is a
>>uniform interface. ...
> 
> Not wanting to appear obtuse, but I think the statement is a little
> misleading, or at least ambiguous. Then again, perhaps I've misunderstood.
> Are you saying that an HTTP status code of 201 following a successful PUT
> is uniform (with 200?) or not?

201 is defined by the protocol, and therefore uniform across all 
compliant HTTP implementations.

I personally would prefer not to see HTTP follow down a similar path as 
COM's HRESULT - where portions of application specific responses are 
comingled with transport level status.

- Sam Ruby












-----------------------------------------------------------------------------------
Post ID:3149
Sender:DJ Adams <dj.adams@...>
Post Date/Time:2002-12-30 20:10:16
Subject:Re: [rest-discuss] Re: Towards a RESTful validation interface
Message:

On Mon, Dec 30, 2002 at 01:33:18PM -0500, Sam Ruby wrote:
>> [201 vs 200, etc]
> I personally would prefer not to see HTTP follow down a similar path as 
> COM's HRESULT - where portions of application specific responses are 
> comingled with transport level status.

<smile/>

This being such an old chestnut I'll at least do you the honour of 
responding. <<Of course, HTTP is an application protocol, not (just)
a transport protocol>>. But I'm sure you know that already :)

Nevertheless, I can see the view from a SOAP-over-HTTP perspective.

People less woolly than I might respond to your statement thus: <<But
Sam, HTTP isn't following that path, it's _defined_ it and has always
been there>>.

dj






-----------------------------------------------------------------------------------
Post ID:3150
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-30 19:20:16
Subject:Re: [rest-discuss] Towards a RESTful validation interface
Message:

On Mon, Dec 30, 2002 at 04:27:41PM +0000, DJ Adams wrote:
> While I don't really have any suggestions, I would like to throw in a
> thought from here - I *think* I would like to be able to tell whether
> the data that I threw at the validator was valid RSS or not by looking
> at the status code. This requires a slight rethink of the model Sam has,
> whereby the URI represents a container that you're *supposed* to throw
> valid RSS at, and receive either:
> 
> a 200 status with no message body if the RSS is valid
> 
> or
> 
> a non-200 status back (with the details in the message body) if it's not. 
> 
> Thing is, I can't figure out what the status code should be. I first
> looked at status code 415 (Unsupported Media Type) but I suspect that
> would mean that 'application/rss+xml' was *generally* not supported at
> that URI, rather than just *invalid* 'application/rss+xml'. 
> 
> So - is trying to get away from the 'homogenisation' of all results into
> a 200 status code an appropriate thing to do here (or anywhere)? 

Sure, if that's what you want.  If you want the state of resulting
validation to be a valid state of your application, you need to return
a 2xx.

IMO, when in doubt, lean towards 2xx.  But that doesn't mean sending
SOAP faults over 2xx, it means sending SOAP envelopes with state
information useful to your application over 2xx.

FWIW, I would fully expect a validation service to send back validation
errors over 2xx, since validation errors are the result of *successful*
processing (i.e. it was able to determine that there were validation
errors).

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3151
Sender:DJ Adams <dj.adams@...>
Post Date/Time:2002-12-30 21:00:28
Subject:Re: [rest-discuss] Towards a RESTful validation interface
Message:

On Mon, Dec 30, 2002 at 02:20:16PM -0500, Mark Baker wrote:
> FWIW, I would fully expect a validation service to send back validation
> errors over 2xx, since validation errors are the result of *successful*
> processing (i.e. it was able to determine that there were validation
> errors).

Yes, I don't disagree; as you say, the actual processing was successful.
This is the reason I was saying the model in my question was different to
the original one.

Cheers
dj






-----------------------------------------------------------------------------------
Post ID:3152
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-12-30 19:58:37
Subject:SOAP assuming REST (was: Towards a RESTful validation interface)
Message:

One thing that is interesting about your interface
is that you assume <envelope> and <body> elements
even if they are not supplied.

Would it be much work to not return them in the 
response if the request wasn't encoded as SOAP?
Granted these are easily ignored, but why deal with
them at all?

Which leads to another question: Has there ever 
been any serious consideration to defining 
SOAP 1.2 in such a way that it would
assume the <envelope> and <body> tags if none 
are given, and only supply them when necessary?

This would seem to allow SOAP toolkits to work
more seemlessly with straight XML/HTTP service
interface. 

I'm sure there are a host of issues that I haven't
even considered.

- Winter






-----------------------------------------------------------------------------------
Post ID:3153
Sender:DJ Adams <dj.adams@...>
Post Date/Time:2002-12-30 21:19:23
Subject:Re: [rest-discuss] Re: Towards a RESTful validation interface
Message:

On Mon, Dec 30, 2002 at 02:56:48PM -0500, Sam Ruby wrote:
> The status code describe things common to all HTTP transfers.  What I 
> personally would like to avoid is applications like Amazon using it to 
> convey the difference between INSTOCK and BACKORDERED.

Agreed.

Mmm, adopting the 'classic' (in my eyes, anyway) "URI in a spreadsheet
cell" example:

GET /order/12345/status HTTP/1.0

200 OK
Content-Type: text/plain

INSTOCK

The actual meaning of 'INSTOCK' of course opens up a can of worms that's
not that noticeable when dealing with numeric values (like stock price).

dj






-----------------------------------------------------------------------------------
Post ID:3154
Sender:"Jeffrey Winter" <j.winter@...>
Post Date/Time:2002-12-31 01:40:58
Subject:Re: [rest-discuss] Towards a RESTful validation interface
Message:

In this case, invalid RSS results in an HTTP 500 error and
an embedded <soap:Fault> element.

Mark, do you see that as improper then given your comments?

The SOAP spec requires that any soap:Fault's use the 500 error, so the
question is, does invalid RSS demand that a Fault be generated?
Is this the proper use of Fault?

- Winter




----- Original Message -----
From: "Mark Baker" <distobj@...>
To: "DJ Adams" <dj.adams@...>
Cc: "Sam Ruby" <rubys@...>; <rest-discuss@yahoogroups.com>
Sent: Monday, December 30, 2002 2:20 PM
Subject: Re: [rest-discuss] Towards a RESTful validation interface


> On Mon, Dec 30, 2002 at 04:27:41PM +0000, DJ Adams wrote:
> > While I don't really have any suggestions, I would like to throw in a
> > thought from here - I *think* I would like to be able to tell whether
> > the data that I threw at the validator was valid RSS or not by looking
> > at the status code. This requires a slight rethink of the model Sam has,
> > whereby the URI represents a container that you're *supposed* to throw
> > valid RSS at, and receive either:
> >
> > a 200 status with no message body if the RSS is valid
> >
> > or
> >
> > a non-200 status back (with the details in the message body) if it's
not.
> >
> > Thing is, I can't figure out what the status code should be. I first
> > looked at status code 415 (Unsupported Media Type) but I suspect that
> > would mean that 'application/rss+xml' was *generally* not supported at
> > that URI, rather than just *invalid* 'application/rss+xml'.
> >
> > So - is trying to get away from the 'homogenisation' of all results into
> > a 200 status code an appropriate thing to do here (or anywhere)?
>
> Sure, if that's what you want.  If you want the state of resulting
> validation to be a valid state of your application, you need to return
> a 2xx.
>
> IMO, when in doubt, lean towards 2xx.  But that doesn't mean sending
> SOAP faults over 2xx, it means sending SOAP envelopes with state
> information useful to your application over 2xx.
>
> FWIW, I would fully expect a validation service to send back validation
> errors over 2xx, since validation errors are the result of *successful*
> processing (i.e. it was able to determine that there were validation
> errors).
>
> MB
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis
>
>
> To unsubscribe from this group, send an email to:
> rest-discuss-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>







-----------------------------------------------------------------------------------
Post ID:3155
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-31 01:43:35
Subject:Re: [rest-discuss] Why can't XML namespace declarations point to real live URLs?
Message:

On Mon, Dec 30, 2002 at 11:20:34AM +0000, Craeg Strong wrote:
> My question:  why can't they be the same thing?  Is there
> some reason I haven't thought of?  In fact, couldn't the 
> very same URL be used for: 
> 
> A) the namespace declaration
> B) the human readable spec
> C) mobile or manually downloadable code implementing the spec
> 
> where B/C is controlled through content negotiation
> or some other ReSTful facility...  Opinions?

Yep, I'd say they should probably be the same thing.  I can't think of
a reason for doing what they're doing.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3156
Sender:Mark Baker <distobj@...>
Post Date/Time:2002-12-31 01:55:12
Subject:Re: [rest-discuss] Towards a RESTful validation interface
Message:

On Mon, Dec 30, 2002 at 08:40:58PM -0500, Jeffrey Winter wrote:
> In this case, invalid RSS results in an HTTP 500 error and
> an embedded <soap:Fault> element.
> 
> Mark, do you see that as improper then given your comments?

"improper" is too strong.  It's perfectly REST-friendly to do this, I
think.  I'd just classify it as poor design within the constraints of
REST.

> The SOAP spec requires that any soap:Fault's use the 500 error, so the
> question is, does invalid RSS demand that a Fault be generated?
> Is this the proper use of Fault?

With the same "[im]proper" qualification above, no.

I'd only expect a Fault when POSTing RSS, if I was POSTing it to a
processor that required that the RSS be valid before it did its
processing.

And I assume we're talking SOAP 1.1 here, which only supports HTTP
500 responses.  For SOAP 1.2, I'd use a Sender fault which would map
to 400, since the sender is sending the invalid RSS.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis






-----------------------------------------------------------------------------------
Post ID:3157
Sender:DJ Adams <dj.adams@...>
Post Date/Time:2002-12-31 09:00:42
Subject:Re: [rest-discuss] Towards a RESTful validation interface
Message:

On Mon, Dec 30, 2002 at 08:55:12PM -0500, Mark Baker wrote:
> And I assume we're talking SOAP 1.1 here, which only supports HTTP
> 500 responses.  For SOAP 1.2, I'd use a Sender fault which would map
> to 400, since the sender is sending the invalid RSS.

Ah, I think this clears something up for me indirectly too - thanks.
I had been wondering whether the wording in 2616 [1] ...

<<
10.4.1 400 Bad Request

The request could not be understood by the server due to malformed syntax.
The client SHOULD NOT repeat the request without modifications.
>>

... referred to the HTTP method & URI & headers only, or referred to the
whole message. I'd been thinking the former, which had made me look at
(and subsequently abandon for reasons I stated in a previous post) 415.

dj

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1